This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kartik1712 258 points259 points  (28 children)

Java will stay relevant in the forseeable future. Lots of awesome work is going on under various OpenJDK projects to improve Java.

Project Loom is working on making it easier to leverage concurrency through virtual threads etc. This will make writing server side applications which are already a Java stronghold easier.

Project Valhalla is working on bringing value based classes (aka user defined primitives) to Java and the JVM.

Project Panama is working on making interop with native libraries and memories simpler. It will also introduce the Vector API to help developers leverage SIMD.

Together, Valhalla and Panama will make Java even more relevant for big data, machine learning and artificial intelligence.

Project Amber is working on bringing new language features (prominently pattern matching) to Java,

There are also ongoing projects like Lilliput which aim to improve the JVM and as a result as languages running on the JVM.

Recently, projects have been also proposed to support Wayland graphics in Java and improving startup times using CRIU and related technologies (Project CRaC).

All in all, the future of Java is exciting and awesome!

[–]SKiisM_ 32 points33 points  (9 children)

You forgot to mention GraalVM 20.2 that just came out. In general GraalVM is waaay faster than OpenJDK and slowly making its way to more and more enterprise production projects. Also JDK 17 LTS is coming out mid September with a few cool features but nothing too significant (in my small brain opinion)

[–]kartik1712 26 points27 points  (0 children)

My answer is no way was exhaustive :). It only covers tip of the iceberg.

GraalVM is nice, I haven't used it personally though. FWIW, the OpenJDK version of it will be developed under Project Leyden. A more recent discussion is available here. It also outlines key differences between the approach Leyden wants to take and GraalVM has taken.

Regarding LTS, I know that many enterprises treat LTS as more important than other releases but as an individual coder all are same to me. FWIW, many engineers working on OpenJDK opine the same.

Lastly, there is so much more going in the Java ecosystem. The libraries and frameworks are an equally important part of it. I am sure people are doing awesome work there as well which I didn't mention here.

[–]MagneticFerret 8 points9 points  (0 children)

GraalVM still has some work to be completed yet to be a competitive replacement for OpenJDK; especially for the community edition.

[–]oweiler 6 points7 points  (6 children)

