Changes:
* constant case labels must now appear before guarded patterns of the same type
* exhaustiveness checking is now more precise when sealed classes and generics mix
Changes:
* more carriers
* obtaining downcall method handles is simpler
* managing temporal dep's between resource scopes is simpler
* more general dereference API
* new API to copy Java arrays to/from memory
Start a web server that hosts files in a directory for tests/demos/experiments with `jwebserver`. It's super simple on purpose: only HEAD and GET, no support for authentication, access control, encryption, etc.
A service-provider interface for host name and IP resolution, so `javaβ.net.InetAddress` doesn't have to rely on `hosts` file or pin threads (#ProjectLoom).
Due to various flaws (unpredictable timing & threading, error-prone, security implications) finalization is deprecated for removal. To preview removal, test with `java --finalization=disabled`.
If no file encoding is specified, file APIs now use UTF-8 instead of determining a fallback from OS/user settings. Stick to old behavior with `-Dfile.encoding=COMPAT`, prepare with `-Dfile.encoding=UTF-8`.
Instead of writing demo code as text in Javadoc (which is agonizing and brittle), place it in a compiled and tested source file and then reference that or a section of it from Javadoc.
There are very few smaller API additions in #JDK18. The most noteworthy are in `Math` and `StrictMath`, which gained methods that combine division and modulo computations with rounding, for example to compute the result of 4 divided by 3, rounded up.
As always, there are plenty of security fixes (keep an eye out for @seanjmullan's post on seanjmullan.org/blog/) and performance improvements (also in the next Inside Java Newscast on youtube.com/java).
Now I'm curious to learn: What's the newest JDK version you'll be using in production in the next weeks. (Twitter polls only allow four choices, so please forgive me if you're in between or below 8. π)
π€
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
#ProjectLoom's virtual threads will make high performance in concurrent systems attainable with much simpler code. But Loom aims for even more and wants to make the code clearer and more robust by introducing *structured concurrency*.
Here's what that's all about. π§΅
Important: This is about concurrency, not parallelism. See yesterday's thread ππΎ for a more detailed distinction, but the gist is that concurrency is about processing lots of tasks that the environment throws at your system at the same time, ideally with high throughput.
* splitting and joining concurrent subtasks in different methods/classes
* little support to compose error-handling, cancellation, β¦ across subtasks
* threading structure is opaque to the runtime, which only sees independent threads
* β¦
I'm no security expert and don't know how ubiquitous this vulnerability is, but if you use Log4J 2.x, you should probably update to 2.15.x and read these:
From compact record constructors to pattern matching, from generic wildcards to chaining predicates and comparators, from jpackage to jlink - here are 11 #Java tricks handpicked from dev.java. π§΅
(Musical version of this thread: )
0/11
A #record's *canonical* constructor has one arg per component but in its *compact* form, you don't have to list them. You also don't have to (in fact, can't) assign fields, just do the checks/reassignments you need, rest happens automatically.
Serialization works great with #records, no black magic needed! The guaranteed presence of constructor parameters and accessors makes serialization work with the object model and makes it easy to create reliable serializable records.
Here are 11 improvements you get when updating to #Java16 later today: from records and type patterns to `Stream`-additions and Unix domain sockets, from creating installers to more performance and observability. π§΅ππΎ
Express in a single line that a type is just a collection of data without need for encapsulation and let the compiler do the rest:
record Range(int low, int high) { }
That results in almost the same API as the attached class. *drops mic*
#2 Type Pattern Matching
This is actually two-for-one:
* first step into pattern matching
* type patterns with `instanceof`
With a type pattern you check whether a variable is of a certain type and, if so, create a new variable of that type, so you can use it without casting.
That's a guiding light of #ProjectAmber and record serialization is the first step. The Inside Java Podcast episode on that topic with Julia Boes and @chegar999 (inside.java/2021/03/08/podβ¦) gives great insight into how it achieves that. π§΅
1/10
First, what's wrong with regular serialization? In short:
* extralinguistic mechanism (aka "magic")
* undermines encapsulation
* causes security issues
* hinders evolving code
* holds back new Java features
In long (and why it turned out that way), see attached thread.