[HN Gopher] Java 21: First Release Candidate
___________________________________________________________________
Java 21: First Release Candidate
Author : mkurz
Score : 96 points
Date : 2023-08-14 20:40 UTC (2 hours ago)
(HTM) web link (openjdk.org)
(TXT) w3m dump (openjdk.org)
| yafetn wrote:
| Can someone please explain how Project Loom and virtual threads
| in the JVM affect Kotlin's coroutines?
| papercrane wrote:
| It largely doesn't affect Kotlin's coroutines. Kotlin targets
| platforms where Loom is not available (e.g. Android, native.)
|
| As a developer if you're targeting the JVM with virtual threads
| you may decide to use those for some workloads instead of
| coroutines.
|
| In the future when targeting the JVM Kotlin maybe can use the
| features exposed by Project Loom to execute coroutines more
| efficiently, but it's not clear to me that there's much for
| Kotlin to gain there, maybe some small gains in performance.
| rr808 wrote:
| Looking forward to Loom so that I can stop having to work on
| these async codebases. I have no idea why people looked at nodejs
| and thought it was a good framework to copy. (Sure maybe there is
| some high performance computing unlocked but most people dont
| need it, and most teams end up with a rats next of complexity)
| trollied wrote:
| Features listed here: https://openjdk.org/projects/jdk/21/
| dang wrote:
| Thanks, we've changed the URL to that from
| https://mail.openjdk.org/pipermail/jdk-
| dev/2023-August/00805....
| mkurz wrote:
| Features can be found here: https://openjdk.org/projects/jdk/21/
| taspeotis wrote:
| No autoproperties yet?
| vips7L wrote:
| record A(B b) {}
| nabogh wrote:
| I'm a bit out of the loop on new Java features so I was reading
| https://en.wikipedia.org/wiki/Java_version_history
|
| And string templates looked exciting to me. But after skimming
| https://openjdk.org/jeps/430
|
| it sounds like they want to avoid backticks for "safety"? Like we
| can already use the plus operator to append strings why would it
| be any less safe to give us an ergonomic way to do that? Oh well,
| Java isn't exactly known for being ergonomic.
| lolinder wrote:
| The safety isn't in avoiding backticks, that's just syntax. The
| safety comes from requiring you to specify which template
| processor you're using for the template string, so it's just as
| easy to use the right processor (eventually, SQL."") as it is
| to use the wrong one (STR."").
|
| Using STR."" instead of STR.`` is just an aesthetic choice, and
| one that I think makes sense for Java.
| 60secs wrote:
| Backticks are used as literals in a lot of contexts, especially
| DBs.
|
| Overloading that behavior by default would likely blow up a lot
| of code and certainly violate the principle of least surprise.
| paulddraper wrote:
| By DBs, you mean MySQL :/
|
| No one else has such an oddity
| coldtea wrote:
| SQLite also features backticks as literals (though they're
| not the main option)
| mattbee wrote:
| How much old advice on Java concurrency will virtual threads
| change?
|
| I'm building a course for people who are new to Java concurrency
| and I've made the assumption that from September, you will almost
| always _choose_ virtual threads over platform threads. The
| default virtual thread management surely matches what most people
| want most of the time (1 worker thread per CPU core, virtual
| threads on top). It removes a lot of the old worries about
| management of thread pools and how OS thread implementation
| details "leak" into Java.
|
| It's brought it much closer to how I'd written coaching material
| for multithreading in Go, but the Executor abstractions will
| still let Java programmers shift over from platform threads at
| their own pace.
| KRAKRISMOTT wrote:
| Only for IO bound tasks, if you are doing a compute bound task
| that needs to saturate all cores, I am not sure what benefits
| virtual threads would bring.
| cogman10 wrote:
| Depends a lot on what you are doing and if you need
| preemption. There's not a huge penalty for using a virtual
| thread for compute (Other than impacting IO bound tasks).
| riku_iki wrote:
| > Only for IO bound tasks
|
| do you know any docs/examples how this can be integrated with
| current java io libraries?.
| PaulKeeble wrote:
| The trade off is going to remain the same for parallel
| algorithms, once saturated performance will gradually decline
| as swapping threads harms performance. Go for example exposes
| the CPU Core/thread count because unbounded performs worse
| even despite its apparently cheap virtual threads. I have
| tested this a number of times in Java and Go and the
| situation is similar you want to be using near the CPU count
| dependent on the algorithm and IO. It will be the same in
| Java with virtual thread, the cost of the threads will be
| lower but the optimal number likely wont change much.
| bcrosby95 wrote:
| In Java, unless they changed something in the past ~6
| months, virtual threads will not "swap out" a CPU bound
| task, you have to have some blocking, otherwise it will
| keep on chugging.
|
| Depending upon your POV this may be a positive or negative.
| You can get around it by manually inserting some sleeps() -
| note that yield() won't work (which is kinda unfortunate).
| cogman10 wrote:
| Wrangling executor services (practically) becomes an
| antipattern. Where old java you'd do a singleton threadpool,
| virtual thread java you'd pretty much never do that. In cases
| where you might be tempted to do that, the common fork join
| pool is likely the better choice.
|
| Locks become more relevant. Old java you might have limited
| concurrency using thread pool size. With virtual threads
| something like a blocking queue or semaphore is likely a better
| choice.
|
| Reactive java should be avoided (IMO). It was a decent choice
| for old java, for virtual thread java you get little benefits
| from it.
|
| This will probably change, but with old java `synchronized` was
| alright. Virtual thread java you want to avoid that.
|
| This likely won't change, ThreadLocalStorage is a bad idea with
| virtual threads, you almost certainly want to use ScopedValues
| instead.
|
| You should understand the implications of structured
| concurrency. It's not fully ready yet, but at very least the
| `try(var service = newVirtualThreadPoolExecutor)` does work (I
| believe) which will block until all tasks launched are
| completed. This is likely desirable but might be unexpected if
| you wanted to fire and forget something.
|
| Otherwise, I think all the old concurrency advice applies.
| clumsysmurf wrote:
| > Reactive java should be avoided (IMO). It was a decent
| choice for old java, for virtual thread java you get little
| benefits from it.
|
| This is interesting, we used RxJava quite a bit on Android
| until Kotlin Coroutines made things a bit easier in that the
| code read more linearly and worked nicely with built in
| language features like exceptions for error handling.
|
| Just curious if you agree with this in Java, or had other
| reasons.
| vips7L wrote:
| Even before the introduction of virtual threads RxJava
| should have been avoided.
|
| It colors your entire code base, prevents natural error
| handling, and quite frankly makes maintenance that much
| more complex.
|
| Obviously there's a place for it, but every project I've
| been on that used it shouldn't have.
| clumsysmurf wrote:
| Now would be a good time for an revised edition of JCIP (Java
| Concurrency in Practice).
| mattbee wrote:
| For sure, yes, it's from 2006! I didn't have that one to
| hand, but remember the O'Reilly "Java Threads" book from 1999
| and >50% of that was still useful for bringing a younger
| colleague up to speed.
| focom wrote:
| Beside legacy code, in what context would you start a new project
| un java?
| greymalik wrote:
| When your engineering team is experienced and proficient in
| Java and your organization has built substantial tooling to
| support it.
| beanjuiceII wrote:
| what kind of tooling?
| cogman10 wrote:
| Any tooling you could imagine for a language java has that
| + 10 other implementations. Static analysis, debuggers,
| profilers, telemetry integration, metrics integration, etc.
| And these are GOOD. Java tooling, because it's pretty old
| at this point, is fairly well polished.
| BaculumMeumEst wrote:
| lots of java shops have loads of internal libraries that
| solve organizational goals or interface with other internal
| systems. they will continue to build new projects in java
| because the cost of tossing all that out is high.
| ENGNR wrote:
| High performance, typesafe code that can be maintained by a
| large team. Also has a very well established ecosystem of
| libraries, and multiple languages to choose from (Java, Scala,
| Kotlin, Clojure, etc)
| eweise wrote:
| Projects where you need mature boring technology so that you
| can focus on building your product.
| mongol wrote:
| When you work in a company that requires reliable software
| beanjuiceII wrote:
| [flagged]
| palata wrote:
| Ever heard of Android? It's not JVM per se (it's ART), but
| given your comment I'm pretty convinced that you don't know
| the difference anyway.
|
| I would take JVM every day instead of those crappy web-based
| ElectronJS apps.
| winternewt wrote:
| Official Android language is Kotlin though.
| pessimizer wrote:
| Boomers are in their 70s. They're not everyone who is older
| than you.
| anon5226 wrote:
| Python is actually ~5 years older than Java.
| dragonwriter wrote:
| > Boomers are in their 70s.
|
| 59-77, this year, by the usual definition.
| pessimizer wrote:
| Boomers born 20 years after WWII? I feel this is Gen X
| erasure. I barely count as Gen X and I'm almost 50.
| dragonwriter wrote:
| > Boomers born 20 years after WWII?
|
| Not quite 20, the usual years for Boomers are 1946-1964.
|
| > I barely count as Gen X and I'm almost 50
|
| Gen X is 1965-1980, if you were 50 (I am) you'd be in the
| latter half of Gen X. If you are merely "almost 50"
| you're late enough, or nearly so, to be counted in the
| Xennial / Oregon Trail subgeneration at the cusp of Gen X
| and Millenial (usually counted as starting somewhere 1975
| and 1977.)
| dang wrote:
| Please don't post flamebait. We're trying for something else
| here.
|
| https://news.ycombinator.com/newsguidelines.html
| 725686 wrote:
| Any project in which you don't want to be obsolete in 6 months.
| abraae wrote:
| When your CV already has enough shiny new stuff in it, and you
| just want to get the product built on a stable, future-proof
| platform.
| gautamdivgi wrote:
| Any system that requires scale and performance and in-depth
| monitoring. The one thing about Java that most people miss is
| the javaagent based instrumentation that is exemplary. So when
| you're in trouble you always have jconsole . There's an
| excellent APM that we use called glowroot which is open source.
|
| Also what all others have mentioned below.
| [deleted]
| cogman10 wrote:
| World class garbage collectors. Well polished concurrency story
| (which gets a lot better with Java 21). Amazing JIT. Humongous
| mature ecosystem, larger than most languages. And the language
| (as of late) has been rapidly evolving to pick up new features
| and a trimmer runtime.
| Yasuraka wrote:
| You had me after the first three words
| dandiep wrote:
| I'm building a webapp backend in Python right now and the
| ecosystem compared to Java is just horrendous.
|
| * Maven (or at the very least transitive dependency management)
| is a defacto standard. While some solutions exist such as
| Poetry, there is no such as thing as a centralized repository
| with POMs that tell you all the related dependencies easily.
| And managing virtual environments feels like a huge step
| backward.
|
| * I ended up using FastAPI + Dependency Injector for the Python
| project, and while great, it is less robust, less well
| documented than things like Spring + JAX-RS
|
| * Because Python sucks at multithreading and is slow, everyone
| has a bunch of C in their libraries, so when there is a bug
| (which there will always be), it's very hard to debug. In Java
| land I can easily step through any code, including the JVM.
|
| * Lack of typing metadata - even relatively new libraries like
| the OpenAI client lack typing information, leaving you guessing
| about what data is available to work with.
|
| * SQL Alchemy is vastly inferior to Java ORM solutions IMO (no,
| I don't want to discuss ORMs...)
|
| * IDE support is still relatively primitive for pytest. Until a
| couple weeks ago, you couldn't see the output of all your tests
| in the VS Code console log until it was done executing. Or when
| you get an error, you can't just click on the stack trace to go
| to the failing line.
|
| * Lack of autogenerated API documentation, e.g. equivalent of
| Javadoc
|
| Love the Python syntax, but I still feel like I was more
| productive in Java for writing webapps. YMMV
| threeseed wrote:
| JVM has the largest and highest quality ecosystem of libraries
| of any platform.
| zx14 wrote:
| I would still pick Java any day over the vast majority of
| languages. Gigantic ecosystem, gigantic community, gigantic
| knowledge base, solid IDEs, and the list goes on.
| dang wrote:
| Recent and related:
|
| _Java 21: What's New?_ -
| https://news.ycombinator.com/item?id=37067491 - Aug 2023 (255
| comments)
| BaculumMeumEst wrote:
| will jdk21 present any opportunities for improvement in Clojure?
| like any part of core.async's implementation for example?
___________________________________________________________________
(page generated 2023-08-14 23:01 UTC)