A lot of the code changes are from a bunch of people on the team ripping out the vestiges of the security manager from the code base. The history of the security manager (really, the Java security architecture, but I’ll just say “security manager”) is given in this article by Li Gong, in CACM Nov 2011. By the time that article was published, there hadn’t been any major enhancements to the security manager for quite some time. And in subsequent years, the security team, led by Sean Mullan, built up a head of steam to get rid of the security manager entirely. This led to its deprecation by JEP 411 in JDK 17 (September 2021) and culminated with it being permanently disabled by JEP 486 in JDK 24, which is to be released in March 2025.

Although JEP 486 is entitled “Permanently Disable the Security Manager” we’re really removing it and all of its tentacles that touched many parts of the JDK. There will still be a java.lang.SecurityManager class, and although you can create an instance of it, the system will throw an error if you attempt to enable it.

We are now reaping the benefits of the removal of the security manager. In many places in the JDK, the code is getting simpler. There’s less code, less complexity, and there may also be some startup improvements. But mainly the benefits are around the reduction in maintenance costs.

Here is an example from my contribution to this effort, which is a commit that fixes the bug JDK-8344149 “Remove usage of Security Manager from java.rmi”.

There’s a change to the sun.rmi.server.Util class in src/java.rmi/share/classes/sun/rmi/server/Util.java. The “new” code is this:

    static final int logLevel =
        LogStream.parseLevel(System.getProperty("sun.rmi.server.logLevel"));

Pretty straightforward, right? This calls System.getProperty to get the value of a system property and passes it to a parseLevel method that converts it to an int while doing some additional checking. Great.

The “old” version of this code looked like this:

    static final int logLevel = LogStream.parseLevel(
        AccessController.doPrivileged(
            (PrivilegedAction<String>) () ->
                System.getProperty("sun.rmi.server.logLevel")));

Ugh! What is this?

Essentially, the getProperty call was wrapped in a call to AccessController.doPrivileged which takes an action, a lambda in this case, and runs it in a privileged context. Why is doPrivileged necessary?

The reason we need to think about a privileged context is that getProperty requires a permission check. Why is that? System properties are used to store all kinds of information in a single data structure. Some of it is sensitive, and some of it is not. We mustn’t have a situation where untrusted code can read sensitive information from system properties. Thus, the caller’s permissions must be checked. Note that the permission isn’t simply about the ability to read system properties in general. The check is whether the code has permission to read a particular system property, in this case, the sun.rmi.server.logLevel property.

The code in the sun.rmi.server.Util class is privileged, because this and many other internal classes are loaded by the boot classloader. All code loaded by this classloader is privileged — it effectively has AllPermission. Why then is the permission check necessary? When getProperty is called, the effective privilege isn’t based just on the class that contains the immediate calling code. Instead, the effective privilege needs to take into account the calling class and all the classes that had called it. The access controller walks the call stack and intersects the permissions of all code on the call stack in order to compute the effective permissions. Note that this stack walk only subtracts permissions. Intersecting one set of permissions with another can only result in a set that is the same size or smaller; permissions can never be increased by an ordinary method call.

Now that the access controller has computed the effective permissions from the stack walk, it checks them against the permission required by getProperty to perform its action. If the required permission is present, the call succeeds. Otherwise, the access controller throws SecurityException.

(OK, if you’re lost at this point, I forgive you. But I bet you didn’t read Li Gong’s paper, did you? If you want to understand how the permissions model works, go read the paper, in particular the paragraphs in the right-hand column of page 50, starting with “Security in JDK 1.2 was rearchitected completely…” and continuing for the next several paragraphs.)

But wait — this is the initializer for a static field of the sun.rmi.server.Util class. This is just class initialization code, so why should it need a permission check? Even though this is a static initializer, there is in fact a caller. Class initialization in Java is lazy: a class is initialized at first use, by code that is using it, and that code is on the call stack. Some untrusted code somewhere might touch something in RMI that wants to use RMI’s Util class, that then causes this static field to be initialized, that then causes getProperty to be called, that in turn performs a permission check. Therefore, arbitrary code, including untrusted code, can be on the call stack at the time the getProperty permission check is performed. The getProperty permission check will thus succeed or fail depending on what code happens to be on the call stack at the time.

Left this way, the system would be terribly unreliable, because most code doesn’t know, and shouldn’t be sensitive to what code is calling it. And it doesn’t make sense for this getProperty call to care who is calling it. After all, it’s RMI code that wants to look at an RMI property to configure a log level for RMI logging. It shouldn’t matter what code is on the call stack. Therefore, this getProperty call ought to succeed no matter who did whatever action that happened to cause the sun.rmi.server.Util class to be initialized. In order for that to happen, we need to make sure that this call to getProperty sees the proper permissions, no matter who else is on the call stack.

That’s what the doPrivileged call is for. In its absence, the call to getProperty is performed on behalf of all callers on the call stack. With doPrivileged in place, the code is asserting that it is calling getProperty on its own behalf, disregarding the possibly-restricted permissions of other callers on the call stack. Effectively, what doPrivileged does is to stop the stack-walk-and-permission-intersection process at the point in the stack where doPrivileged occurs. Since the sun.rmi.server.Util class has full permissions, the effective permissions at this point are full permissions, and the permission check in getProperty will always succeed.

So, that’s why that code needed to be there when the security manager was in place. It’s not too terrible, is it? Just a couple extra lines of code?

Any individual case isn’t a terrible problem. But this was among the simplest of cases. If you look through my commit, there are some cases that are more complex. Some even have nested doPrivileged blocks. Things aren’t horrendously complex, but the extra levels of nesting add a lot of noise and make the logic of the code hard to follow.

And there were hundreds of doPrivileged calls throughout the JDK that needed to be maintained. There were also hundreds of permission checks spread throughout the JDK, such as the one inside of getProperty. This was a huge maintenance burden, and getting rid of this maintenance burden is a big relief. The extra verbosity of the code was certainly an annoyance. The real maintenance burden, however, arose from the following consideration:

Any code that calls into code that performs a permission
check must consider whether and how to use doPrivileged.

In the JDK, there are hundreds of API calls that perform permission checks. Thus, any JDK code that calls any of these APIs needs to determine whether to use doPrivileged. As you can imagine, it’s easy to forget to do this when you write some code that calls an API that performs a permission check. Over the years, this has resulted in hundreds of bugs in the JDK where somebody wrote code that called an API that performed a permission check, but forgot to put it inside of doPrivileged. Later on, somebody would stumble over the missing doPrivileged block and would need to file a bug to get it added after the fact.

Consider this query against the JDK Bug Database that looks for bugs that contain “doPrivileged”, “SecurityException”, or “permission” in the bug’s summary line. As of this writing, it returned nearly 500 hits. This is isn’t a precise measurement of the “missing doPrivileged” pathology, but it’s safe to say that this and related permissions maintenance were the cause of hundreds and hundreds of bugs over the years.

