ClassLoader.definePackage() throwing IllegalArgumentException

[Robert Stupp]

Hi,

I'd like to follow up on https://bugs.openjdk.org/browse/JDK-8350547.

TL;DR java.lang.ClassLoader.definePackage() (the one taking 8 arguments) 
clearly defines that a IllegalArgumentException is thrown, "if a package 
of the given name is already defined by this class loader".

However, it seems that it's a common oversight that an IAE can be 
thrown. Examples are the CDI reference implementation ("Weld") and 
Quarkus. In other words: "naively" calling 'definePackage' without a 
retry on IAE leads to issues when defining classes in custom class 
loaders in parallel.

The CL.definePackage() API is there since Java 1.2, and I admit that my 
initial approach to change the currently observed behavior isn't going 
to fly.

I thought about adding more information to the message of the IAE thrown 
in 'definePackage()', but even this "innocent" change could break the 
observed behavior / existing code.

One option could be to add a new function 'definePackageIfNotExists()` 
to j.l.ClassLoader, which works like the existing 'definePackage()' but 
returns the existing package, if it already exists and is compatible 
with the given arguments. The downside is that it could still throw, if 
the arguments are incompatible (e.g. a different "implTitle") - so it 
might just be a less likely, but still possible way of unexpectedly 
hitting an IAE.

With 'definePackageIfNotExists()` it might be possible to deprecate 
'definePackage()', but that deprecation largely depends on the actual 
usage of it in the wild, which I do not know. I'm not sure whether such 
a deprecation can fly. And the next question would be whether it can be 
deprecated for removal ; and if yes, when could it be removed.

Actually, even a new 'definePackageIfNotExists()` could break existing 
code, in case an implementation overrides the existing 'definePackage' 
but not 'definePackageIfNotExists()`.

Another question to which I don't know the answer is whether the 7 
package attribute parameters specification/implementation 
title/version/vendor + seal-base do fit "all today's wishes & needs". 
Or: is there demand for a "better" or "more flexible" way to define a 
class/package? Or: can that API be redefined in a different way tailored 
for today's needs and wishes? And are there any that would justify such 
an effort?

Overall, I'm a bit lost on what the "best" way would be for this. Maybe 
the answer is that there is no better way yet, which is also fine. Maybe 
the only "fix" is to enhance the Javadocs and prominently highlight the 
behavior and add a "reference code snippet" how 'definePackage()' should 
be used and why.

Robert

-- 
Robert Stupp
@snazy