8 ms·

I haven't been this excited about Java since JDK 1.2. Especially Project Loom. Virtual threads will be a game changer. A return to original Java's rallying cry

I haven't been this excited about Java since JDK 1.2. Especially Project Loom. Virtual threads will be a game changer. A return to original Java's rallying cry of programmer productivity. There's always been steady progress, sure. But it seems like Oracle is much less risk adverse. Or maybe the governance changed. Or maybe Sun, IBM, other had been holding back a lot of progress. I'd love to know the backstories. To better inform future efforts. Regardless, Java today is amazing and rapidly getting better.

chaostheory 6y ago
Isn't much of the excitement gone due to Oracle's license for its JDK?
- kasperni 6y ago
  Why? There are at least 10 other vendors that provide a free version?
- _ink_ 6y ago
  https://adoptopenjdk.net/ https://adoptopenjdk.net/ fixes most of the issues.
- pjmlp 6y ago
  No because anyone that actually works with Java knows the difference between various Java implementations.
  - nobleach 6y ago
    That might not be completely fair. In our sister organization, we had a 20 year Java veteran switch his teams to Elixir because he was concerned about Oracle's licensing. Even though it was a misunderstanding, I wouldn't assume "anyone that actually works with Java knows the difference". Furthermore, it's a little bit of gatekeeping for those who may be entirely new to understand the difference between something like OpenJ9 vs AdoptOpenJdk vs Amazon Corretto.... you get the point.
    - Splognosticus 6y ago
      Which makes sense when you think about it for a moment. Being an expert Java developer doesn't make you good at--or necessarily even interested in becoming good at--legalese.
    - pjmlp 6y ago
      I get the point that there are still people that don't get that Java is like C, with OpenJDK playing the role of ISO C. It was quite clear since the beginning, plenty of Code ONE, Devoxx, NDC, JavaZone, Jax, InfoQ talks Conferences that I expect any veteran to spend some of their learning budget, or at very least read some of the related articles on Java magazines.
- carimura 6y ago
  We hope not, and if it is, it's a misunderstanding. Java is freer and more open than it ever has been. There are many downstream builds under open source licenses, including one from Oracle at http://jdk.java.net http://jdk.java.net
  - ptx 6y ago
    > Java is freer and more open than it ever has been but pron of Oracle says, a few comments over: > No one offers free LTS ... those "free LTS" distributions you should know that you're using a JDK that's not fully maintained ... Maintaining a JDK is a lot of work ... For real support for an old version you must pay. So it doesn't sound like it's really free. If the free version doesn't get security updates you can't really use it in practice.
- krzyk 6y ago
  Why? OpenJDK is free, and if you don't need the Oracle support you don't need to use their JDK, they are almost the same except the support.
ktpsns 6y ago
I have a different impression. I have the feeling that the Java language itself stucks in it's original idioms. If there would not be other languages on the JVM, such as Kotlin, Graal.* or Clojure, I guess the Java ecosystem would percieve a long starvation/death. My impression is that languages such as JavaScript and Go gain more and more track for enterprise software stacks. They are much more multi-paradigm at heart then the Java language could be. I wonder why Java doesn't learn from C++, which reinvents itself every few years. The lambda notation in C++ is really a thing Java could easily have.
- wwright 6y ago
  Java added lambdas in Java 8. Are you thinking of something else?
  - twic 6y ago
    Indeed, Java's notation for lambdas is marginally better than C++'s, where you have to use braces and an explicit return even for tiny lambdas.
- Arcsech 6y ago
  > The lambda notation in C++ is really a thing Java could easily have. Java has had lambda expressions, with what I would describe as cleaner syntax than C++'s, since JDK 8. Is there something I'm missing that C++'s have over Java's? This has also lead to a lot of Java becoming much more functional, see especially the Stream API[0] (also added in JDK 8). I would say it's much, much easier to write functional-style code in Java than it is in Go. [0]: https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html https://docs.oracle.com/javase/8/docs/api/java/util/stream/S...
  - vbezhenar 6y ago
    Stream API is bad example of design IMO. Checked exceptions are not integrated (even if I don't like them, they're part of the language and are not going anywhere soon it seems). Simple operations require lots of ceremony (list.map(x -> x + 1) vs list.stream().map(x -> x + 1).collect(Collectors.toList())). Also Java lambdas can't change outer variables, so one have to resort to old tricks with one-item arrays. Java lambdas are just syntax sugar for anonymous class from language point of view. They're implemented differently under the hood, but they don't bring anything new to developer, they just save few lines of code which is nice, but could be much better.