I did another query on the bug database, and I found about 90 commits that had to do with security manager cleanup, resulting in a net deletion of over 14,000 lines of code. (This doesn’t include the removal of the security manager itself, just the post removal cleanups.) Usually code gets bigger and more complex. It’s a rare treat for code to get smaller and simpler. Permission checking and handling of privileged operations were a continuing maintenance burden on the JDK code. It’s good be rid of it.

Credit to Maurice Naftalin for suggesting the title of this blog.

No generative AI was used in the creation of this article.

Anyway, my favorite feature is that Javadoc search now has a URL.

So what? Javadoc has had searching since JDK 9. Here’s what searching looks like in JDK 17:

(Why am I searching for LinkedList? Shut up.)

Anyway, searching javadoc is great: you click in the Search box, type some text, a menu of hits pops up, you click on the item that you’re interested in, and it takes you there. What could be better than that?

Here’s what searching is like in JDK 21:

It’s pretty much the same as before, but with this “Go to search page” link at the bottom. What does that do? It takes you to this page:

All right, it’s the same search results in a regular browser window instead of a menu-like popup. What’s the big deal?

The big deal is that this page has a URL. And URLs are the API for the web. Once something has a URL, you can program it. This URL has a query string with a simple syntax: after the ?q= you can put whatever string you want javadoc to search for. Opening this URL searches for the string and immediately displays the results.

This is a very big deal.

This means you can write a program that generates the URL for whatever you want to search for and then you can ask a browser to open this URL. For example, on a Mac, you can provide a URL to the open command and it will ask the system default browser to open that URL. I have a little shell script named jd that does this:

open "https://docs.oracle.com/en/java/javase/21/docs/api/search.html?q=$*"

This opens javadoc search on whatever I supply as command-line arguments. Why $*? Sometimes it’s useful to search for multiple words. Try this for example:

jd value based

In Firefox (and maybe other browsers too, I’m not sure) it’s possible to set up a bookmark so that you can type a keyword into the address bar and have it expand into the URL from the bookmark. If the URL has a %s in it, it will be replaced with whatever text you typed after the keyword in the address bar.

I created a bookmark whose URL is

https://docs.oracle.com/en/java/javase/21/docs/api/search.html?q=%s

It’s probably easiest to bookmark some javadoc page and then edit the bookmark and change the URL. While you’re doing that, go to the “Keyword” field of the Edit Bookmark dialog and add the keyword of your choice:

Now you can go to the address bar in Firefox and type “javadoc LinkedList” and it takes you directly to the javadoc search results page. Neat! (Again, these are the instructions for Firefox. Other browsers may have similar features, but I don’t know how to use them.)

Since the URL is just a piece of text, you can easily write a script to construct it from a variety of sources it and send it along. A lot of this is pretty system-specific. For example, on most systems, there’s a way to get the text from the clipboard. Once you’ve gotten the clipboard text, you can append it to the base search URL and open this URL in a browser. On a Mac, you can create a simple Automator workflow to add “Javadoc Search” to your Services menu to do the same thing.

Thanks to Hannes Wallnoefer and the javadoc team for developing this feature.

Have fun with JDK 21!

list.sort(comparator);

If a class implements the Comparable interface, that means instances of that class know how to compare themselves. (The “comparison of themselves” is referred to as the natural order.) If the list contains elements that are Comparable, you don’t need to pass a Comparator argument to the List.sort() method. Instead, you pass null:

list.sort(null);

and the list will be sorted according to the elements’ natural order. José quite reasonably observes that it’s somewhat unpleasant to have to pass “null” there, and he suggests that it would be cleaner to have a no-arg overload that sorts the list in natural order.

Yeah, we should add that!

After all, there are two overloads of the Stream.sorted() method: a no-arg overload that sorts by natural order, and an overload that takes a Comparator argument. We should clearly do the same for List.sort(). Maybe its omission was just an oversight. On the other hand, it’s such an obvious thing; maybe the omission was deliberate.

What about compatibility?

The default methods feature was added in Java 8. This allowed the addition of new methods to interfaces. Prior to Java 8, adding a method to an interface was an incompatible change. With default methods, it’s possible to add a new method in a compatible way. However, incompatibility is still possible when adding a default method. For example, consider the List.sort(Comparator) method again. Its return type is void. Suppose there is a Java 7 application that has this List implementation:

class MyList<E> extends List<E> {
    public MyList<E> sort(Comparator<? super E> comparator) {
        // sort the list
        return this;
    }
}

If this class were recompiled on Java 8, an error would occur, because Java doesn’t allow overrides with a differing return type.

(Java does allow covariant return types in an overriding method, where the return type of the override is a subtype of the return type of the overridden method. That doesn’t apply here, because MyList<E> isn’t a subtype of void.)

Adding a default method to an interface can be compatible, but it might be incompatible if there is a conflict with a method in an existing class. It’s therefore necessary to be quite careful when adding default methods to interfaces. It’s even more important to be careful if the interface is widely implemented (like List), if the method name is short and common (like sort), and if it has few or no arguments. Thus, it seems likely that adding a no-arg List.sort() default method would conflict with a method in an existing subclass. Maybe adding this default method isn’t such a good idea after all.

This line of reasoning seems valuable. Maybe I should write it down somewhere!

This issue is fairly subtle, and it’s worth writing down so that somebody in the future doesn’t make a mistake. A blog post (like this one) is one way to preserve this information. However, this blog isn’t connected to the OpenJDK project, so somebody working on the JDK wouldn’t know to search here. Someplace closer to the JDK would be preferable.

Another place to store this information is the JDK Bug System (JBS), which is the bug database for the JDK. It contains a lot of history, including bug reports converted from the old Sun bug database dating back to the pre-JDK-1.0 era in the 1990s. It seems likely that information in JBS will persist longer than this blog. Since JBS is associated with the JDK project, it’s also more likely that somebody working on the JDK will find it. Plus, JBS is a database, with nice categories and querying capabilities, making it easy to find information.

How should this kind of information be recorded in a bug database? I could file a request to add this API, close it out, and put the rationale for not implementing it into the comments. Filing a request and closing it immediately might seem excessively fussy. Once it’s in the database, though, it would be easy for future maintainers to rediscover the request in the future if a similar issue were to arise.

Before filing a new issue, it’s always good practice to search the database to see if something similar exists already. Indeed, upon searching, I found this:

Huh. That seems like it covers exactly the same issue. It was submitted in April 2015 by “Webbug Group”, which is the JBS username that’s used when a bug is received from an anonymous person on the internet. The bug’s status is Closed, and its resolution value is Won’t Fix. Who did that and why? Looking through bug report, the last comment (also from April 2015) is this one:

This comment was written by … me! Wow, I had completely forgotten about this. Not surprisingly, it turns out that the bug database has a better memory than I do. I just went through this line of reasoning and reached a conclusion. Then I found the same line of reasoning and the same conclusion that I had written down nearly eight years earlier. Fortunately, present me agrees with past me.

