Speaker Details

Stuart Marks


Stuart Marks is a Consulting Member of Technical Staff in the Java Platform Group at Oracle. He is currently working on a variety of JDK core libraries projects, including Collections, Lambda, and Streams, as well as improving test quality and performance. As his alter ego "Dr Deprecator" he also works on the Java SE deprecation mechanism. He has previously worked on JavaFX and Java ME at Sun Microsystems. He has over twenty years of software platform product development experience in the areas of window systems, interactive graphics, and mobile and embedded systems. Stuart holds a Master's degree in Computer Science and a Bachelor's degree in Electrical Engineering from Stanford University.

Collections Corner Cases

Java Language

So you think you know the Collections Framework? Sure, you can add elements to an ArrayList and put entries into a HashMap. There's a lot more to collections than that, though. The Collections Framework has a rich set of APIs with surprising depth. This session isn't a typical survey of the Collections interfaces and implementation classes. Instead, it's a deep exploration of some of the corners of the Collections Framework that will reveal some little-known features. These features can be useful and powerful, but their behavior can also be startling, leading to unexpected bugs for the unwary. Attend this session for a unique and educational look at the Collections Framework.

Scheduled on Friday from 09:30 to 10:20 in Room 9

Collection Framework
Collection Libraries

Why We Hate Java Serialization And What We're Doing About It

Java Language

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.

Scheduled on Thursday from 09:30 to 10:20 in Room 9


Ask the Java Architect

Java Language

Bring your favorite questions about Java SE and the Java Development Kit — past, present, or future — to this open Q&A session.

Scheduled on Thursday from 13:50 to 14:40 in Room 9

Java SE
Java 13
Java 14
Java 15

Talks by tracksTalks by session typesList of SpeakersSchedule