_ink_ 6y ago
Is Project Loom included in JDK 15? I really would like to try it out.
- pjmlp 6y ago
  There are experimental releases. https://jdk.java.net/loom/ https://jdk.java.net/loom/
- carimura 6y ago
  Each of the projects (Loom, Panama, Valhalla, Amber, etc.) are in different stages and are intended to deliver features over time. Project Loom itself is not a single deliverable. As mentioned, you can get an early-access build of most of the work that has gone into it so far [1]. The build is based off an incomplete JDK 16 as of this comment. JDK 15 does have one JEP that is part of the path towards Loom [2]. [1] https://jdk.java.net/loom/ https://jdk.java.net/loom/ [2] https://openjdk.java.net/jeps/373 https://openjdk.java.net/jeps/373
x87678r 6y ago
> Virtual threads will be a game changer. I never really understand this. Tasks and threadpools work great. Are you excited that you can reduce memory usage? I have never been restricted before.
- specialist 6y ago
  I really liked Ron Pressler's [1] presentation on his work. The details from the Q&A really helped me. https://youtu.be/23HjZBOIshY?t=152 https://youtu.be/23HjZBOIshY?t=152 This is good too. https://archive.fosdem.org/2020/schedule/event/loom/ https://archive.fosdem.org/2020/schedule/event/loom/ I'll butcher it, but my TLDR is: Program sequentially, get threading for free. Any blocking calls are now async under the hood. [1] aka @pron or https://news.ycombinator.com/user?id=pron https://news.ycombinator.com/user?id=pron
- pron 6y ago
  I tried explaining that here: https://inside.java/2020/08/07/loom-performance/ https://inside.java/2020/08/07/loom-performance/
  - x87678r 6y ago
    Thanks I'm honored you're replying. :) Looks like performance improvement will be nice.
  - Traubenfuchs 6y ago
    Do you know if Loom has any implications for reactive frameworks, like reactive spring? Or do they already contain a... "non native" implementation of this concept? https://spring.io/reactive https://spring.io/reactive
    - pron 6y ago
      With Loom, the simple, blocking, non-reactive frameworks (like Spring MVC) should give you similar throughput to the reactive ones -- that's the main impact. I don't know how reactive frameworks intend to make use of Loom.
deleted 6y ago
[deleted]
carimura 6y ago
Nice. We talk about this quite a bit. Start with https://inside.java https://inside.java and https://inside.java/podcast https://inside.java/podcast. There are lots of reasons for the continual stream of innovation but the biggest change has been the 6-month release cadence.
abraxas 6y ago
Will the virtual threads be blocked on I/O calls though? It's usually the most common reason threads wait idle. If the implementation is just syntax sugar laid on top of an existing thread pool that can be exhausted by blocking I/O calls then I'd call it a nice evolution but not very groundbreaking.
- bilbo0s 6y ago
  Will the virtual threads be blocked on I/O calls though? No. All automagically handled for you. Just write what looks a lot like regular code. Now, can you change the default behavior? Yes, but now you're on your own.
