Brian Goetz is the Java Language Architect at Oracle, and was specification lead for JSR 335 (Lambda Expressions for the Java Language.) He is the author of the best-selling book "Java Concurrency in Practice" and is a frequent presenter at major industry conferences.
Java Serialization is well known to be one of the worst features of Java. It's been mentioned as such in various "Ask the Experts" panels over the past few years. Joshua Bloch's book "Effective Java" describes many dangers of serialization, and it devotes an entire chapter to the topic. But isn't this merely a recent group of Java platform designers complaining about a bad design produced by an earlier group of Java platform designers?
In fact, Java serialization was well designed for its intended purposes. In the 1990s, big topics of the day included transparent persistence of objects and distributed objects. Transparent persistence is the ability to save and restore objects without requiring explicit code in those objects. Distributed objects involves the transfer of objects and interactions among objects over a network, as in Java RMI. In the context of the late 1990s, Java Serialization supported both of these goals quite well.
The problem is that, while most of the industry has moved on from these goals, Java Serialization is still embedded deeply and pervasively into the platform. With most obsolescent features, libraries and applications can simply ignore them, and doing so poses no issues. Java Serialization is different. Code that on its face appears correct and secure might have bugs or security holes caused by the mere presence of serialization in the platform, even if that code doesn't use serialization explicitly. In many cases, it is simply not possible for high assurance code to ignore the possibility of serialization. Historically, and continuing to this day, serialization is the direct cause of many bugs and security holes in Java appplications, libraries, and in the JDK itself. Serialization thus imposes costs across the platform that cannot be ignored.
This talk is neither a tutorial on serialization, nor is it merely a rant about how bad Java Serialization is. (We can't guarantee there won't be ranting, however.) It is instead a thorough analysis of a few of the fundamental aspects of the design of Java Serialization that, in retrospect, can be considered flaws. We will then provide examples of bugs in the JDK that resulted directly from these design decisions. Informed by this analysis, we will then proceed to describe potential new mechanisms we are exploring that may eventually replace the current Java Serialization mechanism. The direction of the new mechanism is to ensure that it is well integrated with the language model, and where necessary, that the language model is enhanced to accommodate serialization.
Another strong direction is to make the mechanisms explicit in the source code. This will make it possible to verify and reason about the correctness and security of a program by examining it, without having to consider "extra-lingual" mechanisms or "magical" behavior exhibited by the current Java Serialization mechanism.
Accessing foreign (e.g. off-heap) memory from a Java application can be useful for a number of reasons, from avoiding the costs associated with garbage collection, to sharing memory across multiple processes and/or with native code. Yet, to date, the Java SE API provides no official tools for accessing foreign memory, forcing developers to cope with less than ideal solutions. One such solution, perhaps the most widely used, is the ByteBuffer API, which allows the creation of so called "direct" byte buffers --- thus allowing users to manipulate off-heap memory directly from Java.
Another, less common, avenue by which developer can access foreign memory from Java code is through the Unsafe API, which exposes several low-level functionalities to manipulate both off-heap and on-heap memory directly, and in a very efficient fashion, thanks to its clever use of JVM intrinsics.
Unfortunately, existing approaches for accessing foreign memory are far from being ideal: on the one hand, the ByteBuffer API, which has been designed after I/O use cases, suffers from several limitations --- lack of addressing space, non-deterministic deallocation to name a few --- when used as a general purpose foreign memory API; on the other hand, using the Unsafe API -- as the name implies -- is a risky business, which can result in hard JVM crashes if the API is not used correctly.
In other words, when it comes to accessing foreign memory, no optimal solution exists - and Java developers are faced with a dilemma: should they use the safe, trodded but twisted (and possibly less efficient) ByteBuffer path or should they abandon all safety guarantees and embrace the (unsupported) Unsafe API?
In this talk we paint the path to the future: a safe, supported and efficient foreign memory access API for Java. By providing a more targeted solution to the problem of accessing foreign memory, not only developers will be freed by the limitations of the existing APIs - but they will also enjoy improved performances, as the new API will be designed from the ground-up with JIT optimizations in mind - and all without sacrificing memory access safety.
Since last Devoxx, we've shipped Java 12 and 13, and Java 14 will be winding down in another month or so.
What's changed in the language in the last year, and what's coming next?
Join Java Language Architect Brian Goetz in a whirlwind tour of what’s happening in the Java language.
Scheduled on Friday from 11:40 to 12:30 in Room 8
Bring your favorite questions about Java SE and the Java Development Kit — past, present, or future — to this open Q&A session.
|Talks by tracks||Talks by session types||List of Speakers||Schedule|