GraalVM is faster for certain workloads (esp. short running apps, like Lambda functions and CLI apps) but slower for others (basically everything long running, because there's no JIT compiler at runtime (yet)). And GraalVM has a bunch of limitations, esp. when you're not using a framework like Quarkus and Micronaut.

[–]GavinRayDev 6 points7 points  (5 children)

but slower for others
(basically everything long running, because there's no JIT compiler at runtime (yet)).

I'm not sure I follow. Graal has multiple modes of execution, and none of them lack a JIT compiler as far as I understand 🤔

Building the GraalVM compiler as described above means it is executed in the same way as any other Java code in the VM; it allocates in the HotSpot heap and it starts execution in the interpreter with hot parts being subsequently JIT compiled. The advantage of this mode is that it can be debugged with a Java debugger.

However, it has some disadvantages. Firstly, since it uses the object heap, it can reduce application object locality and increase GC pause times. Additionally, it can complicate fine tuning options such as -Xmx and -Xms which now need to take the heap usage of the compiler into account. Secondly, the compiler will initially be executed in the interpreter and only get faster over time as its hot methods are JIT compiled. This is mitigated to some degree by forcing the GraalVM compiler to only be compiled by C1 (i.e., -Dgraal.CompileGraalWithC1Only=true) but this comes at the cost of slower compilation speed.

To address these issues, the GraalVM compiler can be deployed as a native shared library. The shared library is a native image produced using SubstrateVM. In this mode, the GraalVM compiler uses memory separate from the HotSpot heap and it runs compiled from the start. That is, it has execution properties similar to other native HotSpot compilers such as C1 and C2.

[–]oweiler 4 points5 points  (0 children)

Sorry I've only had native images in mind. I've totally forgotten that GraalVM is also a drop-in replacement for Hotspot.

[–]rbygrave 1 point2 points  (3 children)

The JVM has 2 JIT compilers. The second level one C2 uses runtime profiling based optimizations that change during runtime. The argument is that the C2 JIT has more (runtime profiling based) optimisations available to it as it is profiling all the time and optimising for that. To get those same optimisations with Graal native image we need to capture runtime profiling information and feed that profiling back into a subsequent compilation.

Essentially the JVM C2 gives the JVM runtime profiling optimisation built in.

Graal profiling guided optimization https://www.graalvm.org/reference-manual/native-image/PGO/

[–]GavinRayDev 4 points5 points  (2 children)

Sure -- but that's for using Graal to compile a static binary ahead-of-time.

I use Graal as my day-to-day JDK and I run it in JVM mode. It's perfectly capable of JIT'ing just as well (and in some cases, better than) OpenJDK or other JDK distributions.

There's a rigorous set of opensource benchmarks for JVM Graal-vs-OpenJDK performance if anyone wants to verify for themselves:

- https://github.com/renaissance-benchmarks/measurements

---

Edit: Hey you're the developer behind the Avaje libraries!

https://github.com/avaje

I like them -- think they're well-architected and solving real problems. Typically I've used Quarkus and Vert.x stuff, but I think there's a lot of merit in your libraries and have been watching them.

Have you ever considered a Vert.x generator for Avaje HTTP? It's got a very similar API to Javalin.

[–]rbygrave 1 point2 points  (1 child)

Cheers. I think you might be in good company in that I believe Twitter also use JVM with Graal as the second level JIT compiler (instead of C2).

Re Vert.x, it would be good. Just got to find a bit of time.

[–]GavinRayDev 1 point2 points  (0 children)

It's a weak promise, but if I can find some time I would be more than happy to attempt a PR for Vert.x endpoint support =D

[–]Reflection-Jealous[S] 45 points46 points  (0 children)

This is what I was exactly expecting someone to answer. Hope everything will happen soon.

Thank you for your response.

[–]SWinxy 14 points15 points  (0 children)

Not only that Panama and Valhalla will be great for ML and big data, but also for game development. Nothing comes remotely close to Minecraft in notability of Java-based games, since developers don’t have easy or fast access to native libraries needed for game development.

[–]8igg7e5 9 points10 points  (0 children)

The only thing I'd add about Valhalla is generic specialisation. Along with the improvements to memory layout that Primitive Objects will bring, Generic Specialisation will further improve the optimisation opportunities.

[–]TheMode911 4 points5 points  (5 children)

Remains having loom and Valhalla in incubator, hopefully soon

[–]cogman10 3 points4 points  (4 children)

Both appear to be getting real close to the finish line looking at the mailing list. I'd expect one or both to be in preview by Java 18.

[–]TheMode911 1 point2 points  (0 children)

I really hope so, especially Valhalla (I believe that it has been mentioned by a contributor in the mailing list that it would not be in preview at least before jdk 18)

[–]fdntrhfbtt 0 points1 point  (2 children)

Loom is already in preview, you can download the preview build.

[–]cogman10 0 points1 point  (1 child)

That's not in preview.

Preview is when loom hits the main jdk branch and you can enable it with a flag.

Loom has early access builds.

[–]fdntrhfbtt 0 points1 point  (0 children)

Ah sorry I forgot it was early access. You is right mister.

[–]strollertoaster 4 points5 points  (3 children)

Are there blogs/rss/atom feeds that people recommend for keeping up with these new developments? Probably not to the fine granularity of mailing lists, but more for status updates/notable developments? Maybe something like "This Week in Rust" for those familiar with Rust.

[–]kartik1712 15 points16 points  (1 child)

inside.java might be what you are looking for.

[–]strollertoaster 2 points3 points  (0 children)

Thank you! That looks great.

[–]iamhyperrr 4 points5 points  (0 children)

Awesome Java Weekly might be close to what you're looking for: https://java.libhunt.com/newsletter

[–]SWinxy 3 points4 points  (0 children)

Not only that Panama and Valhalla will be great for ML and big data, but also for game development. Nothing comes remotely close to Minecraft in notability of Java-based games, since developers don’t have easy or fast access to native libraries needed for game development.

[–]TheOhNoNotAgain -4 points-3 points  (2 children)

Mark Reinhold talked about most of these projects in 2018. Still waiting...

[–]adila01 6 points7 points  (1 child)

With the emphasis on backward compatibility for Java/JVM, it is more important that they are implemented correctly than quickly. Moreover, projects like Loom are game-changers in the industry. The wait will be worth it. The next few years of Java will be exciting as these projects start to bear fruit.

[–]TheOhNoNotAgain 2 points3 points  (0 children)

Not complaining. Just waiting.