Born in 1979, engineer, doctorate in 2008, I've started my working activity both as a researcher and as a freelance in the industrial automation field.
Old programming approach due to backward compatibility: no null-safety, very verbose way to invoke lambdas (compare with trailing lambdas and so in Kotlin), stupid things requiring patches (Lombok),
new features require time to be merged (map/reduce/filter), idiotic libs (BigDecimal, really?)
Everything is an object even if I do not want state management at all.
Ton of frameworks doing automagic things which require time to learn (Sprint/IoC in general, JPA, ...)
general overcomplex mindset in the community (all comes from the boring Java EE mindset, with few neglected good things: like Vert.x, micronaut-data-jdbc)
Only recently people with micronaut and quarkus (and IMB with OpenJ9) are trying to make java more feasible for modern computing trends (containers/serverless functions)
inevitable patch'n'go approach instead of redesign (GraalVM native compilation, to compete with lighter solutions)
Anyway there are also good things (TM), still you asked for cons only :P
In truth, there is a political game from Pivotal that creates one framework besides the community.
In Java, the community is important and there is a standard for development. Jakarta EE, former Java EE, is the standard. If you implement your application using Jakarta EE you can deploy in any Application Server the implements it. I have already switched from one implementation to another with no changes on my code.
Now Spring is the most used Framework, but it is not a Java standard.
Born in 1979, engineer, doctorate in 2008, I've started my working activity both as a researcher and as a freelance in the industrial automation field.
Yes, this is debatable: it is better to have a rather complex standard (Jakarta) once learned used everywhere, or a lot of simple frameworks? I mean: it took me 30 min to understand Vert.x Web, but a lot of CDI/IoC is still black magic to me! Let alone how the hell JPA can amazingly derive SQL queries from methods' manes! that's silly!
Ok... you develop C/C++ with Qt! Nice, we have the same background. I developed C for years, start using Java, then starting porting C libraries using JNI.
I think the JVM Memory Management was a nice feature in the past, but Docker killed the necessity for this feature. If we could just delete an object manually will be a great improvement.
Born in 1979, engineer, doctorate in 2008, I've started my working activity both as a researcher and as a freelance in the industrial automation field.
When people refer to java as a memory hog, they compare it to other more higher level alternatives then c/c++: Node, Python, Ruby, C# they all consume less memory than java in the same condition. Some do with perf handicaps (Python), still the used ram is way lower.
Also there is a "niche" now days with Go and Rust. Here the memory usage comparison is simply a joke!
About cap'ing memory usage, yes this was a good feature in the 90s but with VMs (way before containers) and a good "single responsibility" approach to ops, java memory cap'ing is obsolete IMHO - also java 8 had some nasty side effects with containerised envs.
Also, why limit max memory but not CPU usage?! you can still put a server on its knees just limiting max RAM! So the feature was nice but also non-complete.
Anyway there are also good things (TM), still you asked for cons only :P
Thanks! I agree with you.
About the tons of frameworks...
In truth, there is a political game from Pivotal that creates one framework besides the community.
In Java, the community is important and there is a standard for development. Jakarta EE, former Java EE, is the standard. If you implement your application using Jakarta EE you can deploy in any Application Server the implements it. I have already switched from one implementation to another with no changes on my code.
Now Spring is the most used Framework, but it is not a Java standard.
Yes, this is debatable: it is better to have a rather complex standard (Jakarta) once learned used everywhere, or a lot of simple frameworks? I mean: it took me 30 min to understand Vert.x Web, but a lot of CDI/IoC is still black magic to me! Let alone how the hell JPA can amazingly derive SQL queries from methods' manes! that's silly!
Regarding the Memory Hog...
Ok... you develop C/C++ with Qt! Nice, we have the same background. I developed C for years, start using Java, then starting porting C libraries using JNI.
I think the JVM Memory Management was a nice feature in the past, but Docker killed the necessity for this feature. If we could just delete an object manually will be a great improvement.
When people refer to java as a memory hog, they compare it to other more higher level alternatives then c/c++: Node, Python, Ruby, C# they all consume less memory than java in the same condition. Some do with perf handicaps (Python), still the used ram is way lower.
Also there is a "niche" now days with Go and Rust. Here the memory usage comparison is simply a joke!
About cap'ing memory usage, yes this was a good feature in the 90s but with VMs (way before containers) and a good "single responsibility" approach to ops, java memory cap'ing is obsolete IMHO - also java 8 had some nasty side effects with containerised envs.
Also, why limit max memory but not CPU usage?! you can still put a server on its knees just limiting max RAM! So the feature was nice but also non-complete.
Thanks again, I didn't know the meaning of the word hog. 😏 So I had to assume based on Google Translator.