pron 6y ago
Investment in Java slowed down in Sun's dying days. Oracle has increased the investment considerably.
Yeroc 6y ago
What's funny is there were versions of the JVM for Sparc way, way back in time (Java 1.1) that had so-called green threads which were multiple threads mapped to a single (or multiple) native threads.
- lokedhs 6y ago
  I think you may be confusing two different concepts here, which is understandable given the fact that this happened some 23 years ago. The first versions of Java only had green threads. That was a cooperative threading model where only a single OS thread was used and the VM did a context switch while blocking for IO (in essence, every method declared as throwing InterruptedException could potentially context switch). The mixed model you were talking about is most likely the threading model of Solaris where threads were split into a userspace part and a kernel part. It was possible to configure pthreads so as to use a multiple userspace threads on top of a single kernel thread (in a similar way as green threads worked in Java). It was also possible to run it in a one-to-one configuration or a version where you had a large number of userspace threads mapped to a smaller number of kernel threads. The last model was default in Solaris for a long time. Eventually it was discovered that kernel threads were so fast in Solaris that there was practically never any benefit to the thread-pool model, and by Solaris 2.6 (I think, it's been a while so I could be wrong about the version) they changed it so that the default thread model was one-to-one.
MichaelMoser123 6y ago
virtual threads are go routines in java. in golang they made a huge difference - for example you can have low overhead generators http://www.golangpatterns.info/concurrency/generators http://www.golangpatterns.info/concurrency/generators (go routines is one of the selling points of the go language/runtime).

chaostheory 6y ago

Isn't much of the excitement gone due to Oracle's license for its JDK?

kasperni 6y ago
Why? There are at least 10 other vendors that provide a free version?
_ink_ 6y ago
https://adoptopenjdk.net/ https://adoptopenjdk.net/ fixes most of the issues.
pjmlp 6y ago
No because anyone that actually works with Java knows the difference between various Java implementations.
- nobleach 6y ago
  That might not be completely fair. In our sister organization, we had a 20 year Java veteran switch his teams to Elixir because he was concerned about Oracle's licensing. Even though it was a misunderstanding, I wouldn't assume "anyone that actually works with Java knows the difference". Furthermore, it's a little bit of gatekeeping for those who may be entirely new to understand the difference between something like OpenJ9 vs AdoptOpenJdk vs Amazon Corretto.... you get the point.
  - Splognosticus 6y ago
    Which makes sense when you think about it for a moment. Being an expert Java developer doesn't make you good at--or necessarily even interested in becoming good at--legalese.
  - pjmlp 6y ago
    I get the point that there are still people that don't get that Java is like C, with OpenJDK playing the role of ISO C. It was quite clear since the beginning, plenty of Code ONE, Devoxx, NDC, JavaZone, Jax, InfoQ talks Conferences that I expect any veteran to spend some of their learning budget, or at very least read some of the related articles on Java magazines.
carimura 6y ago
We hope not, and if it is, it's a misunderstanding. Java is freer and more open than it ever has been. There are many downstream builds under open source licenses, including one from Oracle at http://jdk.java.net http://jdk.java.net
- ptx 6y ago
  > Java is freer and more open than it ever has been but pron of Oracle says, a few comments over: > No one offers free LTS ... those "free LTS" distributions you should know that you're using a JDK that's not fully maintained ... Maintaining a JDK is a lot of work ... For real support for an old version you must pay. So it doesn't sound like it's really free. If the free version doesn't get security updates you can't really use it in practice.
krzyk 6y ago
Why? OpenJDK is free, and if you don't need the Oracle support you don't need to use their JDK, they are almost the same except the support.

ktpsns 6y ago

I have a different impression. I have the feeling that the Java language itself stucks in it's original idioms. If there would not be other languages on the JVM, such as Kotlin, Graal.* or Clojure, I guess the Java ecosystem would percieve a long starvation/death. My impression is that languages such as JavaScript and Go gain more and more track for enterprise software stacks. They are much more multi-paradigm at heart then the Java language could be. I wonder why Java doesn't learn from C++, which reinvents itself every few years. The lambda notation in C++ is really a thing Java could easily have.

wwright 6y ago
Java added lambdas in Java 8. Are you thinking of something else?
- twic 6y ago
  Indeed, Java's notation for lambdas is marginally better than C++'s, where you have to use braces and an explicit return even for tiny lambdas.
Arcsech 6y ago
> The lambda notation in C++ is really a thing Java could easily have. Java has had lambda expressions, with what I would describe as cleaner syntax than C++'s, since JDK 8. Is there something I'm missing that C++'s have over Java's? This has also lead to a lot of Java becoming much more functional, see especially the Stream API[0] (also added in JDK 8). I would say it's much, much easier to write functional-style code in Java than it is in Go. [0]: https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html https://docs.oracle.com/javase/8/docs/api/java/util/stream/S...
- vbezhenar 6y ago
  Stream API is bad example of design IMO. Checked exceptions are not integrated (even if I don't like them, they're part of the language and are not going anywhere soon it seems). Simple operations require lots of ceremony (list.map(x -> x + 1) vs list.stream().map(x -> x + 1).collect(Collectors.toList())). Also Java lambdas can't change outer variables, so one have to resort to old tricks with one-item arrays. Java lambdas are just syntax sugar for anonymous class from language point of view. They're implemented differently under the hood, but they don't bring anything new to developer, they just save few lines of code which is nice, but could be much better.

_ink_ 6y ago

Is Project Loom included in JDK 15? I really would like to try it out.

pjmlp 6y ago
There are experimental releases. https://jdk.java.net/loom/ https://jdk.java.net/loom/
carimura 6y ago
Each of the projects (Loom, Panama, Valhalla, Amber, etc.) are in different stages and are intended to deliver features over time. Project Loom itself is not a single deliverable. As mentioned, you can get an early-access build of most of the work that has gone into it so far [1]. The build is based off an incomplete JDK 16 as of this comment. JDK 15 does have one JEP that is part of the path towards Loom [2]. [1] https://jdk.java.net/loom/ https://jdk.java.net/loom/ [2] https://openjdk.java.net/jeps/373 https://openjdk.java.net/jeps/373

x87678r 6y ago

> Virtual threads will be a game changer. I never really understand this. Tasks and threadpools work great. Are you excited that you can reduce memory usage? I have never been restricted before.

specialist 6y ago
I really liked Ron Pressler's [1] presentation on his work. The details from the Q&A really helped me. https://youtu.be/23HjZBOIshY?t=152 https://youtu.be/23HjZBOIshY?t=152 This is good too. https://archive.fosdem.org/2020/schedule/event/loom/ https://archive.fosdem.org/2020/schedule/event/loom/ I'll butcher it, but my TLDR is: Program sequentially, get threading for free. Any blocking calls are now async under the hood. [1] aka @pron or https://news.ycombinator.com/user?id=pron https://news.ycombinator.com/user?id=pron
pron 6y ago
I tried explaining that here: https://inside.java/2020/08/07/loom-performance/ https://inside.java/2020/08/07/loom-performance/
- x87678r 6y ago
  Thanks I'm honored you're replying. :) Looks like performance improvement will be nice.
