Unnamed module and duplicate package

[Stephen Felts]

The bottom line is that only one module can own a package (generally), where the unnamed module is a possible owner.  If the classes are in the JDK, then it owns the package.  As long as all of the classes that I use from that package are in the JDK, it works.  If some but not all of the classes are  in the JDK, then I have a problem.   If none of the classes from the package are in the JDK for a non-Hotspot JDK, then it should work (we haven’t tested any other JDK9 but Hotspot).

 

In one of the cases that I have, we are using –Xpatch to get around this general rule and add some classes to the package.  We are trying to remove this case.  

However, we might need to keep –Xpatch around if we need to add back sun.misc.BASE64Encoder and sun.misc.BASE64Decoder.  We have a bunch of jar files that I don’t own that use them and some of the jars have requirements to run on pre-JDK8 and/or I know they won’t be re-released for a couple of years.

 

 

 

From: Paul Benedict [mailto:pbenedict at apache.org] 
Sent: Thursday, March 10, 2016 11:43 PM
To: Stephen Felts
Cc: Alex Buckley; ML OpenJDK Jigsaw Developers
Subject: Re: Unnamed module and duplicate package

 

On Thu, Mar 10, 2016 at 10:02 PM, Stephen Felts <HYPERLINK "mailto:stephen.felts at oracle.com" \nstephen.felts at oracle.com> wrote:

Yes, it is compiling and running on Jigsaw.  It’s not pretty but generally getting better. I’m concerned about a number of behaviors that aren’t pinned down yet and I’m worried that a discussion like this one will introduce a non-upward-compatible behavior that will break things worse.

 

Well I appreciate your candid opinion because I believe that you and Niel are ultimately correct. I'll quote from section 3.1 of SOTMS:

"An existing class-path application that compiles and runs on Java SE 8 will, thus, compile and run in exactly the same way on Java SE 9, so long as it only uses standard, non-deprecated Java SE APIs."

To introduce extra validating behavior is backward incompatible. So yes, I believe this is not a good idea anymore. Thanks for your input. I did want to prevent classes shadowing each other, but it's clear the classpath is meant to be more lenient than the modulepath. Kudos.

 

Regarding your previous email, please help me understand how your web application works at all with those duplicate JDK classes present. Wouldn't the modules that expose those JDK classes put you in a split package situation?

Cheers,

Paul


 

 

From: Paul Benedict [mailto:HYPERLINK "mailto:pbenedict at apache.org" \npbenedict at apache.org] 
Sent: Thursday, March 10, 2016 10:16 PM
To: Stephen Felts
Cc: Alex Buckley; ML OpenJDK Jigsaw Developers


Subject: Re: Unnamed module and duplicate package

 

Stephen, regarding your first paragraph, I would like some more detail. Are you running your application server with jigsaw?  

 

Cheers,

Paul

 

On Thu, Mar 10, 2016 at 8:33 PM, Stephen Felts <HYPERLINK "mailto:stephen.felts at oracle.com" \nstephen.felts at oracle.com> wrote:

I'm aware of classes in our application server (not javax) that are unused when running with our own JVM and used when running with another JVM.
In that case, the packages are duplicate of classes in the JDK.  I would not want that usage to generate a fatal error.
This is unrelated to endorsed jar files.

In addition to an upgradeable module for java.transaction.jar with Jigsaw, I'm also running with an upgradeable module for javax.annotation-api-1.2.jar.