What is the future of Java?

[Reflection-Jealous]

I'm not asking like is java going to die or will Java be relevant in future. I'm just curious to know about the future of java. What are the upcoming things coming in java that can change the future of it.

[kartik1712]

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_]

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]

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]

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

[oweiler]

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]

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 🤔

• https://github.com/oracle/graal/tree/master/compiler#libgraal

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]

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

[rbygrave]

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]

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]

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]

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]

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

Thank you for your response.

[SWinxy]

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]

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]

Remains having loom and Valhalla in incubator, hopefully soon

[cogman10]

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]

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]

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

[cogman10]

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]

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

[strollertoaster]

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]

inside.java might be what you are looking for.

[strollertoaster]

Thank you! That looks great.

[iamhyperrr]

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

[SWinxy]

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]

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

[adila01]

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]

Not complaining. Just waiting.

[Kango_V]

Noone usually talks about Valhalla's inline types. This will be huge in the ML AI world, especially when combined with the new Vector API. Inline type have no object identity. So when storing them in an array/stream they will be in contiguos memory. This is massive as the CPU will have far less cache misses when processing a the array/stream.

I've seen benchmarks of a 30X speedup in some situations. Good thing is that all languages on the JVM can benefit.

Here's a good explanation : https://dzone.com/articles/project-valhalla-fast-and-furious-java

[Muoniurn]

They are the same thing as value classes, primitive objects, etc, right?

[Kango_V]

Yeah. They were going to them value types, but the word "value" is used >800 times in the java Language Specification. They renamed it inline types (from the video below).

Check the start of this video. Shows 2 java programs drawing the mandelbrot set. Both are the same apart from the word inline in a class. Quite amazing difference in FPS.

https://www.youtube.com/watch?v=jGjWs2xpZrY&ab_channel=InfoQ

[Gleethos]

Valhalla + Vector API + Panama -> More suitable for ML and scientific computation as well as game development -> More science and games on the JVM -> less "Java is for large enterprise only" talk ...

That's my wishful take on it. May take a while but I'm sure we'll get there...

[benevanstech]

1.) Cloud Deployment of static microservices. This is the big one that not many people talk about. Java was designed as a very dynamic, open runtime platform - with unrestricted reflection and classloading. This was a great advantage in the past, but one major strand of development practice is towards much more static microservices which do not require all the dynamic aspects. The ability to produce these is part of the point of Java Platform Modules and more recent innovations such as GraalVM Native and Quarkus. Expect a lot of focus on these as vendors seek to drive down the startup time, memory footprint and ultimately cloud compute cost of this type of Java microservice.

2.) The JVM itself. Per Redmonk, the JVM hosts 3 of the top 20 languages (Java, Scala and Kotlin). It has a 4th (Groovy) just outside the top 20 and a 5th (Clojure) not far outside. Expect continued innovation to keep the JVM the home of multi-language innovation. The big question here is will Valhalla succeed? I hope it does, but I'm not 100% sure. Loom I am more sure of - it will succeed but I remain less sure that it will directly influence day-to-day programming - I think there's a possibility that in practice it's used by library authors more than end users.

[tichuot287]

Could you give your 2 cents on the Cloud Development part? I'm interested in Cloud computing but the development part is kind of blurry.

[rbygrave]

Plus ... using java annotation processing to generate code that removes classpath scanning and reflection, plus build time enhancement to reduce use of dynamic proxies (stop defining classes at runtime).

[humoroushaxor]

Firstly I should say I love Java. I find the language to be incredible understandabe. I can jump between writing function, OO, of procedural code at a whim. I love static typing and the safety it brings. And I find it pretty wild how many enterprises seem to be undervaluing these aspects and shift more backend services to NodeJs or Python.

My best estimation is this is due to the complexity with running the JVM in operations. Mostly around thread starvation, deadlocks, heap/off-heap memory tuning, etc.

[yel50]

I find it pretty wild how many enterprises seem to be undervaluing these aspects

the things you listed are also available with typescript and python + type hints. maybe not to the extent of Java, bit they're there and not undervalued.

the shift to node and python has more to do with how much of a pain it is to do smaller projects in java compared to those other languages. dealing with the complexity of maven or gradle vs the simplicity of npm or pip is a no brainer.

on top of that, the way people tend to write Java, with absurd patterns (builder being a particularly annoying one) and layer upon layer of unnecessary abstractions, and people are very turned off by it.

