[HN Gopher] Java 22 Released
___________________________________________________________________
Java 22 Released
Author : mkurz
Score : 259 points
Date : 2024-03-19 13:22 UTC (9 hours ago)
(HTM) web link (mail.openjdk.org)
(TXT) w3m dump (mail.openjdk.org)
| melling wrote:
| "Vector API (Seventh Incubator)"
|
| Seven iterations? What is going on with vectors in Java?
| geodel wrote:
| It will go on until 'value classes' are incorporated in Java
| voidfunc wrote:
| My understanding is it depends on Valhalla (value classes) and
| they basically keep updating it as that project changes.
| MrBuddyCasino wrote:
| The Foreign Memory API is in the works since 2014. They are
| just very diligent and careful.
| kaladin_1 wrote:
| Yeah, given the amount of legacy infra built on Java. They
| don't have the luxury to move fast and break things.
| exidex wrote:
| They said it is waiting for some feature from project Valhalla.
| Not sure which one though
| pron wrote:
| There are ad-hoc hacks in the JDK to avoid allocation for
| vectors; once we get some Valhalla features, vectors could be
| represented as plain value objects.
| GreenToad wrote:
| "Vector API" is universal api for SIMD. It will probably remain
| in incubator until valhalla delivers value types.
| packetlost wrote:
| Is there a timeline on Valhalla? I only loosely follow the
| Java ecosystem these days, but Valhalla is of particular
| interest to my performance-oriented mind.
| e3bc54b2 wrote:
| I follow up on valhalla every now and then. It looks few
| more releases away, probably not before next LTS.
|
| That being said, the amount of rigor with which the JDK
| devs test their experiments is really something to witness.
| Its equivalent to old school MS with painstaking
| maintenance at backwards compatibility, all the while
| moving the wheel of progress.
|
| Every single change so far has been planned with a decade
| of advanced planning because that's just how this ecosystem
| roles.
| neonsunset wrote:
| If you're interested, there already is a somewhat similar
| language that offers first-class support for these.
| pkphilip wrote:
| Interesting to see the developments on the String Templates API
| using the STR and fmt template processors.
| ludovicianul wrote:
| It gets interesting: https://mail.openjdk.org/pipermail/amber-
| spec-experts/2024-M...
| bberrry wrote:
| I'm really happy they are reconsidering the syntax. Thanks
| for the link
| JackFr wrote:
| > concrete syntax TBB (to be bikeshod)
|
| TIL the past participle of 'bikeshed' is 'bikeshod'.
| Tremendous.
| oaiey wrote:
| Foreign Function Interface is one of the key advantages what C#
| had over Java (e.g. against huge APIs like Android or macOS). I
| am really curious how this JEP turns out.
| soulbadguy wrote:
| The FFI is also an artifact of CLR type system and the ability
| of have proper stack value based types.
| grishka wrote:
| They will eventually bring value types to Java with Project
| Valhalla.
| layer8 wrote:
| I wonder how long it will take. We've been waiting for ten
| years already.
| kaba0 wrote:
| One design iteration already has a working, implemented
| branch available, it's just one of the hardest designs to
| get right, to remain backwards compatible, to have it
| work nice with generics and all the other features, etc.
|
| So once they actually settle on a design (which they seem
| to have closed on quite a lot in the last couple of
| years), it might not take that long to happen.
| ivan_gammel wrote:
| Looks like we may see a first preview in Java 23, i.e.
| already this year.
| int_19h wrote:
| Not just value types, but also:
|
| 1. Pointers to the same (and not just references to objects).
|
| 2. Unions (via explicit-layout structs)
|
| 3. Function pointers.
|
| 4. C-style varargs.
|
| To be fair, not all of these have been exposed in C#
| historically even though CLR had them all along. Most
| notably, unmanaged function pointers took over 20 years. And
| since most people look at CLR through the prism of C#, they
| aren't necessarily aware of these features.
|
| Still, one way or the other, we're at the point where pretty
| much any C program can be transpiled to C# in a one-to-one
| mapping of almost every construct (setjmp/longjmp has to be
| emulated with exceptions), and a very similar performance
| profile of the resulting code.
| neonsunset wrote:
| Honorable but important mentions:
|
| 5. Stackalloc (C alloca), fixed buffers in structs and
| inline arrays
|
| 6. ref T and Span<T>, which act just like &mut T and &mut
| [T] in Rust (with the same syntax). They are used in both
| advanced and most basic APIs alike to provide zero-cost
| wrapping and/or slicing of arbitrary memory (managed heap,
| stack, NativeMemory.Alloc'd)
|
| e.g. You can receive byte* and length from FFI and
| construct a (ReadOnly)Span<byte> from them. That span then
| can be passed to almost every method that used to work with
| arrays only during .NET Framework days.
| merb wrote:
| Sadly records are not value types, maybe Java will do this
| better, but I doubt it. Valhalla is probably years away.
| neonsunset wrote:
| Small correction: FFI in Android land is abysmal, to get decent
| performance when accessing all kinds of system APIs you almost
| always end up having to write helpers in Java, to try to
| alleviate the pain of JNI as much as possible (it is still
| significant).
|
| Interop with iOS OTOH is a breeze, some of the APIs may require
| newer Swift Library Evolution ABI (direct calls to Swift
| exprots, without going through C/objC) but .NET is getting it
| in .NET 9 (the first and only platform to have it at the moment
| of release).
| pron wrote:
| Calling Android "Java" has always been a stretch. Not only
| has Android never been compatible with any version of Java,
| the divergence between Android and Java is only growing. JDK
| 22 is Java; Android is Android.
| neonsunset wrote:
| That is true, for all intents and purposes however the glue
| code to (insufficiently) reduce marshalling and FFI
| overhead is written in Java the language, even if it does
| not use OpenJDK.
| pron wrote:
| Okay, but we're not talking about OpenJDK but about Java,
| a specification -- not an implementation like the OpenJDK
| JDK -- that Android has never conformed to and from which
| it is only growing further apart. I.e. the OpenJDK JDK is
| an implementation of Java; Android is not (there
| certainly may be _some_ Java code that happens to behave
| the same way on Android, but it is not, and has never
| been, the case for Java code generally). The relationship
| between Java and Android is similar to that between Linux
| and Unix -- lots of intended similarities, but there
| shouldn 't be an expectation that a new Linux feature
| appears in, say, AIX or vice-versa.
| pjmlp wrote:
| At least they were forced to accept how much Android
| ecosystem depends on Java and now Java 17 LTS is the
| latest supported version, minus the stuff they never
| supported like Swing and Java 2D.
| cxr wrote:
| Calling Android Java is certainly a stretch, but aside from
| Sun/Oracle folks, I don't ever see anyone do that. Android
| is Android, Java is Java, and Android is written in Java.
|
| If the language of the non-standard, deliberately
| ES262-incompatible NodeJS programming system (and GraalJS,
| for that matter) is called "JS" without anyone batting an
| eye--which it does--it's pretty silly to insist the
| language of Android isn't Java.
| adra wrote:
| I started to tinker with this new API last week. I definitely
| think it's a lot better than needing to self compile a lot of
| the bindings yourself which will certainly bring more from the
| community into the feature than were here before.
|
| That said, you really need to write a bunch of boiler-plate to
| implement useful things in java-like paradigms in the library
| today. Just as an example, I wrote up a sane windows _getcwd()
| stub and it's like 30 lines to implement correctly (properly
| freeing the buffer when I'm down with it)
|
| My pet project is to see if I can write automatic stubs around
| calls based on published API info and sources, so that at least
| some of that platform binding lift isn't just for those with
| non-trivial knowledge of C. Well, that's the hope anyways.
| schoenobates wrote:
| I've been quite keen on the new FFI too - apologies if this
| is old news, but have you tried the [0] jextract stuff for
| some of the boilerplate gubbins?
|
| [0]: https://github.com/openjdk/jextract
| adra wrote:
| No! Thanks for the callout! That would certainly help on my
| path. My main goal was to insulate calls to avoid overly
| complicated reference counting when integrating large
| native surfaces into as Java program, but certainly an
| important aspect is getting the function signatures to
| target in the first place. I threw something bad together
| to work sort of like this (testing using proton), but I'm
| more than happy to bin it for something that just-works.
| ackfoobar wrote:
| It worked great for me. I had long wanted to rewrite a Python
| lib in Kotlin, since the Python part of the lib is slow, and it
| does not support multi-threading.
|
| But the ugliness of JNI stopped me. Then I tried FFI in Java
| 21, with jextract it was amazing.
|
| I wasn't aware of FFI at first, but the finalized version of
| virtual threads made me check the Java release notes.
| MaxBarraclough wrote:
| For anyone reading, here's a link to the page with detail on
| this project: https://openjdk.org/jeps/454
| grumpydude wrote:
| Unrelated to Java, but it's so refreshing to see a simple HTML
| page for once
| didip wrote:
| Sweet, G1 keeps getting better for free. Time to cut a new build
| tag for this.
| ecshafer wrote:
| It isn't a "Sexy" PL change, but a full foreign function
| interface will be a huge change. In my experience, relying on the
| old java JNI based libraries seems to be one of the biggest
| things that break in upgrades. So I am hoping this will reduce
| the maintenance burden of Java.
| DarkNova6 wrote:
| Boring changes like these are what keeps Java interesting.
|
| New and shiny syntax sugar becomes stale real quick.
| owlstuffing wrote:
| As a modern language Java is still quite feature deficient.
| But you can use compiler plugins like the manifold project[1]
| to level up.
|
| 1. https://github.com/manifold-systems/manifold
| wmfiv wrote:
| I see Manifold as a huge leap past previous tools
| Immutables or Lombok. I understand there's a use case where
| you want to add these language features to an existing code
| base. But for the most part if you want the language
| features on the JVM, you should probably just use Scala.
| That gives you a set of established patterns, best
| practices, libraries, and a community of users.
|
| If you want type safe SQL in particular, you can pry JOOQ
| out of my cold dead hands.
| krzyk wrote:
| Linkable features https://openjdk.org/projects/jdk/22/
|
| For me personally the most interesting one is JEP461 (Stream
| Gatherers) https://openjdk.org/jeps/461
|
| This will allow addition of interesting stream operations.
| jimbokun wrote:
| Maybe my favorite feature in this release:
|
| https://openjdk.org/jeps/463
|
| Finally solves the inscrutable Hello World program!
|
| Yes, it's just ergonomics for early beginners. But could be the
| difference in whether or not someone new to programming sticks
| with Java or not.
| kyawzazaw wrote:
| love this!
| carimura wrote:
| The thought process leading up to this work
|
| https://openjdk.org/projects/amber/design-notes/on-ramp
| coldpie wrote:
| I 1000% agree. Though, a favorite early programming memory of
| mine was when static methods finally clicked and I went back
| and looked at all that boilerplate that meant nothing to me and
| it all became crystal clear what it meant and why it had to be
| like that.
| lotsoweiners wrote:
| That sounds a lot like Top-level Statements in the .Net world.
| Personally I don't use that feature because I'm old and get
| confused if things are magic but can certainly see the benefit
| for the newer devs.
| starik36 wrote:
| Yeah, no doubt inspired by the .NET feature. I use it all the
| time for throwaway console apps.
| Almondsetat wrote:
| My first Java programming course went over in detail about that
| piece of code and in a couple of hours taught me a lot of
| important Java concepts right away. Consider me not enthused
| about it.
| whitehexagon wrote:
| Simple code like that kept pulling me back to the JSL 1.0
| spec time and time again as my understanding deepened, much
| like the old singleton pattern debates of old.
| AtlasBarfed wrote:
| Java continues to evolve to a bad Groovy.
| bheadmaster wrote:
| Groovy itself is a bad Groovy.
| AtlasBarfed wrote:
| bad opinion is bad
|
| I get gradle is a disaster (but that's more of a poorly
| managed and evolved DSL problem)
|
| But ... does anyone use Spock and think "groovy sucks"?
| Yeah, I doubt it.
| ulrikrasmussen wrote:
| How so? I don't think there are many good things to say about
| Groovy, but I generally agree with most new features
| introduced to Java. What do you think Groovy does better?
| AtlasBarfed wrote:
| - String interpolation
|
| - triple-quote strings / blocks
|
| - minimal class boilerplate (this posting)
|
| - closures (Java closures are worse IMO)
|
| - usable hashbang for UNIX
|
| - I think java has strings in switch now, don't they? Do
| they have expressions?
|
| WAIT, does Java STILL force you to write getter/setters?
| mbfg wrote:
| features that make strings easier to use are bad in my
| opinion. the number one problem in java is people
| circumventing the type system with strings.
|
| switch on strings is there, as are switch expressions.
|
| records now removes the need for getters in immutable
| contexts.
| bheadmaster wrote:
| Good that they got rid of the class/public static void/string[]
| Args boilerplate, but if they just went one step forward and
| declared implicit main function as top-level scope of a file,
| we could've got to a Python level of tersity. Just imagine!
| System.out.println("Hello world!");
| aidos wrote:
| To be _that_ guy, not _quite_ a python level of tersity!
| int_19h wrote:
| They almost caught up with C#, which ditched requisite class
| declarations years ago. Although C# went one step further and
| allowed top-level code outside of methods, so that hello world
| is now: Console.WriteLine("Hello, world!")
| TillE wrote:
| It has been a few years, but top-level statements in C# are
| still a fairly recent thing (C# 9 in 2020).
| johnyzee wrote:
| You can write write code outside of methods in a Java class,
| called an initializer block: class MyClass {
| { System.out.println("Hello World!"); }
| }
|
| This will run when an object of the class is instantiated. So
| not useful for the case in question (you could get rid of the
| class declaration but would presumably still need a main
| method).
|
| (It's also pretty poor style, but occasionally useful in a
| pinch, like when instantiating an anonymous inner class,
| which has no constructors that take arguments)
| HackerThemAll wrote:
| C#'s got even better version of this feature since Nov 2021.
| Hello world is just a true one-liner.
|
| https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
| sireat wrote:
| Actually a nice feature.
|
| This solves the public static void main string args issue.
|
| Still if I need JVM then Scala or Kotlin are still preferable
| over Java.
|
| Obligatory Java for the Haters in 100 Seconds:
| https://www.youtube.com/watch?v=m4-HM_sCvtQ
| willsmith72 wrote:
| I've never seen a java codebase I thought couldn't be better
| in kotlin
| aembleton wrote:
| Maybe in another ten years they'll remove System.out.println
| and allow for a simple println to be used.
|
| Or maybe we'll all move to Kotlin by then.
| chopin wrote:
| You can statically import System.out if you are so inclined.
| aembleton wrote:
| You can but for a new user that is even more of a barrier
| than writing out System.out.println
| gdejohn wrote:
| this will probably show up in java 23, ctrl + f "simpleio"
|
| https://openjdk.org/jeps/8323335
| bitwize wrote:
| This is exactly what I've been calling the "public static void
| main problem" for years (and an illustration of why I thought
| something like BASIC or Python should be everyone's first
| programming language). Neat to see the Java team come up with a
| solution for it. But "public static void main" runs deeper, and
| has to do with immediacy: shortening the time between the
| programmer giving instructions to the computer and seeing the
| results of those instructions being executed. It makes the
| smallest possible Java program greatly simpler and absent
| unusual comments that beginning programmers might struggle
| with; but there's the issue of the _compilation_ step as well!
| If they make Java REPL-driven they might well have a winner!
| cgijoe wrote:
| So does this fix the crashing issue with macOS Sonoma 14.4?
| https://arstechnica.com/gadgets/2024/03/usb-hubs-printers-ja...
| kaba0 wrote:
| I doubt Oracle would fix it, as this is definitely a kernel bug
| that breaks userspace. It is part of the POSIX spec what the
| JVM relies on, and MacOS is supposedly POSIX-compliant. So it
| should be Apple that fixed their bug.
| jmyeet wrote:
| Examples [1] of these features.
|
| [1]: https://www.happycoders.eu/java/java-22-features/
| preommr wrote:
| It's kind of startling to see how many places still use Java 8,
| estimated at ~1/3 of projects according to a survey i just
| googled. And something like half that still use java 11.
| BroomOfSYS wrote:
| Unbelievable! It is a strong signal that people don't care and
| technical leadership is bad. Always the nonsense excuses of
| having to work on a "legacy" codebase for more than ten years
| with a team of 3 developers and 4 analysts.
| MBCook wrote:
| 8 reached EOL in the last year or two. I think 11 is still
| under LTS.
|
| Part of the problem is the changes made between 8 and 17 could
| be incredibly disruptive depending on your libraries.
|
| If they had stuck to not using sun.* stuff you were pretty
| safe, but a few very popular things did.
|
| Then somewhere in there a lot of the common server stuff moved
| from javax.* over to jakarta.*.
|
| Both were needed and very good, but could turn into dependency
| nightmares. So depending on your app/stack it wasn't an easy
| transition.
|
| 17 is fantastic though, especially coming from 8. I'm excited
| about what's already in 21 (latest LTS) and coming in the next
| LTS after that.
| agurk wrote:
| > 8 reached EOL in the last year or two
|
| Java 8 is still under Extended Support until 2030 (and
| indefinite sustaining support). Java 11 left Premier Support
| September 2023.
|
| "Java SE 8 has gone through the End of Public Updates process
| for legacy releases. Oracle will continue to provide free
| public updates and auto updates of Java SE 8 indefinitely for
| Personal, Development and other Users via java.com".
|
| https://www.oracle.com/java/technologies/java-se-support-
| roa...
| Nullabillity wrote:
| Oracle JDK support is not the same as OpenJDK support (for
| both better and worse).
| MBCook wrote:
| Oh that's right. My company didn't want to pay the insane
| Oracle fees to keep getting support. I think it wasn't even
| a discussion once the saw the number, but that's basically
| a rumor.
|
| So we have to stick to OpenJDK which means 8 doesn't
| receive security updates and is untenable.
| adra wrote:
| I'm dragging my new company's codebases from 8 to 17 from soup
| to nuts. It's not always just about the language update, but
| all the old legacy crust that accumulated since java 8 that
| prevented anyone else to do it. My PRs are terrible and
| necessary.
| fngjdflmdflg wrote:
| Wasn't the whole point of Java never releasing a 2.0 that there
| would never be breaking changes? Seems like something went very
| very wrong with Java if the state they are in is that the
| language refuses to make breaking changes and the developers
| refuse to take up the supposedly non breaking updates due to
| breaking changes based on the comments I'm seeing here. So the
| language never improves as much as it can and the developers
| never update anyway making the whole point of non-breaking
| changes moot.
| chungy wrote:
| Java 8 allows access to unsafe methods, which despite being
| meant for internal JDK use only, have been widely used in
| external projects. Newer Java versions do not permit the use
| of unsafe except for the JDK itself.
|
| It wasn't ever part of the public API that's promised to
| never break, and JDK developers were annoyed that it being
| used meant Java got perceived as unstable, and it's gone in
| more recent versions.
| Nullabillity wrote:
| In practice, Java is the language of legacy and Android.
|
| Java 8 keeps working, while "modern" Java keeps chasing
| mistakes like green threads. If anything, I'm more baffled by
| 9+ having a non-neglegible market share at all.
| citrin_ru wrote:
| > Java keeps chasing mistakes like green threads
|
| If by green threads you mean virtual threads in JDK 21 could
| you please elaborate why they are a mistake? I'm not a Java
| developer but from what I see new concurrency model allows to
| write much more efficient network software - OS threads are
| expensive (in terms of RAM/CPU) and to handle many thousands
| of network connections (C10k problem) you have to either
| throw a lot of hardware or use NIO (New/Non-blocking I/O)
| which is hard to code.
|
| One of reasons why Go become popular - gorutines look like
| normal threads (relatively easy to code) but more efficient.
| jsnelgro wrote:
| Why would I use Java 22 over Kotlin?
| cupofjoakim wrote:
| To me the question "Why would I use X over Y?" in programming
| space is a bit redundant. Why would I use Kotlin over Closure?
| Why would I use Groovy over Scala?
|
| Even only considering JVM languages you run in to way too many
| options for the question in itself to be worth your time as a
| serious discussion.
|
| IMO - use whatever you and your team like best and that suits
| your needs. Java is great for hiring new devs and is arguably
| the most well established in an enterprise settings.
|
| If you want an actual answer: Personal preference.
___________________________________________________________________
(page generated 2024-03-19 23:01 UTC)