- Traubenfuchs 6y ago
  Do you know if Loom has any implications for reactive frameworks, like reactive spring? Or do they already contain a... "non native" implementation of this concept? https://spring.io/reactive https://spring.io/reactive
  - pron 6y ago
    With Loom, the simple, blocking, non-reactive frameworks (like Spring MVC) should give you similar throughput to the reactive ones -- that's the main impact. I don't know how reactive frameworks intend to make use of Loom.

deleted 6y ago

[deleted]

carimura 6y ago

Nice. We talk about this quite a bit. Start with https://inside.java https://inside.java and https://inside.java/podcast https://inside.java/podcast. There are lots of reasons for the continual stream of innovation but the biggest change has been the 6-month release cadence.

abraxas 6y ago

Will the virtual threads be blocked on I/O calls though? It's usually the most common reason threads wait idle. If the implementation is just syntax sugar laid on top of an existing thread pool that can be exhausted by blocking I/O calls then I'd call it a nice evolution but not very groundbreaking.

bilbo0s 6y ago
Will the virtual threads be blocked on I/O calls though? No. All automagically handled for you. Just write what looks a lot like regular code. Now, can you change the default behavior? Yes, but now you're on your own.

pron 6y ago

Investment in Java slowed down in Sun's dying days. Oracle has increased the investment considerably.

Yeroc 6y ago

What's funny is there were versions of the JVM for Sparc way, way back in time (Java 1.1) that had so-called green threads which were multiple threads mapped to a single (or multiple) native threads.

lokedhs 6y ago
I think you may be confusing two different concepts here, which is understandable given the fact that this happened some 23 years ago. The first versions of Java only had green threads. That was a cooperative threading model where only a single OS thread was used and the VM did a context switch while blocking for IO (in essence, every method declared as throwing InterruptedException could potentially context switch). The mixed model you were talking about is most likely the threading model of Solaris where threads were split into a userspace part and a kernel part. It was possible to configure pthreads so as to use a multiple userspace threads on top of a single kernel thread (in a similar way as green threads worked in Java). It was also possible to run it in a one-to-one configuration or a version where you had a large number of userspace threads mapped to a smaller number of kernel threads. The last model was default in Solaris for a long time. Eventually it was discovered that kernel threads were so fast in Solaris that there was practically never any benefit to the thread-pool model, and by Solaris 2.6 (I think, it's been a while so I could be wrong about the version) they changed it so that the default thread model was one-to-one.

MichaelMoser123 6y ago

virtual threads are go routines in java. in golang they made a huge difference - for example you can have low overhead generators http://www.golangpatterns.info/concurrency/generators http://www.golangpatterns.info/concurrency/generators (go routines is one of the selling points of the go language/runtime).