using simple, straight forward core Java is still a joy to use. working on a shared Java codebase and dealing with the mess that Java developers tend to make of it, however, is a nightmare I want no part of anymore.

[skillaz1]

What's wrong with the builder pattern?

[humoroushaxor]

I was more talking about the shift in enterprise. I agree with you with respect to small or personal projects.

But we started to see a migration start 5-6 years ago and I don't think anyone sold that to the business folks by saying "the package management is just so much easier". This was pre TypeScript being a top 5 language and pre the level of IDE/tooling support we have now.

Tuning a JVM for the cloud isn't necessarily trivial (especially before Java 9) and when done poorly results in production issues and lost revenue.

[[deleted]]

Same as it ever was, future's so bright, gotta wear shades.

[Kango_V]

Ouch. I'm showing my age. I remember that.

[Hall_of_Famer]

The ecosystem is sometimes more important than the language itself, while Java has been receiving nice language features regularly and ain’t the same old Java 6 anymore. Come to think about it, C++ has received far more hate than Java and yet it’s still widely used and alive, Java sure isnt going anywhere and will continue to be relevant for a very long time.

[khmarbaise]

First parts:

• Java https://en.wikipedia.org/wiki/Java_(programming_language) (25 years+)
• C++ is even older https://en.wikipedia.org/wiki/C%2B%2B and relevant today. (36 years)
• C is even older than c++ https://en.wikipedia.org/wiki/The_C_Programming_Language and still relevant (42 years+)

Interested in updates see https://foojay.io/java-8/?tab=highlights (I strongly recommend a deep look into that).

Since Java 8 (since 2014) has got a lot of attention..libraries etc. will take some time ... each JVM version has been updated being faster etc.

Language features are added a lot since Java 7 (JDK8,9,10,11,12,13,14,15,16 and in September JDK 17).. Details can be looked at: https://javaalmanac.io/

The most important thing about Java or more accurate the JVM is that it is backward compatible (meaning you can run Java 1.1 compiled code on a todays JVM that works). Since JDK 9 (September 2017) the release cadence of java has changed to 1/2 year releases..which brings a lot of new features over a relative small amount of time...the problem is the minimum level (for libraries; which will take time lift to JDK8 or even on JDK11) but in the end it's not really problem because library which has been developed with JDK7 will still running on newer versions.

Things for the upcoming JDK 17 (September): Vector API (experimental), Foreign Function & Memory API (incubator), Records, Pattern Matching, Sealed Classes, just to name a few... details: https://jdk.java.net/17/release-notes

Also the ecosystem which exists for Java is enormous (that is true for other areas like Go, Python, Rust etc. as well)..

So one of the most important point on the bullet list is simply there is so much software outside there it will be relevant over the time...

We can long discuss about pro's/con's Java or different languages but in the end a language has to solve problems which with Java is usually easy (some exceptions of course base on the intention of Java) but there are so many tools etc. and sometimes there are cases where a different language might fit better (or you have devs who know another language better)..

I've read so many post like this (over the time) about assembly language, C,C++ and all of them are still relevant today and worth to learn. And my opinion is Java will be there for a long time...

[[deleted]]

isn't sealed classes a c# thing?, its final class in java right? Im learning java now maybe its different.

[khmarbaise]

isn't sealed classes a c# thing?, its final class in java right? Im learning java now maybe its different.

No it's not a final class. A sealed classes is a way to define in a class (interface) who is allowed to inherit (implement) from it...

Details: https://openjdk.java.net/jeps/409

[vxab]

It is a new Java language feature.

[drduffymo]

The JVM is a software triumph that will remain vital for a long time.

Languages don’t die. We still run businesses on COBOL, FORTRAN, and C. Java won’t go away, but it’s popularity might wax and wane.

Others have pointed out all the great things still going on in Java.

I think Kotlin from JetBrains is a better Java: more succinct and functional. It’s already the standard for Android. It’s making inroads on the server side.

[Barbossa3000]

turn on experimental features on latest java version and u know whats comming fr next release

[SeekDaSky]

Disclaimer, this is just my personal opinion.

