JEP-238 & JEP-261 Coexistence

[Richard Opalka]

Hi Experts,

I expected if users provide 'multirelease' jar file with
modules-info.class
placed in its META-INF/versions/9 folder would work without problems.
But I'm getting:

Caused by: java.lang.IllegalArgumentException: META-INF.versions.9:
Invalid package name: Illegal character at index 4

instead. Does it mean JEP238 and JEP-261 cannot coexist?
My jar content is:

$>jar tf transactions.jar
javax/
javax/annotation/
javax/annotation/security/
javax/annotation/security/PermitAll.class
javax/annotation/security/DenyAll.class
javax/annotation/security/DeclareRoles.class
javax/annotation/security/RolesAllowed.class
javax/annotation/security/RunAs.class
javax/annotation/PostConstruct.class
javax/annotation/sql/
javax/annotation/sql/DataSourceDefinition.class
javax/annotation/sql/DataSourceDefinitions.class
javax/annotation/ManagedBean.class
javax/annotation/PreDestroy.class
javax/annotation/Resources.class
javax/annotation/Resource$AuthenticationType.class
javax/annotation/Resource.class
javax/annotation/Generated.class
javax/annotation/Priority.class
META-INF/
META-INF/MANIFEST.MF
META-INF/versions/
META-INF/versions/9/
META-INF/versions/9/module-info.class
META-INF/LICENSE.txt

where javax resources are compiled for JDK8
and META-INF/MANIFEST.MF contains 'Multi-Release: true' entry.

Thanks in advance for clarification.

Rio

[Alan Bateman]

Post by Richard Opalka
Hi Experts,
I expected if users provide 'multirelease' jar file with
modules-info.class
placed in its META-INF/versions/9 folder would work without problems.
Invalid package name: Illegal character at index 4
instead. Does it mean JEP238 and JEP-261 cannot coexist?

There isn't any support yet for modular JAR as multi-release JARs. It's
tracked as JDK-8146486 with the main question being whether the compiled
module declaration can be in the META-INF/versions tree or not.

As things stand then a JAR file that does not have a module-info.class
in the top level directory is assumed to be an automatic module so this
is why it barps when trying to determine a package name from
META-INF/versions/9.

BTW: Just looking at the contents of your JAR file then it looks like
this is the EE version of the Common Annotations. In that case you
shouldn't need a multi-release JAR. Instead you should be able to put
the module-info.class in the top level directory and deploy it on the
upgrade module path.

-Alan

[Richard Opalka]

Post by Alan Bateman

Post by Richard Opalka
Hi Experts,
I expected if users provide 'multirelease' jar file with
modules-info.class
placed in its META-INF/versions/9 folder would work without problems.
Invalid package name: Illegal character at index 4
instead. Does it mean JEP-238 and JEP-261 cannot coexist?

There isn't any support yet for modular JAR as multi-release JARs.
It's tracked as JDK-8146486 with the main question being whether the
compiled module declaration can be in the META-INF/versions tree or not.
As things stand then a JAR file that does not have a module-info.class
in the top level directory is assumed to be an automatic module so
this is why it barps when trying to determine a package name from
META-INF/versions/9.

IMHO it should be allowed to put module-info.class to META-INF/versions
subtree as modules may evolve (their imports/exports) with different JDK
versions. // My 2c.

Post by Alan Bateman
BTW: Just looking at the contents of your JAR file then it looks like
this is the EE version of the Common Annotations. In that case you
shouldn't need a multi-release JAR. Instead you should be able to put
the module-info.class in the top level directory and deploy it on the
upgrade module path.

Yes I know. Our requirement is to support both JDK8 and JDK9 with the
same jar.
Thus in my experiments I have javax classes compiled for JDK8 and
module-info.class for JDK9.
Multi-Release jar was my first attempt, when it failed I did what you
propose above Alan.

Post by Alan Bateman
-Alan

Rio

[Alan Bateman]

Post by Richard Opalka

Post by Alan Bateman
BTW: Just looking at the contents of your JAR file then it looks like
this is the EE version of the Common Annotations. In that case you
shouldn't need a multi-release JAR. Instead you should be able to put
the module-info.class in the top level directory and deploy it on the
upgrade module path.

Yes I know. Our requirement is to support both JDK8 and JDK9 with the
same jar.
Thus in my experiments I have javax classes compiled for JDK8 and
module-info.class for JDK9.
Multi-Release jar was my first attempt, when it failed I did what you
propose above Alan.

and did this work? In this case then I would expect the same JAR file
should just work on the upgrade module path with JDK 9 or via the
endorsed standard override mechanism with JDK 8. In the case of the
latter then the module-info.class will be ignored.

-Alan.

[Richard Opalka]

Post by Alan Bateman

Post by Richard Opalka

Post by Alan Bateman
BTW: Just looking at the contents of your JAR file then it looks
like this is the EE version of the Common Annotations. In that case
you shouldn't need a multi-release JAR. Instead you should be able
to put the module-info.class in the top level directory and deploy
it on the upgrade module path.

Yes I know. Our requirement is to support both JDK8 and JDK9 with the
same jar.
Thus in my experiments I have javax classes compiled for JDK8 and
module-info.class for JDK9.
Multi-Release jar was my first attempt, when it failed I did what you
propose above Alan.

and did this work? In this case then I would expect the same JAR file
should just work on the upgrade module path with JDK 9 or via the
endorsed standard override mechanism with JDK 8. In the case of the
latter then the module-info.class will be ignored.

Yes, it worked for the usecase (PoC) I'm testing ATM.
My next attempt will be to leverage our testsuite FW
and test it on both JDK8 and JDK9.

Post by Alan Bateman
-Alan.

Rio

[Richard Opalka]

Post by Richard Opalka

Post by Alan Bateman

Post by Richard Opalka
Hi Experts,
I expected if users provide 'multirelease' jar file with
modules-info.class
placed in its META-INF/versions/9 folder would work without problems.
Invalid package name: Illegal character at index 4
instead. Does it mean JEP-238 and JEP-261 cannot coexist?

There isn't any support yet for modular JAR as multi-release JARs.
It's tracked as JDK-8146486 with the main question being whether the
compiled module declaration can be in the META-INF/versions tree or not.
As things stand then a JAR file that does not have a
module-info.class in the top level directory is assumed to be an
automatic module so this is why it barps when trying to determine a
package name from META-INF/versions/9.

IMHO it should be allowed to put module-info.class to META-INF/versions
subtree as modules may evolve (their imports/exports) with different
JDK versions. // My 2c.

'requires' module section may change with different JDKs if new useful
API is introduced in JDK
and it is used by the multirelease module (I mean change not affecting
the multirelease jar exposed API)

Post by Richard Opalka

Post by Alan Bateman
BTW: Just looking at the contents of your JAR file then it looks like
this is the EE version of the Common Annotations. In that case you
shouldn't need a multi-release JAR. Instead you should be able to put
the module-info.class in the top level directory and deploy it on the
upgrade module path.

Yes I know. Our requirement is to support both JDK8 and JDK9 with the
same jar.
Thus in my experiments I have javax classes compiled for JDK8 and
module-info.class for JDK9.
Multi-Release jar was my first attempt, when it failed I did what you
propose above Alan.

Post by Alan Bateman
-Alan

Rio

Rio