Thanks' for explanation.
Would not it make a sense to extend java.util.jar.Attributes.Name class
to support ConcealedPackages new optional attribute?
Martin
On 16.12.2015 11:19, Alan Bateman wrote:
On 16/12/2015 09:27, Martin Balin wrote:
I've encountered this problem with jlink as well. The scenario was
different. I used modular jar files produced by NetBeans with jigsaw
build. NetBeans uses Ant jar task to create jar files. At this moment
we run NB on top of JDK8 and Jigsaw is referenced as Project Java
platform. Therefore NetBeans produces jar file using jar task based
on JDK8 which is not compatible with JDK9 jlink.
I found that I can run these NB produced modular jar files on Jigsaw
e.g.
> "java -mp.... -m <module_name/fully_qualified_main_class>"
But I cannot run such modular jigsaw app when packaged by jlink. Even
specifying Main class does not help. It needs to be packaged by jar
utility from jigsaw in order to be runnable in jlink.
Is this going to be defined somewhere? E.g. Jigsaw jar utility
specification and how it changed from JDK8 jar.
One we fix this issue then it should resolve this case too and there
should be no issue creating the JAR files with older versions of the
jar tool or any zip tool.
As to what is going on? The set of exported packages are in the Module
class file attribute. There may be other non-exported packages and as
an optimization to avoid scanning the contents of the JAR, then this
set of packages can be stored in the optional ConcealedPackages class
file attribute. The jar and jmod tools add or update this attribute,
older versions of the jar tool or zip programs don't know anything
about it. When the attribute is not present then the contents of the
JAR file will be scanned or the file system will be scanned in the
case of an exploded module.
There is a missing piece when we get to jlink and the run-time images.
The code that reconstitutes the set of modules descriptors in the
run-time image assumes the ConcealedPackages attribute is present.
This works great when the modules are in JMOD format or generated with
the updated jar tool but doesn't work when the modules don't have this
attribute. The original intention was it be generated at link-time.
We've since moved on much further to generate code at link time to
speed up the reconstitution of the module descriptors. I initially
thought `jlink --gen-installed-modules off` would be a workaround for
Sebastian but there is a bit more to it. So I think the "TODO" needs a
priority boost.
-Alan
