Most people don't even know why they hate Java. And the rest hates it because their Chief Architect taught J2EE is a great idea.
Personally I developed a dislike for it because of Eclipse, Android Studio, Swing and JavaDoc.
Love It or Hate It, Java Continues to Evolve
51–60 of 156 posts
Re: Love It or Hate It, Java Continues to Evolve
#52Earlier quoted context omitted.
Agreed on all points. You mentioned Go, so I'd like to add that Project Loom is the OpenJDK initiative to add green threads/coroutines to the JVM which I'd love. The tricky thing with "data classes" are that everyone wants something similar but different between the various terms: records, data classes, value types. Personally, what I want from this is essentially Lombock-style all-args constructors, equals, hashcode…
Loom is rather nice, but frankly I don't find the lack of co-routines something I miss. You can spawn hundreds of real threads a second so it is possible to write Go style code in Java if you really want. I may change my mind when I actually use it though. I don't mind what type of data classes they come up with. I just want to not have to write stupidly long constructors, multiple sets or chain-able objects when I w…
Except that the memory overhead for each thread is MUCH higher: the default would be 1Mb for most JVM implementation.
Yes, you can change the thread stack size, but that's a global fixed size for all threads, so you can't make it to small, or you'll risk stack overflows.
Meanwhile, Go is using dynamically growing stacks, starting at 2k.
Re: Love It or Hate It, Java Continues to Evolve
#53Earlier quoted context omitted.
Not a die hard java/go-or-anything entusiast, but replace the name Java with Go and you have the exact same thing.
But with Go you can iterate quickly compared to java as the compilation time is very small. This difference is massive in big projects. This is an important reason why I took up Go for many projects.
Can you give a few numbers what counts as "very small" here? Most of my big java projects take less than two minutes for a full compile and incremental compile of the whole project is usually in the range of 10 secs. If you run the whole test suite it can take longer depending on the tests, but that's not what I'd count as "compile time".
Re: Love It or Hate It, Java Continues to Evolve
#54Earlier quoted context omitted.
> Once I show them Java 11 with var keyword, lambda's and streams they start appreciating how modern the language has become. I wrote a lot of Java, but it was a long time ago. Could you share a bit of code representative of the modern Java 11 style you mentioned (var keyword, lambdas, streams, etc.)?
Not the guy that you were asking but Trivial example: public static void assertIsSuperset(Collection superSet, Collection actualSet) { final List missing; missing = actualSet.stream().filter(x -> !superSet.contains(x)).collect(Collectors.toList()); if (missing.size() != 0) { /* Imagine some more verbose exception creation here, which is why we caught it in a list*/ } } The lambda is in the creation of 'missing': filt…
That still seems very clunky and also very inefficient compared to what I'd do in Swift:
func isSuperset(superSet: Set, actualSet: Set) -> Bool {
return actualSet.contains(where: { !superSet.contains($0) })
}
Re: Love It or Hate It, Java Continues to Evolve
#55I'd like to see a JVM with a garbage collector that isn't designed to always consume the maximum amount of memory before it starts collecting. If you configure the JVM to have at most 400MB and it's current heap size is 120MB and you allocate 0.5MB every second or simply allocate 400MB of temporary objects that could be collected right away, it will allocate more GC heap until it hits the maximum 400MB and only then it decides to start a collection cycle. This makes the JVM useless for anything that isn't a web server that uses the entire RAM anyway.
Although Shenandoah looks promising but it's pretty telling that even in 2019 the JVM only has a single good garbage collector and it's still experimental. 23 years of history my ass. Other than the awful JEE ecosystem, the JVM is probably the worst part about the Java ecosystem. You can't fix it with a language that runs on top of it. It's slow (mostly startup performance), the GC is awful and it gobbles up a huge amount of memory. Obviously my company doesn't care because 8GB of RAM for a webserver costs them almost nothing.
It wouldn't surprise me if a WebASM implementation will take over one day, because the JVM is such a failure.
Re: Love It or Hate It, Java Continues to Evolve
#56Earlier quoted context omitted.
I may work with java soon, so I was reading about Spring and it was yet again a dive into insane amount of verbose over engineering that I ran away from years ago. It's true that post 8 Java becomes palatable. And someone on reddit just showed me this piece of stats: https://www.jetbrains.com/lp/devecosystem-2019/java/ 83% on java 8, java 11 nicely going up I pity those forced to work with old techniques
I write quite a lot of Java, and I have to admit I never “got” Spring. I’d much rather have explicit boilerplate code (preferably in library form as much as possible) than complex, invisible magic. The latter is “easy”, but the former is “simple”. In most cases, “simple” is more important.
But Spring gives you the best of both worlds. A lot of verbose code (as annotations and class inflation instead of explicit boilerplate) and inscrutable magic.
Re: Love It or Hate It, Java Continues to Evolve
#57Earlier quoted context omitted.
Any language that will survive as much as Java or C++ will accumulate some baggage, even your cool shine new language will look outdated 20 years from now to the new cool programmers. Look at other examples, CSS - full of bad examples on how do do X, JS - a lot of bad parts, missing core stuff like importing modules , Python - it had is issue caused by some old decisions that caused a lot of pain when migrating versi…
The point is to work at the sweetspot of emerging language/high pay and then get out once the framework decision level bugs start emerging. Then come back as a consultant in 20 years at the intersection of high pay/no one else can figure out how to fix the software. If you're working with Java you're mostly in medium pay/tearing hair out coz of legacy issues-which you WILL have because a Java shop never COMPLETELY mo…
Except that Java is that 20 year old thing, and it has stood the test of time, it's not the new COBOL.
I learned vi about 30 years ago, Java and SQL over 20 years ago, and they're tools I can still use every day to get stuff done.
Re: Love It or Hate It, Java Continues to Evolve
#58One thing I would really love to see is a better way how you manipulate strings. Variable interpolation would be nice and you wouldn't have to have all that ugly string concatenation all over the place.
Re: Love It or Hate It, Java Continues to Evolve
#59In my experience most people don't like Java due to experiences they had before Java 8. This means they were used to the bloat, config as XML style world which made Java a pain to write and slow to run. Once I show them Java 11 with var keyword, lambda's and streams they start appreciating how modern the language has become. Then you throw in frameworks like javalin or sparkjava and suddenly they are not as hostile a…
That sounds a lot like what people are saying about PHP and its newer versions. But the thing is, now that we have great alternatives (Kotlin, C#, Scala, Go, Dart...), what does Java have that those don't?
Re: Love It or Hate It, Java Continues to Evolve
#60Java 8 made it an "okay" language for me to use. It's a lot better nowadays, but historically the biggest problem with Java has been the 3rd party libraries. They tended to be written with extensibility in mind at the expense of usability. Extensibility is great, but it's not the only important thing in a design. I'm not a huge fan of annotations. It makes the language feel a bit magical and hard to debug in some pla…
You're right. Java is a decent language with a decent type system (bar the lack of null safety and some other quirks). It's all the annotations and reflection and XML and magic that creates most of the pain, and that's the fault of the library and framework developers, not Java itself.
> Java is a decent language with a decent type system (bar the lack of null safety and some other quirks).
Optional is your (and my) friend. It has a small performance penalty and for historic reasons it will never be used everywhere, but for new externally visible code (code not in the class) I try to use it and it makes for face nicer APIs.
I never understood why XML config everywhere and "we should configure it all instead of programming it" took off. You shouldn't change things on production anyway, so the main aspect "you can change it without recompile" is moot and instead you have all the downsides of not having part of your code checked by the compiler.