9 ms·
Java 21: First Release Candidate
- trollied 3y agoFeatures listed here: https://openjdk.org/projects/jdk/21/ https://openjdk.org/projects/jdk/21/
- dang 3y agoThanks, we've changed the URL to that from https://mail.openjdk.org/pipermail/jdk-dev/2023-August/008059.html https://mail.openjdk.org/pipermail/jdk-dev/2023-August/00805....
- mkurz 3y agoFeatures can be found here: https://openjdk.org/projects/jdk/21/ https://openjdk.org/projects/jdk/21/
- nabogh 3y agoI'm a bit out of the loop on new Java features so I was reading https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history And string templates looked exciting to me. But after skimming https://openjdk.org/jeps/430 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.
- 60secs 3y agoBackticks 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 3y agoBy DBs, you mean MySQL :/ No one else has such an oddity
- coldtea 3y agoSQLite also features backticks as literals (though they're not the main option). And I fail to see how it's much of an oddity, as other RDBs use all kinds of BS for literals. SQL Server for example uses [square brackets]. If anything backticks have some history of being used for string literals in some languages (e.g. Javascript and Go), whereas in many others they are used for command substitution (which is not far removed from what a string literal combined with a processor does in Java).
- paulddraper 3y agoI consider them to be odd when ANSI SQL has perfectly workable identifier quoting. Different for the purpose of being different.
- scrame 3y agoyes and mysql has an enormous install base.
- lolinder 3y agoThe 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.
- focom 3y agoBeside legacy code, in what context would you start a new project un java?
- zx14 3y agoI 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.
- greymalik 3y agoWhen your engineering team is experienced and proficient in Java and your organization has built substantial tooling to support it.
- beanjuiceII 3y agowhat kind of tooling?
- cogman10 3y agoAny 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 3y agolots 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 3y agoHigh 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)
- mattbee 3y agoHow 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 3y agoOnly 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 3y agoDepends 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).
- PaulKeeble 3y agoThe 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 3y agoIn 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).
- dang 3y agoRecent and related: Java 21: What’s New? - https://news.ycombinator.com/item?id=37067491 https://news.ycombinator.com/item?id=37067491 - Aug 2023 (255 comments)
- BaculumMeumEst 3y agowill jdk21 present any opportunities for improvement in Clojure? like any part of core.async's implementation for example?
- yafetn 3y agoCan someone please explain how Project Loom and virtual threads in the JVM affect Kotlin’s coroutines?
- papercrane 3y agoIt 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.
- dangets 3y agoHere's a take from Roman Elizarov (Kotlin bias) - https://www.youtube.com/watch?v=zluKcazgkV4 https://www.youtube.com/watch?v=zluKcazgkV4 I imagine a lot of the missing structured concurrency will get built up over time on the Java side, but it is an interesting talk regardless.
- yafetn 3y agoYeah, I watched that talk (and many others from KotlinConf) but it was a bit too high level and not actionable.
- adra 3y agoIf you think about how you use os threads today, you have two main dispatcher pools, default (cpu), and IO (for IO processing). You can now swap out the discrete IO threads with a virtual thread pool instead. You can get the "infinite" IO (blocking) task benefits of virtual threads like normal java virtual thread pools while still using the same benefits of structured concurrency that coroutines grants. In reality, this will take a bunch of time to actually show much real results. We've been producing async future driven libraries for a long time, and they're generally pretty good at keeping the computer busy while sending out many concurrent IO requests. The real benefits are when these libraries start to support these virtual threads which should ideally lead to less complexity and some lesser compute overhead (my hopes). For server tasks, it may simply be reducing the total number of OS threads necessary to do the same tasks, since we won't need to depend on farming out work to work pools, so it may actually make some simpler uses of coroutines unnecessary, if I can simply receive request, process, ask blocking source for info, then respond in one virtual thread, why would I need the extra complexity/cost of coroutines for this naive use case anymore?
- rr808 3y agoLooking 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)
- EdwardDiego 3y agoVert.x?
- rr808 3y agoLol you guessed it. I actually like vertx over spring in general. the rxjava is the real problem.
- winrid 3y agoEven in Node I found the rx* libraries to be a bad abstraction and slow. I tend to just have my own observable stuff as I only want a small feature set in that regard anyway.
- porridgeraisin 3y agoYes same. I write myself a nice typed pipe() [2], and a one-after-the-other promise queue[4] whenever I need it but that's it really. I use web streams a lot. The most abstract I'm usually willing to get is using River [5] instead of array's map/filter/reduce. There seems to be an absolute obsession over these libraries now though. I assume it's fueled by every frontend library pushing functional patterns. See Effect [1] for example, it's insane how much is piled on. [1] https://effect.website https://effect.website [2] type Fun<A, B> = (a: A) => B export const pipe = <A, B>(f: Fun<A, B>) => { return { to: <C>(g: Fun<B, C>) => pipe((arg: A) => g(f(arg))), start: () => f, }; }; [4] class TaskQueue<U = any> { private pending: Promise<any> = Promise.resolve(); add = <T,>(task: () => Promise<false extends true & U ? T : U>) => (this.pending = this.pending.then(task).catch(task)); } [5] https://GitHub.com/wiselibs/river https://GitHub.com/wiselibs/river
- trhhowaway232 3y agoI'm glad Java is returning to its original design with userland threads. Java users can finally have some decent readable concurrent I/O without the blight of reactive. This is a huge win.
- invalidname 3y agoThat's not what Loom is. It uses a combination of native threading and user threads to create a hybrid mode that gives the benefits of both.
- jjtheblunt 3y agoThat sounds like Solaris threads, with userspace threads multiplexed on OS threads of course themselves multiplexed onto physical cores? (https://a.co/d/1XGdjWQ https://a.co/d/1XGdjWQ is an Amazon link to Solaris Internals)
- invalidname 3y agoPretty much. The way it is integrated is pretty novel though. It has special cases for the various low level networking APIs which uses the asynchronous versions of said APIs. This lets the threads block in a very efficient way and scale to 1M threads without much overhead. In general the overhead of a thread is around 1kb compared to the 1mb system thread overhead. That's fantastic.
- philonoist 3y agoI trying to decide between Kotlin and Java 21. Please suggest me the advantages of Kotlin over Java 21.
- fzeindl 3y agoKotlin all the time, for these reasons: * Nullsafe typing. * Nullsafe typing! * Inline extension functions for existing APIs. These are supremely useful. You can write features like locking and unlocking around a block, or try-with-resources in a one-liner, without compromising performance. * (Nested) When statements, if-else as expression etc. * Reified generics. You can actually write: "if (xy is T)" or use T::class * Nullsafe typing * Data classes * Getter/Setter syntax as property and indexing syntax. * Only unchecked exceptions Kotlin really is Java 2.0.
- p2detar 3y agoIf Android, then Kotlin, else Java. But on a serious note it’s far too complex of a decision that includes your personal situation. I have a mixed codebase of Java and Kotlin and I tend to prefer Java now. I do use Kotlin’s Data classes a lot though. That’s my favorite feauture of the language.
- kaba0 3y agoHow do they relate to Java’s records?
- p2detar 3y agoThey do have similarities, but data classes actually predate records. One can declare a data class a record by using the @JvmRecord annotation, which probably introduces some JVM benefits in how records are represented in the Java memory model. All in all you could use a Kotlin data class just like you'd use a Java record, but it gives you much more flexibility like inheritance and mutable fields.
- qlkjwenf 3y agoC# introduced async/await like 20 years ago and java still doesn't have it yet... I hope in the next 20 years they will finally find time to implement this feature.
- ysleepy 3y agoasync/await is syntactic sugar for futures/callbacks/statemachines in .net. kotlin does this for coroutines on the jvm. I think green threads are a much better was to solve the problem as its much easier to reason about and debug.
- pjmlp 3y agoThe feature that required David Fowler from ASP.NET team to write a set of guidelines because everyone still uses it wrong, and had the team experiementing with Go and Java approach during last Summer, and they aren't adding it because it is too complex to retrofit?
- kaba0 3y agoThank god. Async/await is an okay tradeoff for Rust, which lacks a managed runtime, but it is simply a bad abstraction for managed languages, where the runtime can automagically do the right thing for you without user involvement.