Suppose that I had watched José’s video and immediately decided to implement the new default method. Every change to the JDK requires a JBS entry, so I would have started by searching for an existing issue or filing a new one. It seems likely I would have run across the 2015 issue at that time. (There are only 14 collections bugs in the database that have both “list” and “sort” in the title.) Even if I had missed it, one of the reviewers of the change probably would have noticed the 2015 bug and called my attention to it. Either way, it’s clear that writing down the reasoning in 2015 is valuable to a future maintainer in 2023, whether that maintainer is me or somebody else. And it seems likely that having this issue in the database, along with other similar issues, will be of value to future maintainers.

Anyway, sorry about that José, that’s why we won’t be adding a no-arg List.sort() overload.

The code from SunGraphics2D that Heinz pointed out is this:

@SuppressWarnings("removal")
public void finalize() {
    // DO NOT REMOVE THIS METHOD
}

Why did somebody bother to write an empty finalize() method, and why is it so important that there is a comment warning not to remove it?

The answer is that an empty finalizer disables finalization for all instances of that class and for all instances of subclasses (unless overridden by a subclass). Depending on the usage of that class, this can be a significant optimization.

To understand this, let’s recap the Java object life cycle.

A Java object without a finalizer is created, is used for a while, and eventually becomes unreachable. Some time later, the garbage collector notices that the object is unreachable and garbage collects it.

An object with a finalizer is created, is used for a while, and eventually becomes unreachable. Some time later, the object’s finalize() method is run. This is regular Java code, so the object is now actually reachable. Some additional time later, the object becomes unreachable again, and this time, the garbage collector collects the object. Thus, objects with finalizers live longer than objects without finalizers, and the garbage collector needs to do more work to garbage collect them. Using a lot of objects with finalizers increases memory pressure and potentially increases the memory requirements of the system.

Why would you need to disable finalization for some objects?

Let’s look at the case that Heinz pointed out. Instances of java.awt.Graphics (actually, its subclasses) keep a pointer to native resources used by that object. The dispose() method frees those native resources. It also has a finalizer that calls dispose() as a “safety net” in case the program didn’t call dispose(). Note that when a Graphics object becomes unreachable, it’s kept around in order for it to be finalized, even if the program had already called dispose().

The SunGraphics2D subclass is a “lightweight” object that never has any associated native resources. If it were to inherit the finalizer from Graphics, instances would need to be kept around longer in order to run the finalizers, which would call dispose(), which would do nothing. To prevent this, SunGraphics2D provides an empty finalize() method. An empty method has no visible side effects; therefore, it’s pointless for the JVM to extend the lifetime of an object in order to run an empty finalize() method. Instead, the JVM garbage collects such objects as soon it can determine they are unreachable, skipping their finalization step.

Let’s see this in action. It’s pretty easy to tell when an object is finalized by putting a print statement into its finalizer. But how can we tell whether an object with an empty finalizer was actually finalized or whether it was garbage collected immediately? This is fairly simple to do, using a new JFR event added in JDK 18.

Here’s a program with a small class hierarchy. Class A has a finalizer; B inherits it; C overrides with an empty finalizer; D inherits the empty finalizer; and E overrides with a non-empty finalizer. (I’ve made them static classes nested inside a top-level class EmptyFinalizer so they’re all in one file, but otherwise this doesn’t affect finalization. See the full program.)

    static class A {
        protected void finalize() {
            System.out.println(this + " was finalized");
        }
    }

    static class B extends A {
    }

    static class C extends B {
        protected void finalize() { }
    }

    static class D extends C {
    }

    static class E extends D {
        protected void finalize() {
            System.out.println(this + " was finalized");
        }
    }

The main program creates a bunch of instances but doesn’t keep references to them. It calls System.gc() a few times and sleeps to let the garbage collector run. The output is something like the following:

$ java EmptyFinalizer
EmptyFinalizer$E@cd4e940 was finalized
EmptyFinalizer$B@8eb6c02 was finalized
EmptyFinalizer$A@4de9e37b was finalized
EmptyFinalizer$E@57db5523 was finalized
EmptyFinalizer$B@7cee2871 was finalized
EmptyFinalizer$A@2f36c092 was finalized
EmptyFinalizer$E@2dc61c34 was finalized
EmptyFinalizer$B@203936e2 was finalized
EmptyFinalizer$A@2d193f34 was finalized
EmptyFinalizer$E@34324855 was finalized
EmptyFinalizer$B@2988c55b was finalized
EmptyFinalizer$A@40ef68ae was finalized
EmptyFinalizer$E@246b0f18 was finalized
EmptyFinalizer$B@23d8b20 was finalized
EmptyFinalizer$A@6df02421 was finalized

We can see that instances of A, B, and E were finalized, but C and D were not. Well, we can’t really tell, can we? Their empty finalizers might have been called. Starting in JDK 18, we can use JFR to determine whether these objects were finalized. First, enable JFR during the run:

$ java -XX:StartFlightRecording:filename=recording.jfr EmptyFinalizer
[0.365s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default.
[0.365s][info][jfr,startup] 
[0.365s][info][jfr,startup] Use jcmd 56793 JFR.dump name=1 to copy recording data to file.
EmptyFinalizer$A@cd4e940 was finalized
EmptyFinalizer$E@8eb6c02 was finalized
EmptyFinalizer$B@4de9e37b was finalized
EmptyFinalizer$A@57db5523 was finalized
EmptyFinalizer$E@7cee2871 was finalized
EmptyFinalizer$B@2f36c092 was finalized
EmptyFinalizer$A@2dc61c34 was finalized
EmptyFinalizer$E@203936e2 was finalized
EmptyFinalizer$B@2d193f34 was finalized
EmptyFinalizer$E@34324855 was finalized
EmptyFinalizer$B@2988c55b was finalized
EmptyFinalizer$A@40ef68ae was finalized
EmptyFinalizer$E@246b0f18 was finalized
EmptyFinalizer$B@23d8b20 was finalized
EmptyFinalizer$A@6df02421 was finalized

Now we have a file recording.jfr with a bunch of events. Next, we print this file in a readable form with the following command:

$ jfr print --events FinalizerStatistics recording.jfr
jdk.FinalizerStatistics {
  startTime = 16:43:37.379 (2022-04-27)
  finalizableClass = EmptyFinalizer$A (classLoader = app)
  codeSource = "file:///private/tmp/"
  objects = 0
  totalFinalizersRun = 5
}

jdk.FinalizerStatistics {
  startTime = 16:43:37.379 (2022-04-27)
  finalizableClass = EmptyFinalizer$B (classLoader = app)
  codeSource = "file:///private/tmp/"
  objects = 0
  totalFinalizersRun = 5
}

jdk.FinalizerStatistics {
  startTime = 16:43:37.379 (2022-04-27)
  finalizableClass = jdk.jfr.internal.RepositoryChunk (classLoader = bootstrap)
  codeSource = N/A
  objects = 1
  totalFinalizersRun = 0
}

jdk.FinalizerStatistics {
  startTime = 16:43:37.379 (2022-04-27)
  finalizableClass = EmptyFinalizer$E (classLoader = app)
  codeSource = "file:///private/tmp/"
  objects = 0
  totalFinalizersRun = 5
}

We can easily see that classes A, B, and E each had five instances finalized, with zero instances remaining on the heap. Classes C and D aren’t listed, so no finalization was performed for them. Also, it looks like the JFR internal class RepositoryChunk uses a finalizer, and there was one live instance, and none were finalized. (We’ll have to get the JFR team to convert this class to use Cleaner instead!)

JEP 421 has deprecated finalization for removal. Eventually it will be disabled and removed from the JDK. If your system uses finalizers — or, perhaps more crucially, if you don’t know whether your system uses finalizers — use JFR to help find out. See the JDK Flight Recorder documentation for more information about JFR.

(Updated with suggestions from Kim Barrett. Thanks, Kim!)

Kudos to Nikhil Nanivadekar and Don Raab and the Eclipse Collections team for getting on top of this issue!

What’s the story here? Aren’t new JDK releases supposed to be compatible? In general, yes, we try really hard to keep everything compatible. But sometimes incompatibilities are unavoidable, and sometimes we just miss stuff. To understand what happened, we need to discuss two distinct concepts: source incompatibility and binary incompatibility.

A source incompatible change is one where a source file compiles just fine on an earlier JDK release but fails to compile on a more recent JDK release. A binary incompatible change is one where a compiled class file runs fine on an earlier JDK release but fails at runtime on a more recent JDK release.

In development of the JDK, we put in quite a bit of effort to avoid binary incompatible changes, since it’s unreasonable to force people to recompile everything, and potentially maintain different artifacts, for different JDK releases. Ideally, we’d like to enable people to provide a single binary artifact (e.g., a jar file) that runs on all of the JDK releases that their project supports.

We are somewhat more tolerant of source incompatible changes. If you’re recompiling something, then presumably you have access to the source code in order to make a few minor adjustments. We’re willing to make minor source incompatible changes to the JDK if the change provides enough value to justify the incompatibility.

It turns out that adding a default method to an interface is potentially both a source and binary incompatible change. I was a bit surprised by this. What’s going on?

Let’s first set aside default methods on interfaces and look just at adding methods to classes. Making changes to a class potentially affects subclasses. In most cases, adding a method to a class is a binary compatible change, even if the subclass has methods that are apparently in conflict with the new method in the superclass. For example, consider this class compiled on JDK 8:

class MyInputStream extends InputStream {
    public String readAllBytes() { ... }
    ...
}

This works fine. However, a method was added to InputStream on JDK 9:

public byte[] readAllBytes()

Now there is a conflict between InputStream and MyInputStream, since they have methods with the same name, the same parameters (none), but different return types. Despite this conflict, this is a binary compatible change. Any already-compiled classes that invoke the readAllBytes() method on an instance of MyInputStream will do so using this bytecode:

invokevirtual #6 // Method MyInputStream.readAllBytes:()Ljava/lang/String;

(I determined this by compiling a program that uses MyInputStream on JDK 8, and then running the javap -c command on the resulting class file.) Roughly, this says “invoke the method named «readAllBytes» that takes no arguments and returns a String.” That method exists on MyInputStream and not on InputStream, so the method invocation works even on JDK 9.

However, this is a source incompatible change. When I try to recompile MyInputStream.java on JDK 9, the result is this:

MyInputStream.java:13: error: readAllBytes() in MyInputStream cannot override readAllBytes() in InputStream
public String readAllBytes() {
^
return type String is not compatible with byte[]

The compatibility analysis of adding methods to classes is fairly straightforward. There is only one path from the current class up the superclass chain to the root class, java.lang.Object. Any conflicts among methods can only occur on this path.

Analysis of adding default methods to interfaces is more complicated, because a class or interface can inherit from multiple interfaces. This means that, looking upward from the current class, instead of there being a linear chain of superclasses up to Object, there is a branching tree (actually a DAG) of interface inheritance. This gives rise to several inheritance possibilities that cannot occur with class-only inheritance.

Also, since default methods are a relatively recent feature, the Java community has relatively less experience evolving APIs using default methods. Default methods were added in Java 8, which was released in 2014, so we have “only” six years of experience with it.

It was possible to have conflicts among interfaces, even before Java 8, for example, if two unrelated interfaces declared the same method but with different return types. Prior to Java 8, though, interfaces were essentially impossible to evolve, and so having such conflicts arise from interface evolution hardly occurred. Finally, in the pre-Java 8 world, interface methods were all abstract. If a class inherited the “same” method (same name, parameters, and return type) from different interfaces, that was OK, as both could be satisfied by a single implementation provided by the class or one of its superclasses.

With the addition of default methods in Java 8, a new problem arose: what if a default method were added to an interface somewhere, such that conflicts between method implementations might arise somewhere in the superclass and superinterface graph? More specifically, what if the superinterface graph contains two default implementations for the same method? The full rules are described in the Java Language Specification, sections 8.4.8 and 8.4.8.4, and there are lots of edge cases, but briefly, the rules are as follows:

• Methods inherited from the class hierarchy take precedence over default methods inherited from interfaces.
• Default methods in interfaces are allowed to override each other; the most specific override takes precedence.
• If multiple default methods are inherited from unrelated interfaces (that is, one doesn’t override the others), that’s a compile-time error.

Here are some examples of these rules in action:

class S {
    public void foo() { ... }
}

interface I {
    default void foo() { ... }
}

interface J extends I {
    default void foo() { ... }
}

interface K {
    default void foo() { ... }
}

Given this class and these interfaces, how do the inheritance rules work?

class C extends S implements I { }
// ok: class wins, S::foo inherited

class D implements I, J { }
// ok: overriding default method wins, J::foo inherited

class E implements I, K { }
    ERROR: types I and K are incompatible;
    class E inherits unrelated defaults for foo() from types I and K

So now we have to think harder about the compatibility impact of adding a default method. If a class already has the method, we’re OK. If there’s another interface that has a default method that overrides or is overridden by the default method we’re adding, that’s OK too. A problem can only occur if there is another default method somewhere in the interface graph inherited by some class.

That’s what’s going on with source compatibility. If you run through the examples above, you can see the kind of compilation error that might arise. What about binary compatibility? It turns out that the rules for binary compatibility with default methods are actually quite similar to those for source compatibility.

Here’s what the Java Virtual Machine Specification says about how invokevirtual finds the method to call. It first talks about method selection:

A method is selected with respect to [the class] and the resolved method (§5.4.6).

Section 5.4.6 says:

The maximally-specific superinterface methods of [the receiver class] are determined (§5.4.3.3). If exactly one matches [the method]’s name and descriptor and is not abstract, then it is the selected method.

OK, what if there isn’t exactly one match? In particular, what if there are multiple matches? Back in the specification of invokevirtual, it says:

If no method is selected, and there are multiple maximally-specific superinterface methods of [the class] that match the resolved method’s name and descriptor and are not abstract, invokevirtual throws an IncompatibleClassChangeError.

Thus, the JVM has to do quite a bit of analysis at runtime. When a method is invoked on some class, it has to not only search for that method up the class hierarchy. It also has to search the graph of interface inheritance to see if a default method might have been inherited, and that there is exactly one such method. Thus, adding a default method to an interface can easily cause problems for existing, compiled classes — a binary incompatibility.

We always examine the JDK for incompatibilities and avoid them if possible. In addition, we look at popular non-JDK libraries to see if problems might occur with them. This kind of incompatibility can occur only if a non-JDK library has a signature-compatible default method in an interface that is unrelated to the JDK interface being modified. It also requires that there be some class that inherits both that interface and the JDK interface. That seems pretty rare, but it can happen.

In fact, this is exactly the case that came up in Eclipse Collections! The Eclipse Collections library has an interface PrimitiveIterable that implements a default method isEmpty, and it also has a class CharAdapter that implements PrimitiveIterable and CharSequence:

interface PrimitiveIterable {
    default boolean isEmpty() { ... }
}

class CharAdapter implements PrimitiveIterable, CharSequence {
    ...
}

This works perfectly fine in JDK 14 and earlier releases. Consider some code that calls CharAdapter.isEmpty(). The bytecode generated would be as follows:

invokevirtual #13 // Method org/eclipse/collections/impl/string/immutable/CharAdapter.isEmpty:()Z

This works on JDK 14, because invokevirtual searches all the superclasses and superinterfaces of CharAdapter, and it finds exactly one default method: the one in PrimitiveIterable.

On JDK 15, the situation is different. A new default method isEmpty() was added to CharSequence. Thus, when the same invokevirtual bytecode is executed, it searches the superclasses and superinterfaces of CharAdapter, but this time it finds two matching default methods: the one in PrimitiveIterable and the one in CharSequence. That’s an error according to the JVM Specification, and that’s exactly what happens:

java.lang.IncompatibleClassChangeError: Conflicting default methods: org/eclipse/collections/api/PrimitiveIterable.isEmpty java/lang/CharSequence.isEmpty

What’s to be done about this? Fortunately, the fix is pretty simple: just add an implementation of isEmpty() to the CharAdapter class. (A couple other classes, CodePointAdapter and CodePointList, are in a similar situation and were also fixed.) In this case the implementations of isEmpty() are so simple that the code this.length == 0 was just inlined. If for some reason it were necessary to have CharAdapter inherit the implementation from PrimitiveIterable, then the implementation in CharAdapter could have been written like this:

@Override
public boolean isEmpty()
{
    return PrimitiveIterable.super.isEmpty();
}

As mentioned above, this fix was delivered in Eclipse Collections 10.4.0, which was delivered in time for JDK 15. Again, thanks to the EC team for their quick work on this.

❧

OK, that’s how the JVM behaves. Why does the JVM behave this way? That is, why does it throw an exception (really, an Error) if it detects multiple default methods among the superinterfaces? Couldn’t it, for example, remember what method was called on JDK 14 (the one on PrimitiveIterable), and then continue to call that method even on JDK 15?

The explanation requires understanding of some background about virtual methods. Consider a simple class hierarchy in a library:

class A {
}

class B extends A {
    void m() { }
}

class C extends B {
}

Suppose further that an application has this code:

void exampleCode(B b) {
    b.m();
}

What method is called? Clearly, this will invoke the B::m. Now suppose that the library is modified as follows:

class A {
    void m() { } // method "promoted" from B
}

class B extends A {
}

class C extends B {
    void m() { } // a new overriding method
}

and the application is run again. Even though the code is invoking method m on B, we don’t know which method will actually be invoked. If the variable b is an instance of B, then A::m will be invoked. But if variable b is an instance of C, then C::m will be invoked.

The method that actually gets invoked depends on the class of the receiver object and the class hierarchy that has been loaded into in this JVM. There is nothing written down anywhere that says that the application used to call B::m. In fact it would be a mistake for something to be written down that causes B::m to continue to be invoked. When an overriding method is added to class C, calls that used to end up at B::m should now be calling C::m. That’s what we want virtual method calls to do.

It’s similar with superinterfaces (though more complicated of course). The JVM needs to do a search at runtime to determine what method to call. If it finds two default methods, such as PrimitiveIterable::isEmpty and CharSequence::isEmpty, there is no information to tell the JVM that the code used to call PrimitiveIterable::isEmpty and that the CharSequence::isEmpty method was added in the most recent release. All the JVM knows is that it’s been asked to invoke a method, it found two, and it has no further information about which to call. Therefore, the only thing it can do is throw an error.

❧

Finally, could this problem have been avoided in the first place? The JDK team had done some analysis to determine whether adding CharSequence.isEmpty() would cause any incompatibilities. The analysis probably looked for no-arg methods with the same name but with a different return type. It might have looked for a method named isEmpty() with a non-public access level, another cause of incompatibilities. But these are both source incompatibilites. Or maybe the analysis missed Eclipse Collections entirely.

One thing that future analyses ought to look for is interfaces with a matching default method. That would have turned up PrimitiveIterable, and which runs the risk of binary incompatibility. By itself this isn’t a problem, but it would cause a problem for any class that implements both interfaces. It turns out that CharAdapter (and related classes) do implement both, so that’s clearly a binary incompatibility.

Even if CharAdapter and friends didn’t exist (and even now after they’ve been fixed) there is still a possibility that further incompatiblities exist. Consider some application class that happens to implement both PrimitiveIterable and CharSequence. That class might work perfectly fine with Eclipse Collections 10.3.0 and JDK 14. But it will fail with JDK 15. The problem will persist even if the application upgrades to Eclipse Collections 10.4.0, since the incompatibility is with the application class, not with CharAdapter and friends. So, that application will have to be fixed, too.

Now that we’ve described the problem and the possibility of incompatibilities, does it mean that it was a mistake to have added CharSequence.isEmpty()? Not necessarily. Even if we had noticed the incompatibility in Eclipse Collections prior to the addition of the isEmpty() default method, we might have gone ahead with it anyway. The criterion isn’t to avoid incompatibility at all costs. Instead, it’s whether the value of adding the new default method outweighs the cost and risk of incompatibility. That said, it would have been better to have noticed the incompatibility earlier and discussed it before proceeding, instead of putting an external project like Eclipse Collections into the position of having to fix something in response to a change in the JDK.

In summary, adding a default method to an interface can result in source and binary incompatibilities. The possibility of the source incompatibility is perhaps obvious, but the binary incompatibility is quite subtle. Both of these have been a possibilities since Java 8 was delivered in 2014. But to my knowledge this is the first time that the addition of a default method has resulted in a binary incompatibility with a real project (as opposed to a theoretical exercise or a toy program). It behooves us to do a more rigorous search for potentially conflicting methods the next time we decide to add a default method to an interface in the JDK.

Back in the day, people at Sun would refer to each other by their Unix logins. (I was “smarks”, and to some extent, I still am.) To this day I think of Bill simply as “shannon”. The other day I tweeted a few memorable quotes from shannon. Each of them is backed by a funny story, which I’ll relate here. If you ever heard Bill speak, please imagine these spoken in his imperious baritone.

❧

Sometime in the 1990s, Sun’s internal network was organized into domains that corresponded to the overall functional area in which one worked. The engineering groups were under “eng.sun.com”, the corporate management was under “corp.sun.com”, and so forth. We had email addresses that were tied to the domain name, so I was [email protected]. At some point it as decided that everything would be reorganized into geographic domains. I worked in the San Francisco Bay Area region, so the old domains would be replaced with the sfbay.sun.com domain. An announcement went out that described this change, and it said something like,

Please inform all of your contacts that your new email address will be login@sfbay.sun.com instead of the old login@eng.sun.com. The eng.sun.com email addresses will stop working in 90 days.

I thought, this is ridiculous. I’ve handed out countless business cards that have my eng.sun.com email address on them, and I can’t track down everybody I’ve ever given a business card. I’ve written that email address on papers that have been published in conference proceedings, and those can’t be changed. I can’t be the only one with this problem, either. But, I thought naïvely, it should be pretty simple to set up an MX record (a DNS mail exchanger record) to handle email sent to addresses in the old eng.sun.com domain. I filed a ticket to request that, but it was summarily closed by the network administrators with some explanation like, “Mail forwarding is not possible.” Oh well, I guess I don’t know anything about running a corporate network with thousands of nodes, and I let it drop.

A couple days later, shannon sent mail to all of engineering, describing exactly the same problem I was concerned about. I replied to him, saying that I had requested an MX record be published, but the ticket had been closed. He said, “Yes, that’s what should be done. I’ll talk to the network administrators about it.”

A couple days later, he followed up with this:

    You're right, these people are idiots.

❧

A project that shannon and I worked on together was a large joint development project with another company (which I won’t name, but whose initials are H.P.) Well, OtherCompany had a penchant of coming up with incredibly complex, fragile designs that tried to solve problems that didn’t really need solving.

In desktop systems, it’s pretty common to have a portion of a window that lets users edit text. This is usually implemented by a “text editor” widget provided by the windows tookit library, but created and managed by the application. Apparently this was unsatisfactory for OtherCompany, so they wanted to have a single, “daemon” process that managed all of the text editor widgets for every application on the desktop. At Sun we all thought this was a terrible idea, but OtherCompany wouldn’t let go of it.

At one point there was a conference call where shannon and and others at Sun had a review for this design with OtherCompany. It went something like this.

shannon: Now let me get this straight. Instead of each
application owning its own text widgets, all the text
editing functions are centralized into a single process?

OtherCompany: Yes.

shannon: And instead of each application process handling
keyboard events for its text widgets, those events will be
handled by this centralized daemon process?

OtherCompany: Yes.

shannon: So all the text data that the user has entered will
be in this daemon process, not in the application?

OtherCompany: Yes.

shannon: And if this other process crashes, what happens
to that data?

OtherCompany: (discussion) All the text data is lost.

shannon: And if this daemon process hangs, then what will
happen to the applications on the desktop?

OtherCompany: (discussion) They will all hang.

shannon: ...

OtherCompany: ...

shannon: Do you see anything wrong with this architecture?

❧

Bill made a big impression on me early on, well before I actually met him. I joined Sun in 1986, as an impressionable young engineer fresh out of school. Fairly early on I heard about some guy “shannon” who was a bigwig in the Systems group. I was in a separate group, the Windows group, so we didn’t interact.

Some time soon after I joined, shannon sent an email to all of engineering, with a policy statement. (This was before I started to save email compulsively, otherwise I would have dug up the original.) As I recall, it went something like this:

This is a statement on the Systems Group's policy for code
that is checked into SunOS. The policy is:

    * All code must conform to the Sun C Style Guide

Non-conforming code that is posted for review will be
rejected until it does conform.

Non-conforming code that is checked into the source base
will be backed out and will not be permitted to be checked
in until it does conform.

If you do not understand this policy, I will come to your
office and explain it until you do.

This only applied to SunOS code, not Windows code, so it didn’t affect my day-to-day work. But as a young engineer I found it to be hair-raising! The lesson I took from this was, you do not want to cross shannon.

It’s a lesson that served me well over the years.

❧

Like Bill, I stayed on at Sun all the way up until the 2010 acquisition by Oracle, and we stayed at Oracle until the present day. We didn’t work together too closely in recent years, though we both worked on Java – he worked on Java EE, and I worked on Java ME and Java SE. We were even in the same building on Sun’s (later Oracle’s) Santa Clara campus for several years. It’s amazing that he’s been around nearby for literally my entire career. It’s huge loss that he’s gone. Bye shannon, we’ll miss you.

❧

Here are some links to other pages about Bill.

• Obituary from the San Jose Mercury News
• Article by David Rosenthal, a former colleague at Sun
• History of the UNIX License Plate
• Tribute by Reza Rahman
• Tribute Site at LastingMemories.com

Scanner has a pretty complicated API, but once you figure out how to use it, it’s incredibly useful. Its main issue is that it’s trying to do too many things at once. The good news is that you can use parts of the API for stylized uses and mostly ignore other parts of the API.

At its core, Scanner is about regex pattern matching. Unlike the Pattern and Matcher classes, which can only match on a fixed input such as a String, Scanner allows you to match over arbitrary input that might not even exist in memory. There are several Scanner constructors that allow input to be read from various sources such as files, InputStreams, or channels. Scanner handles buffering, and it reads additional input as necessary, and it discards any input that was skipped over during matching. This is really cool. It means you can do matching over arbitrarily sized input data using just a few KB of memory.

(Naturally this depends on the patterns used for matching as well as the well-formedness of input. For example, you can attempt to read a file line by line, and this will work for an arbitrarily sized file if it’s broken up into reasonably sized lines. If the file doesn’t have any line separators, Scanner will bring the whole file into memory, as the file conceptually contains one long line.)

Scanner has two fundamental modes of matching. The first mode is to break the input into tokens that are separated by delimiters. The delimiters are defined by the regex pattern you provide. (This is rather like the String.split method.) The second mode is to find chunks of text that result from matching the regex pattern you provide. In other words, the token mode provides the text between matches, and the find mode provides the text of the matches themselves. What’s odd about the Scanner API is that there are groups of methods that apply in one mode but not the other.

The methods that apply to the tokens mode are:

• delimiter
• locale
• hasNext* (excluding hasNextLine)
• next* (excluding nextLine)
• radix
• tokens
• useDelimiter
• useLocale
• useRadix

The methods that apply to the find mode are:

• findAll
• findInLine
• findWithinHorizon
• hasNextLine
• nextLine
• skip

(Additional Scanner methods apply to both modes.)

Here’s an example of using Scanner for matching tokens:

    String story = """
        "When I use a word," Humpty Dumpty said,
        in rather a scornful tone, "it means just what I
        choose it to mean - neither more nor less."
        "The question is," said Alice, "whether you
        can make words mean so many different things."
        "The question is," said Humpty Dumpty,
        "which is to be master - that's all."
        """;

    List<String> words = new Scanner(story)
        .useDelimiter("[- \\.\n\",]+")
        .tokens()
        .collect(toList());

(Note, this example uses the new Text Blocks feature, which was previewed in JDK 13 and 14 and which is scheduled to be final in JDK 15.)

Here, we set the delimiter pattern to match whitespace and various punctuation marks, so the tokens consist of text between the delimiters. The results are:

    [When, I, use, a, word, Humpty, Dumpty, said, in, rather, a, scornful,
    tone, it, means, just, what, I, choose, it, to, mean, neither, more,
    nor, less, The, question, is, said, Alice, whether, you, can, make,
    words, mean, so, many, different, things, The, question, is, said,
    Humpty, Dumpty, which, is, to, be, master, that's, all]

In this example I used the tokens() method to provide a stream of tokens. Scanner implements Iterator<String>, which allows you to iterate over the tokens that were found, using the typical hasNext/next methods. Unfortunately, Scanner does not implement Iterable, which would allow you use it within a for-loop.

Scanner also provides pairs of hasNext/next methods for converting tokens to data. For example, it provides hasNextInt and nextInt methods that search for the next token and convert it to an int (if available). Corresponding pairs of methods are also available for BigInteger, boolean, byte, double, float, long, and short. These pairs of methods are “iterator-like” in that the hasNextX/nextX method pairs are just like the hasNext/next method pair of an Iterator, with the addition of data conversion. But there’s no way to wrap them in an Iterator, like Iterator<BigInteger> or Iterator<Double>, without writing your own adapter code. This is unfortunate, since Scanner is an Iterator<String> but its Iterator is only over tokens, not the value-added iterator-like constructs that include data conversions.

The other main mode of Scanner is the find mode, which provides a succession of matches from a pattern you provide. Here’s an example of that:

    List<String> words = new Scanner(story)
        .findAll("[A-Za-z']+")
        .map(MatchResult::group)
        .collect(toList());

Here, instead of matching delimiters between tokens, I’ve provided a pattern that matches the results I want to get. Note that return of findAll() is Stream<MatchResult> and which must be converted to strings; that’s what the MatchResult::group method does. The resulting list is the exact same list of words as the previous example. Personally, I find this mode more useful than the tokens mode. You’re providing the pattern for the text you’re interested in, as opposed to a pattern for the delimiters between the text you’re interested in. Also, you get back MatchResult objects, which are useful for extracting substrings of what you matched. This isn’t available in tokens mode.

I started off this article saying that Scanner is weird but useful. It’s weird because it has these two distinct modes. It has groups of methods that apply to one mode but not the other. If you look at the API carefully (or at the implementation) you’ll also see that there is also a bunch of internal state that applies to one mode but not the other. It seems like Scanner should have been split into two classes. Another weird thing about Scanner is that it’s an Iterator<String>, which elevates one part of one of the modes to the top level of the API and relegates the other parts to second-class status.

That said, Scanner provides some very useful services. It does I/O and buffering for you, and if regex matching needs more input, it handles that automatically. I’m also partial to the streams-returning methods like findAll() and tokens() — I have to admit, I added them — but they make bulk processing of arbitrary input quite easy. I hope you find these aspects of Scanner useful as well.

Brian Goetz and I gave this presentation in Antwerp, Belgium on November 7, 2019. The original title of this talk (as posted on the conference program) was “Why We Hate Java Serialization And What We’re Doing About It.” We made a slight adjustment to the title just before the presentation.

• slides (PDF)
• video (YouTube)

I initially proposed this talk to Brian because I felt we needed to correct the record about Java serialization. It’s very easy to criticize Java serialization in retrospect. We hear a lot of comments like “Just get rid of it!” but in fact serialization was introduced because it solves — and continues to solve — a very important problem. Like many complex systems, it has flaws, not because its designers were stupid, but because of typical software project difficulties: disagreements over the fundamental goals, being designed and implemented in a hurry, and a healthy dose of corporate politics.

We wanted to document very precisely where we think Java serialization’s flaws are: at the binding to the object model. In addition, Brian and the Java team had been thinking a lot about what the future of serialization would be, and we wanted to present that as well. Those ideas are described in more detail on Towards Better Serialization (June, 2019).

(This is a backdated article, posted on April 2, 2021. I’ve represented to the best of my ability my perspective at the time the presentation was given in November, 2019.)

It essentially started the previous week at the “Chinascaria”, Steve Chin‘s Community BBQ for JUG leaders and friends. Although Steve is now at JFrog, he’s continuing the BBQ tradition. Of course Bruno Souza, Edson Yanaga, and some other cohorts from Brazil were manning the BBQ, and there was plenty of meat to be had. I didn’t get many photos, but Ruslan from JUG.RU was there and he insisted that we take a selfie:

Hi Ruslan! Oh, here’s a tweet with the chefs from the BBQ:

Java Keynote

The conference kicked off with the Java keynote, The Future of Java is Now, led by Georges Saab. The pace was pretty brisk, with several walk-on guests. We heard from Jessica Pointing talk about quantum computing, and from Aimee Lucido on her new book, Emmy in the Key of Code.  This sounds really cool, a book written in Java-code-like verse. This should be interesting to my ten-year-old daughter, since she’s reading the Girls Who Code series right now. I have to say this is the first time I’ve shown a segment of a conference keynote to my family!

Naturally a good section of the keynote covered technical issues. Mikael Vidstedt and Brian Goetz ably covered the evolution of the JVM and the Java programming language. Notably, Mark Reinhold did not appear; he’s taking a break from conferences to refocus on hard technical problems.

My Sessions

This year, I had two technical sessions and a lab. This was a pretty good workload, compared with previous years where I had half a dozen sessions. I felt like I made a good contribution to the audience, but it left time for me to have conversations with colleagues (the “hallway track”) and to attend other sessions I was interested in.

My sessions were:

Collections Corner Cases — slides — video — ccc.jshell

This session covered Map’s view collections (keySet, values, entrySet) and topics regarding comparators being “inconsistent with equals.”

Local Variable Type Inference: Friend or Foe? — slides — video

(with Simon Ritter)

When Simon and I did an earlier version of this talk at another conference, we called it “Threat or Menace.” This probably doesn’t translate too well; to me, it has a 1950s red scare connotation, which is distinctly American. I think that’s why Simon changed it to Friend or Foe. It turns out that Venkat Subramaniam also had a talk on the same subject, entitled “Type Inference: Friend or Foe”!

Lambda, Streams, and Collectors Programming Laboratory — lab repository

(with Maurice Naftalin and José Paumard)

This lab continues to evolve; there are now over 100 exercises. Thanks to Maurice and José for continuing to maintain and develop the lab materials. I recalled that we first did a Lambda Lab at Devoxx UK in 2013, which was before Java 8 was released. Maurice and Richard Warburton and I got together an hour beforehand and came up with about half a dozen exercises. It was a bit ad hoc, but we managed to keep a dozen or so people busy for an hour and a half.

More recently we (mostly José) have added and reorganized the exercises, converted the project to maven, and converted the test assertions to AssertJ. I’ve finally come around to the idea that maven is the way to go. However, the lab attendees still had their fair share of configuration problems. The think the main problem is the mismatch between maven and the IDE. It’s possible to build the project on the command line using maven, but hitting the “Test” button in the IDE does some magic that doesn’t necessarily invoke maven, so it might or might not work.

Meet the Experts

One thing that was new this year was the “Meet the Experts” sessions. In the past we’d be asked to sign up for “booth duty” which consisted of standing around for a couple hours waiting for people to ask questions. This was mostly a waste of time, since we didn’t have flashy demos. Instead, we scheduled informal, half-hour time slots at a station in the Groundbreakers Hub, and these were put onto the conference program. The result was that people showed up! I signed up for two of these. I didn’t have a formal presentation; I just answered people’s questions. This seemed considerably more useful than past “booth duty.” People had good questions, and I had some good conversations.

Everything You Ever Wanted To Know About Java And Didn’t Know Whom To Ask — video

I hadn’t signed up for this session, but the day before the session, Bruno Souza corralled me (and several others) into participating in this. Essentially it’s an impromptu “ask me anything” panel. He convinced about 15 people be on the panel. This included various JUG leaders, conference speakers, and experts in various areas. During the first part of the session, Bruno gathered questions from the audience and a colleague typed them into a document that was projected on the screen. Then he called the panelists up on stage. The rest of the session was the panel picking questions and answering them. I thought this turned out quite well. People got their questions answered, we covered quite a variety of topics, and it provoked some interesting discussions.

Other Sessions of Interest

I attended a few other sessions that were quite useful. I also watched on video some of the sessions that I had missed. Here they are, in no particular order:

Robert Seacord, Serialization Vulnerabilities — video

Mike Duigou, Exceptions 2020 (slide download available)

Sergey Kuksenko, Does Java Need Value Types? Performance Perspective — video

Brian Goetz, Java Language Futures, 2019 Edition — video

Venkat Subramaniam, Type Inference: Friend or Foe? — video

Robert Scholte, Broken Build Tools and Bad Behaviors (slide download available)

Nikhil Nanivadekar, Do It Yourself: Collections

Here’s the playlist of Code One sessions that were recorded.

Unfortunately, not all of the sessions were recorded. Some of the speakers’ slide decks are available for download via the conference catalog.

I’m a Java SE guy, so the details of Java EE and Jakarta EE specifications are pretty much outside my bailiwick. However, as Dr Deprecator, I should point out that there is one area of overlap: the dependence of Java EE / Jakarta EE APIs on deprecated Java SE APIs. One example in particular that I’m aware of was brought to my attention by my colleague Sean Mullan, who is tech lead of the Java SE Security Libraries group.

The Java SE API in question is java.security.Identity, which was deprecated in JDK 1.2 (released 1998) and deprecated for removal in Java 9. Since this API has been deprecated for a very long time, and we’d like to remove it from Java SE. For most purposes, it can be replaced by java.security.Principal, which was added in JDK 1.1 (released 1997).

The EJB specification uses the Identity type in a couple methods of the EJBContext class. If we were to remove Identity from some release of Java SE, it would mean that EJB — and any Java EE, Jakarta EE, or any other framework that includes EJB — would no longer be compatible with that release of Java SE. We’ve thus held off removing this type for the time being, in order to avoid pulling the rug out from underneath the EE specs.

Identity is used only in two methods the EJBContext class. It appears that these methods were deprecated in EJB 1.2, and replacements that use Principal were introduced at that time. Since J2EE 1.2 was introduced in 1999, things have been this way for about 20 years. I think it’s time to do some cleanup! (See EJB-spec issue #130.)

For better or for worse, these methods still appear in Java EE 8. As I understand things, the next specification release will be Jakarta EE 9, which will be the earliest opportunity to change the EE specification to remove the dependency on the deprecated SE APIs.

The usual argument against removing stuff is that it’s both source and binary incompatible. If something falls over because of a missing API, it’s pretty hard to work around. This is the reason that deprecated stuff has stayed around for so many years. On the other hand, if these deprecated APIs aren’t removed now, when will they be removed?

I’d argue that the upcoming package renaming (whether incremental or big bang) is an opportunity to remove obsolete APIs, because such renaming is inherently both source and binary incompatible. People will have to run migration tools and change their code when they transition it from Java EE 8 to Jakarta EE 9. There can be no expectation that old jar files will run unchanged in the new Jakarta world. Thus, the package renaming is an opportunity to shed these obsolete APIs.

I’m not aware of any EE APIs other than EJBContext that depend on Java SE APIs that are deprecated for removal. I did a quick check of GlassFish 5 using the jdeprscan tool, and this one was the only API-to-API dependency that I found. However, I’m not an expert in EE and GlassFish, so I’m not sure I checked the right set of jars. (I did find a bunch of other stuff, though. Contact me if you’re interested in details.)

I had a brief Twitter exchange with David Blevins on this topic the other day. He pointed me at the parts of the TomEE implementation that implements EJBContext, and it turns out that the two methods in question simply throw UnsupportedOperationException. This is good news, in that it means TomEE applications aren’t using these methods, which means that those applications won’t break if these methods are removed.

However, that doesn’t mean these methods can simply be removed from EE implementations! The TCKs have what is called a “signature test,” which scans the libraries for the public classes, fields, and methods, to make sure that all the APIs required by the specifications are present and that there are no extra APIs. I’m fairly sure that the EE TCK signature test contains entries for those methods. Thus, what needs to happen is that the Jakarta EE specification needs to remove these methods, the EE TCK needs to be updated to match, and then implementations can remove — in fact, will be required to remove — these methods when they’re brought into conformance with the new specification.

Note that all of this is separate from the question of what to do with other deprecated Jakarta EE APIs that don’t depend on deprecated Java SE APIs. Deprecated Jakarta EE APIs might have been deprecated for their own reasons, not because of their dependency on SE APIs. These should be considered on their own merits and an appropriate removal plan developed. Naturally, as Dr Deprecator, I like removing old, obsolete APIs. But the deprecation and potential removal plan for deprecated Jakarta EE APIs needs to be developed with the particular evolution path of those APIs in mind.