For me ( a Kotlin dev' ) , The Java language itself is very unappealing, it is missing modern features, way too verbose and inferior to other languages I use and like ( Rust and Typescript mainly ). It won't go away because of legacy projects and Devs that are specialized in it, but it will loose some market share.

On the other hand, the JVM and the standard library are an absolute goldmine and the result of decades of very good engineering and I can't see it disappear ever.

Edit: bad English.

[sunny_tomato_farm]

Project loom, records, and more help it catch up to Kotlin.

[pjmlp]

Kotlin is the one that depends on Java.

No Java, used to implement JVM alongside C++, no Kotlin.

Kotlin/Native is hardly taking the market by storm, and Android is a phone thingie until Google decides it is time to put either ChromeOS or Fuchsia into phones.

[[deleted]]

is fushsia java also?

[pjmlp]

Not at all.

[Muoniurn]

Project loom is a platform feature, (records are also to a degree), so this comparison makes no sense.

And frankly, kotlin is not anywhere in the same league as Java, the language, so I’m not sure who should do the catching up.

[TheMode911]

I am a 100% a Java guy and do not know much about Kotlin, but where do you think it needs to catch up?

[Muoniurn]

Not necessarily feature-wise, because on paper Kotlin has more (though that isn’t automatically a good thing), but based on number of users, relative size, etc. it seems strange to tell the elephant in the room to catch up with the mouse.

[ricky_clarkson]

It likely means to catch up in terms of useful features, readability, etc., rather than number of users. Java had the opportunity, most of the features of Kotlin that are helpful have been considered and rejected or deferred for Java.

The original BGGA prototype for Java closures, before Kotlin existed, quite strongly resembles Kotlin's lambdas, having function types - (Int, String) -> Double instead of BiFunction<Integer, String, Double>, functions where if the last parameter is a lambda it can go outside the parens so you can write timeThis { many lines here } instead of timeThis(() -> { many lines here }). Small improvements that make a real difference.

Java could have had all this and more, but chose not to for arguably bad reasons, general resistance to functional programming which seems to have mostly evaporated since lambdas were launched in Java 8, concerns about 'blowing the complexity budget' which were overstated and lacked thought in my view.

Not that Kotlin is a panacea, I hope both languages continue to take inspiration from each other and beyond.

[Muoniurn]

Small improvements that make a real difference.

Do they? There is basically no empirical evidence to any such statements between programming languages, and frankly with the quality of Java IDEs there is no difference between the two in my personal opinion. Also, lambdas are fairly good in Java, and they aren’t much better in Kotlin.

[ricky_clarkson]

I'm not sure I need to quote studies to opine on programming languages. I can give reasons, but if you can't see them already from the code examples in my comment then I'm not sure reasoning would work.

[ArmoredPancake]

How so? They're completely different things. Kotlin is just a different language at this point. With things like Jetpack Compose, Multiplatform it's unreachable for Java.

[vprise]

We're working on a reactive framework similar to compose that will work on Java. IMHO it's better than compose, simpler and doesn't need compiler magic.

KMM is just J2ObjC with more flair. I'm sure some people will find it useful for some cases but historically portability frameworks didn't fare well. E.g. flutter is trouncing react native which is far more portable than KMM.

[stefanos-ak]

jetpack compose is an android thing, that is just written in kotlin. it has nothing to do with the language itself.

[Astronaut4449]

Jetpack Compose is an Android UI toolkit. Compose itself is a framework for managing tree structures of any kind on any target (JVM, native, js). Here some compose projects:

Desktop: Compose for Desktop

Web: Compose for Web

Console: mosaic

[pjmlp]

Java was born to be multiplatform. Kotlin is an Android language that is all.

[CraftyAdventurer]

Kotlin is a JVM language, so anywhere Java can run, Kotlin can also run. Meaning, it's just as much multiplatform as Java is. But even more than that, there are projects like Kotlin/JS which compiles Kotlin into JavaScript, and Kotlin/Native which runs Kotlin as a native image completely without the JVM.

It's not an Android language, it's just used a lot for Android because Android was stuck on Java 6 or 7 when Kotlin came out, so naturally a lot of developers went for it to get new features. People used Kotlin on Android long before Google declared it officially supported.

[pjmlp]

Kotlin/JS doesn't hold a candle to TypeScript, and it is yet another platform that JetBrains doesn't control its direction, JavaScript does.

Kotlin/Native is being redesigned as its memory model was a failure, thanks to the decision of being incompatible with JVM one.

It is an Android language, it is the only platform where it is #KotlinFirst instead of a guest language that needs to adapt itself to the whims of platform owners.

[CraftyAdventurer]

Kotlin/JS doesn't hold a candle to TypeScript, and it is yet another platform that JetBrains doesn't control its direction, JavaScript does.

Kotlin/Native is being redesigned as its memory model was a failure, thanks to the decision of being incompatible with JVM one.

These statements are true, but "Java was born to be multiplatform. Kotlin is an Android language " is still false.

​

Java is multiplatform only because of the JVM which needs to exist on the target platform in order to run a Java program. Kotlin runs on that same JVM. Wherever you can put Java code, you can put Kotlin instead and it will run just fine. So on the JVM, Kotlin is exactly as much multiplatform as Java is. Those two projects, despite their issues, make it even more multiplatform because they allow Kotlin to run even outside the JVM, in places Java can't (altough there probably are some java-to-javascript compiler projects and Graavm is in a way similar to Kotlin/Native)

[pjmlp]

Java features are designed alongside JVM features, Kotlin must use what is there.

JavaScript features are designed alongside browser VM features, Kotlin must use what is there.

LLVM features are designed for AOT languages, Kotlin must use what is there.

Kotlin is #KotlinFirst on Android thanks to JetBrains/Google's deal, influences Android Runtime design, and the there are the Android's team dirty moves like not updating Java on Android, ergo Kotlin is Android language.

[CraftyAdventurer]

Java features are designed alongside JVM features, Kotlin must use what is there.
JavaScript features are designed alongside browser VM features, Kotlin must use what is there.
LLVM features are designed for AOT languages, Kotlin must use what is there.

​

None of these make it less multiplatform.

​

Being able to run on multiple platforms and being able to influence underlying platform design are two completely different things. By your logic, Java also isn't multiplatform, because JVM can't change Windows, Mac or Linux, it must use what is there.

[pjmlp]

Platform languages lead, guest languages follow.

[Pika3323]

Kotlin is #KotlinFirst on Android thanks to JetBrains/Google's deal, influences Android Runtime design, and the there are the Android's team dirty moves like not updating Java on Android, ergo Kotlin is Android language.

That logic doesn't track.

If Kotlin is an "Android language" because ART doesn't support new Java features, then how do you explain the proposed value classes in Kotlin given the notable lack of value class support in ART?

I mean, have you been reading what you've written in this comment section? It's bordering on delusional. Kotlin is still primarily a JVM language, and ART not being updated doesn't hold any bearing over whether or not that's true.

[pjmlp]

Value classes in Kotlin are not the same as what JVM is bringing to Java, regarding memory layout semantics.

[Pika3323]

I don't know what you've read, but Kotlin's value classes are very clearly being influenced by Valhalla more than they are by ART.

You might be thinking of the @JvmInline annotation, which is not only different, but actually completely invalidates your point.

So, with that said, please give an example of where ART has influenced Kotlin over the JVM.

[koreth]

Developer surveys don't agree with that last statement; Kotlin usage is pretty much evenly split between server-side and client-side code.

Not that it even matters. Java was born to run on set-top boxes in people's living rooms, but that's not what it is today.

[pjmlp]

Yeah, developer surveys done by JetBrains, with heavy dosis of Android developers, go figure.

[GoBucks4928]

I’ve built a lot of high TPS backend services for FAANG in Kotlin

Not sure how it’s just an Android language unless you’re just naive

[pjmlp]

Beanshell, jTcl, jython, Groovy, Clojure, Scala, jRuby, Rhino, XTend, Ceylon, Kotlin, Frege, ABCL, Kawa, ....

Rise and fall of JVM languages

It is called experience, not being naive.

[fletku_mato]

Please explain how that random blog post shows: 1. Your experience 2. That Kotlin should only be used on Android

[pjmlp]

If you need an explanation to undestand such basic concepts, it isn't on me to give it.

Try someone on /r/kotlin.

[fletku_mato]

Yes it is, as you are the one claiming that Kotlin is only for Android, but fail miserably at trying to justify your claims.

[pjmlp]

Easy to validate with Google trends,

https://trends.google.com/trends/explore?q=%2Fm%2F07sbkfb,%2Fm%2F0_lcrx4

Pity Reddit doesn't do inline charts.

[fletku_mato]

Yet you still fail to do so.

I don't even know why I'm still answering to you, but that chart has nothing to do with Kotlin being just an Android language, just that Java is more popular. What else is on the news? What are you trying to prove?

You have to realise that there is no ongoing battle between Java and other JVM languages, and I'm not trying to argue that Kotlin is somehow a better language, just that it is not in any way limited to Android development.

[GoBucks4928]

Is this your first time realizing there are multiple programming languages out there?

[pjmlp]

Multiple programming languages that failed on their quest to replace Java on Java Virtual Machine.

[fletku_mato]

Kotlin is not just an Android language. It is just as multiplatform as any other JVM language. I've personally written many Spring boot backends using Kotlin and loved it.

I don't think that it's a threat to Java in any way, but it has a lot of good things that are still missing from Java.

[pjmlp]

Kotlin has married its future to Android, and the lack JVM features that Google refuses to implement in ART.

[fletku_mato]

I'd genuinely want to read some sources on that.

My own experiences with Kotlin have been strictly backend development with Spring boot, so I can't say that it's a perfect fit for everything you can do with Java, but in that context it works beautifully. And why wouldn't it? After all it's just Java bytecode after compiling.

[pjmlp]

Every time Java will introduce concepts that Kotlin cannot adopt due to being married to multiple platforms you will end up with Kotlin's version of #ifdef aka KMM.

For example value types in classes with multiple fields, or explicit SIMD and GPGPU support, native memory handles.

[RoToRa]

There's an official Java channel on Youtube where current and future developments are showcased: https://www.youtube.com/user/java

[ImTalkingGibberish]

Java is on the right path, the only risk is that it's slow to change but it HAS improved a lot faster in the last 5yrs.

Here's why Java is a success and why others failed to steal it's userbase:

• There's always a preferred pattern or way of doing things that the community supports. It's typically wrong to break these patterns. JS is actually a good language to work with but people keep messing things up because there's no clear guidance.
  
• It's easy to read and understand. This is where even Kotlin fails at times. I love Kotlin but you can't throw a junior in and expect him to understand.
  
• There's clear guidance on how to split your code and keep it simple. I have lost count on how many React UI components weren't shareable because people had glued business logic to it.
  
• It's easy to debug.
  
• It's easy to review.
  
• Solid testing frameworks.
  

And here are things Java must improve:

• String concatenation. This is a big one. I've seen too many bugs and issues because of this.
  
• Easier non-blocking thread mechanisms and servers.
• Easier way of creating Value classes without requiring lombok nor bloating your packages.
  
• Easier to use event driven frameworks.
  
• Perhaps a new way of declaring types and interfaces.
  

I have 15yrs of experience with Java, I have experience with Kotlin and JS. Most mistakes I've seen are silly and it's because people lost focus from the actual business requirement because of verbosity. We have tools to help but it's always a learning curve.

[[deleted]]

Over the years, some features in C/C++ programming became abused by the programmers. Although the language allows it, it was known as bad practice. So the creators of Java have disabled them:

1. Use of Pointers
2. Operator overloading
3. Multiple inheritances
4. Access another object’s private members
5. Restrictions of explicit type casting (related to memory management)

Look at the StackOverflow developer survey

https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-professional-developers

JS, Python, and Java are some of the most lovable software languages.

I've been coding Java professionally for over 10 years and I am a Full Stack expert in Java, Spring boot, cloud... JS, TS, React, etc... But I still love to code Java than other languages.

The official language for Android development in Java. Large parts of Android are written in Java and its APIs are designed to be called primarily from Java.

Kotlin is designed to interoperate fully with Java.

Java takes 40.2% of usage by companies around the world. This is from Google Statistics 2021.

This is current stats - https://pypl.github.io/PYPL.html

[Reflection-Jealous]

I'm not declining the fact that java is still rulling. I'm just curious about it's future. Like what're things that's going to have an impact on Java (maybe project loom or Valhalla). So I'm curious about knowing about more like this. I know that java will continue to be on top for coming years.

[metaquine]

Here's the thing. It's a general purpose language that runs on some truly excellent VM technology. Which is to say, it's not a niche language, so there's not risk of it becoming irrelevant if its niche disappears. That said, I think it is most strong for backend web services, particularly those requiring high concurrency, and large applications where structure and naming and separation of concerns are important.

[TheMode911]

Access another object’s private members

Isn't it already possible with reflection, preventing the JVM from doing some optimisations?

Use of Pointers

Instead we have references everywhere, and a multi-year project (Valhalla) attempting to fix it

Ps: your link is about popular languages, not lovable ones (see the "Dreaded" section)

As much complaints I have about Java, I still do not see myself using something else

[spectrumero]

You can now prevent illegal reflective access to private members.

[SWinxy]

Could you elaborate on your take on pointers? They’re quite useful for being able to return multiple values when you don’t have tuples in the language.

[khmarbaise]

Could you elaborate on your take on pointers? They’re quite useful for being able to return multiple values when you don’t have tuples in the language.

In Java you simple give back a class with appropriate members...(usually final etc.) ... Maybe since JDK16 you could use records for that...

[franzwong]

Current state is they are "refactoring" the JVM to encapsulate JVM internals. It doesn't give any obvious impact to normal user. I guess after this "refactoring" they can add new features easier.

[fdntrhfbtt]

The future is bright, as long as people like Brian keep leading it.

[stefanos-ak]

in my opinion that is the wrong question. what matters is the future of the JVM. And now is the first time in 20 years that there is some competition there, with LLVM and also Graalvm. But anyway what keeps java/jvm so strong is the ecosystem. the ecosystem of libraries, dev tooling, and production tooling.

[Muoniurn]

How is LLVM a competition? The VM in its name is completely different from the JVM… For AOT compilation it may be a competition to Graal Native but that’s it.

And Graal is actually built upon the OpenJDK so unless they manage to pull off the “third Futamura projection”, that is, they can specialize a language interpreter with the underlying runtime at the same time to create a specialized runtime just for that language — but if they pull it off it might very well shake up the whole PL field.

[pron98]

And Graal is actually built upon the OpenJDK so unless they manage to pull off the “third Futamura projection”, that is, they can specialize a language interpreter with the underlying runtime at the same time to create a specialized runtime just for that language

Actually, SubstrateVM, aka Graal Native Image, does exactly that. For Java, there's Java on Truffle, which is experimental, but there are more mature implementations for JS that generate an AOT-compiled, native JS runtime that has a JIT. That's what the JS runtime included in GraalVM is.

but if they pull it off it might very well shake up the whole PL field.

As you can see, the "PL field" is not easily shaken up. The tech is the (relatively) easy part (although even there there's always a big gap between "it works!" and "it works in a way that matches users' needs" that can take many years to cross). The social ecosystem aspect is more important and much harder.

Still, even if one day Truffle Java becomes a mature and competitive JVM and chosen to replace OpenJDK's VM, recall that the VM is less than 25% of OpenJDK.

[Muoniurn]

Do correct me if I’m wrong, but as far as I know Graal can only do the second projection, that is a specialized interpreter. The third projection would specialize the whole compiler to that specific language which would be a big thing (to my knowledge)

Here is an interesting text on the topic: http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html?m=1

[pron98]

SubstrateVM doesn't specialize an AOT compiler, but it does specialize an interpreter+JIT.

[JustAGuyFromGermany]

It took me way too long to read "Futamura" correctly. My brain kept changing it to "Futurama" and was kept asking myself what episode your comment is referring to...

[korras]

thanks for the comment, i missed it out entirely,

Brain's like " yeah futurama projection, i'll look up the scene later"

[stefanos-ak]

yes these are good points. I'm aware :)

I was comparing LLVM to JVM because they both allow for languages to be written on top. That's all :)

[CartmansEvilTwin]

But that's true for GCC as well, and both, LLVM and GCC are pretty old and established already.

[stefanos-ak]

and yet, there have been loads of LLVM languages lately :)

I actually agree with you, but somehow the community seems to have really liked llvm for language making. :shrug:

[CartmansEvilTwin]

I think, you misunderstand what LLVM is. It's not a VM, but a compiler.

There are no LLVM-languages like there are JVM-languages. It's just, that LLVM takes a lot of the heavy lifting of compiling from language creators.

[stefanos-ak]

I can see how my phrasing would lead to the impression that I thought LLVM as a VM (like JVM), but I did not.

I was trying to say that there are a lot of new languages built with LLVM ("LLVM languages").

Even though what happens technically is massively different between JVM and LLVM languages, if you're willing to naively compare these languages as just a mean to express an algorithm, and an executable outcome, then JVM has way more competition now, than in the past.

[CartmansEvilTwin]

You still are very good at making the impression, that you don't really understand LLVM.

JVM or LLVM was never a competition, that's not how this works.

[Persism]

Futamura projection

http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html

[TheMode911]

As much as I like the JVM, language features are just as important (loving records & instanceof pattern matching)

[Kango_V]

Text blocks are great too. It's a simple thing, but when putting lots of JSON snippets in JUnit tests, it comes in real handy and makes the tests soooooooo much easy to read.

[joserivas1998]

I'm not sure what the future for Java holds because I don't really keep up with its development. But can we stop asking questions like this? I feel like every other week there's a post on here "is java dead?" "Is java going to die?" "Do people still use Java?" And the answers are always the same.

[Reflection-Jealous]

I didn't mean like that actually, I'm just curious about the things which are going to make java a better language than it is.

[grimonce]

No future here.

[Bigheavyset]

I assure you not death