13 ms·

JDK 19 Release Notes

264 points by ludovicianul 4y ago

fny 4y ago
It's incredible what competition can do to spur innovation. Does everyone remember how stagnant Java had become during the 6-7 era?
- pjmlp 4y ago
  It is like being busy with an aquisition, and uncertainity about the job, would be an impedement for doing software development.
  - 411111111111111 4y ago
    That too, but i think the parent is correct as well. Java has definitely increased the pace of development with gradual changes going out quicker, especially after 11.
    - dcminter 4y ago
      It's on a date-based rather than feature-based cycle since 8. I think I recall there being talk of doing that back in the Sun era at one point, but then it ended up being a multi-year wait regardless. Very much nicer this way, and although a few businesses are still stuck on 6 or 8 most places seem to be aiming to stay current with Long Term Support (LTS) releases (of which 17 is the current LTS and 21 will be the next one).
      - PaulHoule 4y ago
        We switched to 17 this summer. I am hoping that many of the things in the pipe right now are finalized for 21.
  - KptMarchewa 4y ago
    It was stagnant even before acquisition. Sun apparently focused on JavaFX trying to make Android competitor, which all failed.
    - giancarlostoro 4y ago
      To me it sucks because its a space that would get me to use Java if they had a really powerful GUI stack that is modern and feature filled. I feel like Oracle is dropping the ball not investing there. We went from having RAD IDE's that produced native UIs to everything has to be done in electron because nobody is innovating in the Desktop GUI space.
    - titzer 4y ago
      Sun put a huge amount of effort into JavaFX. It was literally hundreds of engineers.
    - pjmlp 4y ago
      JavaFX predates Android.
    - gonzo41 4y ago
      JavaFX was a missed opportunity. A bit more effort and you'd have an electron killer.
      - MattPalmer1086 4y ago
        Nobody liked cross platform UI toolkits (they just don't feel native). And all UI development was happening with web tech, where somehow the divergence didn't matter.
        KptMarchewa 4y ago
        People severely overestimate how users positively perceive native vs non-native apps. Especially since >And all UI development was happening with web tech, where somehow the divergence didn't matter. If you're 95-99% of time using non-native web technologies, why would you care about that much about rest of it being native?
  - chrisjc 4y ago
    It's been a long time since I thought about this, but wasn't IBM really the one pushing and innovating Java (not just EE)?
    - pjmlp 4y ago
      IBM has done some innovations of their own implementation, which nowadays lives on as OpenJ9. Some of the innovations were value types extensions, AOT compilation or JIT caches, and until OpenJ9 came to be, that usually was only available to commercial clients.
- eventhorizonpl 4y ago
- geodel 4y ago
  Someone has to have money to spend. Sun did not have much money during 6-7 era.
- josefx 4y ago
  The 6-7 era was as far as I remember blocked by the community process, as there was a dispute over open source Java implementations and the restrictions in Suns certification process (no embedded use without license). Sun instead invested time and money into OpenJDK, which probably also pissed of a lot of people that wanted free reign over their Java implementations without having Sun or the GPL dictating terms.
- pron 4y ago
  I don't think Java has ever faced as much serious competition as it did circa 2005 from PHP and Ruby. What caused Java's stagnation was Sun's decline (which both reduced resources as well as made some big missteps), and as Oracle ramped up the investment in Java, we were able to get back to the roadmap (as well as come up with new ideas).
  - mwcampbell 4y ago
    Do you not think Node.js in the 2010s was serious competition? After all, it combined the dynamism of something like PHP with a high-performance VM built by (IIUC) former HotSpot devs.
    - pron 4y ago
      Yeah, you're right. Anyway, my point is that what caused Java's stagnation is not lack of competition, and what's caused its resurgence is not greater competition. Both were just a matter of resources.
- fulafel 4y ago
  The slow period helped other JVM languages - Clojure, Scala and Kotlin - which are now preferred by many. A fortunate stagnation I think.
Tomte 4y ago
Not officially announced. What's ready to download is the release candidate from Saturday: https://jdk.java.net/19/ https://jdk.java.net/19/
- ludovicianul 4y ago
  Yes. But today is official release day.
  - deleted 4y ago
    [deleted]
nhoughto 4y ago
Virtual threads preview! The beginning of a big change to java!
- kungfufrog 4y ago
  This is the feature I've been waiting for. Bring on the era of the loom!
dbrgn 4y ago
Nice new language features for Java users! sobs in Android-Java8
- nine_k 4y ago
  Android? Why not Kotlin then?
  - waynesonfire 4y ago
    Java 8 is fine and the argument to replace it with kotlin has to be very compelling. Kotlin was designed to replace Java 1.6 and that's about all it's good for.
    - cies 4y ago
      > Kotlin was designed to replace Java 1.6 and that's about all it's good for. Not sure what K was designed for. But we use it to fix J's billion dollar "implicit nulls" mistake, and terse syntax (making it useful for templating: Kotlinx.html), and pass-as-value method references. We love it's hang towards immutability. K is not Haskell, but it sure feels a lot safer that J (where a lot of strings were used to refer to methods, and strings+Groovy was used to do templates). Bottom line: I'm too old --and life's too short-- for NPEs.
      - flatiron 4y ago
        Have your tried static analysis? When I used Java most (if not all) of our NPE problems were pointed out by sonar qube
        ris58h 4y ago
        What if I don't want to put @Nullable/@NotNull all over the code?
        seer-zig 4y ago
Nullabillity 4y ago
Looks like they just won't stop digging the Loom hole deeper, huh.
- royjacobs 4y ago
  Why is it a "hole"?
royjacobs 4y ago
The first release to contain bits for Project Loom (the "virtual threads" part of the release notes). That is extremely exciting, since it is designed in a way that mostly allows drop-in replacement of existing threading and thread pool code, without requiring an utterly different programming model like async, coroutines or reactive programming do.
- likeabbas 4y ago
  I wish more languages would have gone this route (looking at you, Rust)
  - amaranth 4y ago
    Rust started on this route but decided easy C interop and no required runtime were more important and trying to have everything made green threads slower than native threads.
    - likeabbas 4y ago
      They wouldn’t have had to include a runtime. They just needed to set a standard interface for kernel threads and user threads and then the community could’ve built the runtimes in libraries like they’re currently doing. But they didn’t create those interfaces early enough so the community built them and now the async ecosystem is so fragmented you can’t build libraries generically for async runtimes or for both async and sync
      - pkolaczk 4y ago
        > is so fragmented you can’t build libraries generically for async runtimes How does futures.rs work generically with different async runtimes then?
        likeabbas 4y ago
        It doesn't work for all async runtimes like Monoio
QuadDamaged 4y ago
So... Green threads are back?
- sideeffffect 4y ago
  But they are being multiplexed on more than one Platform thread this time.
- Quekid5 4y ago
  There's a lot more to it than that. Loom is Actually Useful Green Threads^TM.
dang 4y ago
Related: Java record pattern matching in JDK 19 - https://news.ycombinator.com/item?id=31378896 https://news.ycombinator.com/item?id=31378896 - May 2022 (155 comments) Using Java's Project Loom to build more reliable distributed systems - https://news.ycombinator.com/item?id=31314006 https://news.ycombinator.com/item?id=31314006 - May 2022 (91 comments) JEP proposed to target JDK 19: 425: Virtual Threads (Preview) - https://news.ycombinator.com/item?id=31236855 https://news.ycombinator.com/item?id=31236855 - May 2022 (212 comments) Achieving 5M persistent connections with Project Loom virtual threads - https://news.ycombinator.com/item?id=31214253 https://news.ycombinator.com/item?id=31214253 - April 2022 (145 comments) Loom: Project Loom Early-Access Builds - https://news.ycombinator.com/item?id=28191308 https://news.ycombinator.com/item?id=28191308 - Aug 2021 (76 comments) Project Loom and Structured Concurrency - https://news.ycombinator.com/item?id=25300233 https://news.ycombinator.com/item?id=25300233 - Dec 2020 (108 comments) Project Loom: Fibers and Continuations for the Java Virtual Machine - https://news.ycombinator.com/item?id=15599854 https://news.ycombinator.com/item?id=15599854 - Nov 2017 (41 comments)
- mwcampbell 4y ago
  Any previous coverage of JEP 424 (Panama), the planned JNI alternative?
geodel 4y ago
Not sure why one would post release notes when release is not out yet. My first instinct would be to download and try out new features, but its just release candidate on OpenJDK site.
- sgift 4y ago
  Not sure if it was there 2 hours ago, but you can download GA now: https://jdk.java.net/19/ https://jdk.java.net/19/
moondowner 4y ago
I'm mostly excited about JEP 405: Record Patterns + JEP 425: Virtual Threads. https://openjdk.org/jeps/405 https://openjdk.org/jeps/405 https://openjdk.org/jeps/425 https://openjdk.org/jeps/425
d4a 4y ago
Seems like Java is ported to RISC-V on Linux now
Pet_Ant 4y ago
AFAICT there is no major language changes released in JDK 19, only previews.
jxi 4y ago
Is it faster?
carimura 4y ago
Loom is the talk of the town (for great reasons!), but let's not forget about Project Amber and Record Patterns [1] ... there's an arc of features moving the platform towards a data-oriented programming model. Brian Goetz talks about this quite a bit [2] including the latest 19 launch podcast [3]. [1] https://openjdk.org/jeps/405 https://openjdk.org/jeps/405 [2] https://inside.java/u/BrianGoetz https://inside.java/u/BrianGoetz [3] https://inside.java/2022/09/20/podcast-026 https://inside.java/2022/09/20/podcast-026
fniephaus 4y ago
GraalVM JDK19 dev builds are available at https://github.com/graalvm/graalvm-ce-dev-builds/releases/latest https://github.com/graalvm/graalvm-ce-dev-builds/releases/la....
hn_throwaway_99 4y ago
As someone who spent the first 15 years of their career in Java, but has been out of the ecosystem for some time now, it's cool to see Java get such big improvements, especially virtual threads. However, given the number of excellent JVM languages, especially Kotlin, I'm curious what the general consensus is for starting new projects. That is, if I were starting a greenfield project, I think I would definitely use Kotlin over Java - Kotlin doesn't have to deal with the backwards compatibility concerns of Java, and thus does away with some of the problematic annoying complexity of Java. E.g. first class language support for nullable/optional types I think is critical these days - Java has bolted on an Optional wrapper, but it's cumbersome and doesn't provide the kind of strong guarantees that a language-implemented version does. So what does the HN community think? Would you use another JVM language over Java if you were starting a new project?
- EvanKnowles 4y ago
  Actively coding in Java in a large system at the moment (so we can't Kotlin), but if I were to start a greenfields I'd give serious consideration to doing it in Kotlin.
- debug-desperado 4y ago
  If you have a small team of engineers and you need the added productivity of a more ergonomic language, then go ahead with Kotlin. In particular it's good for "lite-functional" style with OO mixed in, and your engineers get to keep all the familiarity they have with the JVM ecosystem. It's not some panacea though, and at the end of the day Java is the system language of the JVM. New VM features are not built to cater to the guest languages. In the case of virtual threads we have a directly competing "async" solution to Kotlin coroutines. So you may see further ecosystem split between libraries catering to Android and those catering to backend work.
- unregistereddev 4y ago
  I like Kotlin. However, these decisions aren't always simple - and are based on more than the technical merits of the language. Some years ago, my division at <large company> decreed Scala was the way of the future. All new development was to be done in Scala. We were offered training classes. We formed book clubs. We paired, shared, and opined as we tried really hard to do functional programming correctly. We genuinely tried, and then we gave up. The specific reasons would better suit another post, but it was a grassroots developer-led effort that led us to abandoning Scala. At this point, we have backend code in NodeJS, Scala, GoLang (this is currently a performance-sensitive one-off), and Java. That's a problem for code reuse, tooling reuse, and general maintenance. If we were to write new components in Kotlin, we would be making the problem worse. At this point in time Java is our safe fallback. In the future we may try a different language again, but for now there needs to be a really good reason to add to our tech stack. I suspect most new projects will continue to be Java for quite some time, because we're not going to rewrite all the Scala and NodeJS code "just because". It will slowly get replaced as it stops working, or as we find reasons to replace it other than "it's in a language we don't like". Until then, our polyglot set of codebases is too intimidating and devs are going to resist adding another language to it.
thayne 4y ago
I think it is funny that originally Java only had green threads, but then they were replaced with native threads, and now java is getting green threads again. Obviously a lot of development has happened in that area since, but still funny.
splix 4y ago
Does anyone know if there are any plans to improve typing and null pointer safety in future releases? I tried to google for existing JEPs, but I'm not sure I'm using the correct terms. I mean, I'd like to see better typing because the current generics are too basic, and you always end with casts and `isAssignableFrom`. Is there anyone working on types for Java, like in TypeScript and Rust? Another huge issue for me is null-type safety. The latter is basically the only reason we use Kotlin right now. We would be happy to migrate to the latest Java if it fixes the nulls. I'm wondering what prevents adding a simple syntax sugar like optional !-suffix for non-nullable definitions. Like `void fooBar(String! path)`, which should prevent at the compiler level from passing a null argument. Could that work?

264 points by ludovicianul 4y ago

fny 4y ago

It's incredible what competition can do to spur innovation. Does everyone remember how stagnant Java had become during the 6-7 era?

pjmlp 4y ago
It is like being busy with an aquisition, and uncertainity about the job, would be an impedement for doing software development.
- 411111111111111 4y ago
  That too, but i think the parent is correct as well. Java has definitely increased the pace of development with gradual changes going out quicker, especially after 11.
  - dcminter 4y ago
    It's on a date-based rather than feature-based cycle since 8. I think I recall there being talk of doing that back in the Sun era at one point, but then it ended up being a multi-year wait regardless. Very much nicer this way, and although a few businesses are still stuck on 6 or 8 most places seem to be aiming to stay current with Long Term Support (LTS) releases (of which 17 is the current LTS and 21 will be the next one).
    - PaulHoule 4y ago
      We switched to 17 this summer. I am hoping that many of the things in the pipe right now are finalized for 21.
- KptMarchewa 4y ago
  It was stagnant even before acquisition. Sun apparently focused on JavaFX trying to make Android competitor, which all failed.
  - giancarlostoro 4y ago
    To me it sucks because its a space that would get me to use Java if they had a really powerful GUI stack that is modern and feature filled. I feel like Oracle is dropping the ball not investing there. We went from having RAD IDE's that produced native UIs to everything has to be done in electron because nobody is innovating in the Desktop GUI space.
  - titzer 4y ago
    Sun put a huge amount of effort into JavaFX. It was literally hundreds of engineers.
  - pjmlp 4y ago
    JavaFX predates Android.
  - gonzo41 4y ago
    JavaFX was a missed opportunity. A bit more effort and you'd have an electron killer.
    - MattPalmer1086 4y ago
      Nobody liked cross platform UI toolkits (they just don't feel native). And all UI development was happening with web tech, where somehow the divergence didn't matter.
      - KptMarchewa 4y ago
        People severely overestimate how users positively perceive native vs non-native apps. Especially since >And all UI development was happening with web tech, where somehow the divergence didn't matter. If you're 95-99% of time using non-native web technologies, why would you care about that much about rest of it being native?
- chrisjc 4y ago
  It's been a long time since I thought about this, but wasn't IBM really the one pushing and innovating Java (not just EE)?
  - pjmlp 4y ago
    IBM has done some innovations of their own implementation, which nowadays lives on as OpenJ9. Some of the innovations were value types extensions, AOT compilation or JIT caches, and until OpenJ9 came to be, that usually was only available to commercial clients.
eventhorizonpl 4y ago
geodel 4y ago
Someone has to have money to spend. Sun did not have much money during 6-7 era.
josefx 4y ago
The 6-7 era was as far as I remember blocked by the community process, as there was a dispute over open source Java implementations and the restrictions in Suns certification process (no embedded use without license). Sun instead invested time and money into OpenJDK, which probably also pissed of a lot of people that wanted free reign over their Java implementations without having Sun or the GPL dictating terms.
pron 4y ago
I don't think Java has ever faced as much serious competition as it did circa 2005 from PHP and Ruby. What caused Java's stagnation was Sun's decline (which both reduced resources as well as made some big missteps), and as Oracle ramped up the investment in Java, we were able to get back to the roadmap (as well as come up with new ideas).
- mwcampbell 4y ago
  Do you not think Node.js in the 2010s was serious competition? After all, it combined the dynamism of something like PHP with a high-performance VM built by (IIUC) former HotSpot devs.
  - pron 4y ago
    Yeah, you're right. Anyway, my point is that what caused Java's stagnation is not lack of competition, and what's caused its resurgence is not greater competition. Both were just a matter of resources.
fulafel 4y ago
The slow period helped other JVM languages - Clojure, Scala and Kotlin - which are now preferred by many. A fortunate stagnation I think.

Tomte 4y ago

Not officially announced. What's ready to download is the release candidate from Saturday: https://jdk.java.net/19/ https://jdk.java.net/19/

ludovicianul 4y ago
Yes. But today is official release day.
- deleted 4y ago
  [deleted]

nhoughto 4y ago

Virtual threads preview! The beginning of a big change to java!

kungfufrog 4y ago
This is the feature I've been waiting for. Bring on the era of the loom!

dbrgn 4y ago

Nice new language features for Java users! sobs in Android-Java8

nine_k 4y ago
Android? Why not Kotlin then?
- waynesonfire 4y ago
  Java 8 is fine and the argument to replace it with kotlin has to be very compelling. Kotlin was designed to replace Java 1.6 and that's about all it's good for.
  - cies 4y ago
    > Kotlin was designed to replace Java 1.6 and that's about all it's good for. Not sure what K was designed for. But we use it to fix J's billion dollar "implicit nulls" mistake, and terse syntax (making it useful for templating: Kotlinx.html), and pass-as-value method references. We love it's hang towards immutability. K is not Haskell, but it sure feels a lot safer that J (where a lot of strings were used to refer to methods, and strings+Groovy was used to do templates). Bottom line: I'm too old --and life's too short-- for NPEs.
    - flatiron 4y ago
      Have your tried static analysis? When I used Java most (if not all) of our NPE problems were pointed out by sonar qube
      - ris58h 4y ago
        What if I don't want to put @Nullable/@NotNull all over the code?
        seer-zig 4y ago

Nullabillity 4y ago

Looks like they just won't stop digging the Loom hole deeper, huh.

royjacobs 4y ago
Why is it a "hole"?

royjacobs 4y ago

The first release to contain bits for Project Loom (the "virtual threads" part of the release notes). That is extremely exciting, since it is designed in a way that mostly allows drop-in replacement of existing threading and thread pool code, without requiring an utterly different programming model like async, coroutines or reactive programming do.

likeabbas 4y ago
I wish more languages would have gone this route (looking at you, Rust)
- amaranth 4y ago
  Rust started on this route but decided easy C interop and no required runtime were more important and trying to have everything made green threads slower than native threads.
  - likeabbas 4y ago
    They wouldn’t have had to include a runtime. They just needed to set a standard interface for kernel threads and user threads and then the community could’ve built the runtimes in libraries like they’re currently doing. But they didn’t create those interfaces early enough so the community built them and now the async ecosystem is so fragmented you can’t build libraries generically for async runtimes or for both async and sync
    - pkolaczk 4y ago
      > is so fragmented you can’t build libraries generically for async runtimes How does futures.rs work generically with different async runtimes then?
      - likeabbas 4y ago
        It doesn't work for all async runtimes like Monoio

QuadDamaged 4y ago

So... Green threads are back?

sideeffffect 4y ago
But they are being multiplexed on more than one Platform thread this time.
Quekid5 4y ago
There's a lot more to it than that. Loom is Actually Useful Green Threads^TM.

dang 4y ago

Related: Java record pattern matching in JDK 19 - https://news.ycombinator.com/item?id=31378896 https://news.ycombinator.com/item?id=31378896 - May 2022 (155 comments) Using Java's Project Loom to build more reliable distributed systems - https://news.ycombinator.com/item?id=31314006 https://news.ycombinator.com/item?id=31314006 - May 2022 (91 comments) JEP proposed to target JDK 19: 425: Virtual Threads (Preview) - https://news.ycombinator.com/item?id=31236855 https://news.ycombinator.com/item?id=31236855 - May 2022 (212 comments) Achieving 5M persistent connections with Project Loom virtual threads - https://news.ycombinator.com/item?id=31214253 https://news.ycombinator.com/item?id=31214253 - April 2022 (145 comments) Loom: Project Loom Early-Access Builds - https://news.ycombinator.com/item?id=28191308 https://news.ycombinator.com/item?id=28191308 - Aug 2021 (76 comments) Project Loom and Structured Concurrency - https://news.ycombinator.com/item?id=25300233 https://news.ycombinator.com/item?id=25300233 - Dec 2020 (108 comments) Project Loom: Fibers and Continuations for the Java Virtual Machine - https://news.ycombinator.com/item?id=15599854 https://news.ycombinator.com/item?id=15599854 - Nov 2017 (41 comments)

mwcampbell 4y ago
Any previous coverage of JEP 424 (Panama), the planned JNI alternative?

geodel 4y ago

Not sure why one would post release notes when release is not out yet. My first instinct would be to download and try out new features, but its just release candidate on OpenJDK site.

sgift 4y ago
Not sure if it was there 2 hours ago, but you can download GA now: https://jdk.java.net/19/ https://jdk.java.net/19/

moondowner 4y ago

I'm mostly excited about JEP 405: Record Patterns + JEP 425: Virtual Threads. https://openjdk.org/jeps/405 https://openjdk.org/jeps/405 https://openjdk.org/jeps/425 https://openjdk.org/jeps/425

d4a 4y ago

Seems like Java is ported to RISC-V on Linux now

Pet_Ant 4y ago

AFAICT there is no major language changes released in JDK 19, only previews.

jxi 4y ago

Is it faster?

carimura 4y ago

Loom is the talk of the town (for great reasons!), but let's not forget about Project Amber and Record Patterns [1] ... there's an arc of features moving the platform towards a data-oriented programming model. Brian Goetz talks about this quite a bit [2] including the latest 19 launch podcast [3]. [1] https://openjdk.org/jeps/405 https://openjdk.org/jeps/405 [2] https://inside.java/u/BrianGoetz https://inside.java/u/BrianGoetz [3] https://inside.java/2022/09/20/podcast-026 https://inside.java/2022/09/20/podcast-026

fniephaus 4y ago

GraalVM JDK19 dev builds are available at https://github.com/graalvm/graalvm-ce-dev-builds/releases/latest https://github.com/graalvm/graalvm-ce-dev-builds/releases/la....

hn_throwaway_99 4y ago

As someone who spent the first 15 years of their career in Java, but has been out of the ecosystem for some time now, it's cool to see Java get such big improvements, especially virtual threads. However, given the number of excellent JVM languages, especially Kotlin, I'm curious what the general consensus is for starting new projects. That is, if I were starting a greenfield project, I think I would definitely use Kotlin over Java - Kotlin doesn't have to deal with the backwards compatibility concerns of Java, and thus does away with some of the problematic annoying complexity of Java. E.g. first class language support for nullable/optional types I think is critical these days - Java has bolted on an Optional wrapper, but it's cumbersome and doesn't provide the kind of strong guarantees that a language-implemented version does. So what does the HN community think? Would you use another JVM language over Java if you were starting a new project?

EvanKnowles 4y ago
Actively coding in Java in a large system at the moment (so we can't Kotlin), but if I were to start a greenfields I'd give serious consideration to doing it in Kotlin.
debug-desperado 4y ago
If you have a small team of engineers and you need the added productivity of a more ergonomic language, then go ahead with Kotlin. In particular it's good for "lite-functional" style with OO mixed in, and your engineers get to keep all the familiarity they have with the JVM ecosystem. It's not some panacea though, and at the end of the day Java is the system language of the JVM. New VM features are not built to cater to the guest languages. In the case of virtual threads we have a directly competing "async" solution to Kotlin coroutines. So you may see further ecosystem split between libraries catering to Android and those catering to backend work.
unregistereddev 4y ago
I like Kotlin. However, these decisions aren't always simple - and are based on more than the technical merits of the language. Some years ago, my division at <large company> decreed Scala was the way of the future. All new development was to be done in Scala. We were offered training classes. We formed book clubs. We paired, shared, and opined as we tried really hard to do functional programming correctly. We genuinely tried, and then we gave up. The specific reasons would better suit another post, but it was a grassroots developer-led effort that led us to abandoning Scala. At this point, we have backend code in NodeJS, Scala, GoLang (this is currently a performance-sensitive one-off), and Java. That's a problem for code reuse, tooling reuse, and general maintenance. If we were to write new components in Kotlin, we would be making the problem worse. At this point in time Java is our safe fallback. In the future we may try a different language again, but for now there needs to be a really good reason to add to our tech stack. I suspect most new projects will continue to be Java for quite some time, because we're not going to rewrite all the Scala and NodeJS code "just because". It will slowly get replaced as it stops working, or as we find reasons to replace it other than "it's in a language we don't like". Until then, our polyglot set of codebases is too intimidating and devs are going to resist adding another language to it.

thayne 4y ago

I think it is funny that originally Java only had green threads, but then they were replaced with native threads, and now java is getting green threads again. Obviously a lot of development has happened in that area since, but still funny.

splix 4y ago

Does anyone know if there are any plans to improve typing and null pointer safety in future releases? I tried to google for existing JEPs, but I'm not sure I'm using the correct terms. I mean, I'd like to see better typing because the current generics are too basic, and you always end with casts and `isAssignableFrom`. Is there anyone working on types for Java, like in TypeScript and Rust? Another huge issue for me is null-type safety. The latter is basically the only reason we use Kotlin right now. We would be happy to migrate to the latest Java if it fixes the nulls. I'm wondering what prevents adding a simple syntax sugar like optional !-suffix for non-nullable definitions. Like `void fooBar(String! path)`, which should prevent at the compiler level from passing a null argument. Could that work?