Hacker News new | past | comments | ask | show | jobs | submit login

Sounds about right for Java..



How many classes do you think it should have, ballpark, given the same feature set? GUI toolkits alone can produce thousands of classes because there are thousands of concepts that make sense to model, then add on security, collections, many utilities, XML handling, multiple RPC systems and so on. It's hard to over-state how large the Java standard library is.

And it's not like other ecosystems do better. The standard complaint about JS is that you try to do something basic in that ecosystem and discover you have 10,000 modules in node_modules. Not so different, really, except that the Java stuff comes from a single team with a relatively coherent design philosophy.


If it is necessary to have that many classes, then there should be so many classes.

but in Java everything is a class, main function? in a class. a library of static functions? in a class.


With an alternative design you'd need to have some other code container concept, but it'd be almost exactly the same as a class file. If the JVM also had a separate notion of a non-class file, just hold to hold static methods, then it'd boil down to duplicating the format. Most languages decide to make the source file the first-class container concept, or in native languages, the DLL/.so, but this isn't obviously better and comes with its own downsides. Orienting the VM around classes has a bunch of upsides that contribute to Java being successful.

The real complaint here is more about the syntax boilerplate involved in writing top level functions in Java that map to classes with static methods. Kotlin shows there's no deep reason why the Java language has to be written this way, it's just notation. They picked it to avoid complicating the language with special cases, but I can easily agree that smarter syntax is more important than the Java guys have historically believed. Kotlin is proving this at the moment.


Sure, classes act as namespaces in that case. What pain point does it cause?


Does the AbstractFactoryFactoryInterface and AbstractFactoryFactoryImpl count as two different classes...?

Kidding aside, I always found Java as a core language (and the basic standard library for it) to be mostly fine, but the weird architecture astronaut cult that hovered around it and infected many of the commonly used libraries to be a real problem.

Maybe things are different now for the language, I haven't touched it in many years at this point.


Yeah it was never the language or the core libs which were the problem, it was mostly some of the frameworks which had the FactoryFactory problem


I disagree with what I call Java's OOP obsession, but I have to admire the drive behind that ecosystem.


I'm disgusted by it, but admire the ability for the system to run in spite of the mess that the pattern generate.


At least with lambdas and `var`, they yielded a bit on the old ways.


Sounds like a typical enterprise Java hello world type application.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: