Stuart Marks is the JDK Core Libraries project lead in the Java
Platform Group at Oracle. His areas of expertise include Collections,
Lambdas, and Streams. As his alter ego "Dr Deprecator" he also works
on Java's deprecation mechanism. Stuart previously worked on JavaFX
and Java ME at Sun Microsystems. He has over thirty years of software
platform product development experience in the areas of window
systems, interactive graphics, payments, 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.
In the last 25 years, the Java Collections Framework has become arguably the most used data structures on the planet, part of everyday life for millions of developers. And yet, the world in which the Collections Framework was designed is very different from the one we inhabit now. How should we avoid pitfalls from older paradigms, and how do we teach a 25-year-old framework to embrace current concepts? We’ll cover the following topics:
– Concurrent programming is driving Java towards a functional style, but collections were designed around in-place mutation. Does unmodifiability help? Should persistent data structures now be added? We’ll argue these questions, with examples to illustrate the tradeoffs;
– Anything as complex and long-lived as the collections framework is bound to attract controversies, which we’ll explain;
– We’ll take some examples of code using collections and improve them, discovering good practices as we go;
– The Collections Framework is fundamentally about shared abstractions. Is the current set of abstractions sufficient, and if not, what is missing? We’ll discuss some new abstractions we’re exploring for the future.
This session is for every Java developer who needs to use the collections framework – that’s every Java developer. You’ll leave with a deeper understanding of the design forces that shaped the framework, and with sharpened practical knowledge of how to get the very best from it, and some ideas for where the framework is heading.
A Java program consists of objects that have references to each other. This is called the "object graph." It's easy to set up an object graph with cycles. If you do this, some things work, but other things break, sometimes in a surprising fashion. Cyclic object graphs don't come up very often, but when they do, they often result in difficult and subtle problems. Worse, the JDK doesn't provide much help here.
Garbage collection works perfectly with cyclic object graphs. Early reference-counted GCs had problems with cycles, but modern tracing collectors handle them perfectly fine. This is a solved problem.
The picture is less rosy in other parts of the system. A cyclic object graph using records or collections often results in a stack overflow or out-of-memory error.
Java serialization claims to support cyclic object graphs. This works only in the simplest of cases. In more complex cases, deserialization will fail in subtle and unpleasant ways. There is a whole family of bug reports in the JDK Bug System that represents these different failure modes.
I'll show several examples of cyclic object graphs that cause failures, and I'll explain these failures. I'll also explain why it's very difficult for the JDK to do anything effective to prevent them.
Yet there are times when it's useful for Java applications to represent relationships that have cycles. I'll describe a set of techniques that can be used to represent cycles and that avoid the problems I've described.
Ask them anything related to the Java language with the Oracle engineers making it happen!
Searching for speaker images...