I have raised the issue of command line options several times.  I think the 
summary is the following.

1. I don't always have control of the command line.

2. I don't always own the main.

3. When multiple projects are merged into the same JVM, there is not a good way 
to merge command line options.

4. Different releases of the JDK require different options.


One way to resolve this is to embed versioned command line option information 
into library jar files.


Regarding using command line arguments in argument files:

1. Path names are relative to the current working directory, not the argument 

- To use an argument file from anywhere, you need to have full pathnames.

- To generate full pathnames in an argument file, you need to do processing on 
the argument file  (unzip is not sufficient).




-----Original Message-----
From: Dawid Weiss [mailto:dawid.we...@gmail.com] 
Sent: Monday, September 19, 2016 1:02 PM
To: Remi Forax
Cc: jigsaw-dev
Subject: Re: NoClassDefFoundError: Could not initialize, class 


Exactly. I reported the problem having the --add-exports-private option in the 
back of my mind (saw it in a recent thread somewhere), but what I'd be more 
interested in what Rémi asked about.


As a separate note, having multiple non-compatible options becomes quite a 
burden to maintain in a complex build. We use shell scripts to launch 
(command-line) software, so shell scripts have to detect java version first and 
modify options accordingly (currently adding the missing modules with 
annotations), maven builds need a separate profile that adds these options to 
the compilation (and build), etc.


Is there any other, more elegant way of doing this that I overlooked?

Pardon the example, but Microsoft's executable manifest files come to mind -- 
something that permits attaching "metadata" options to the program without 
having to provide it explicitly. Ideally, this metadata could be conditionally 
specified for a given JVM version. It would be interesting to have "java -jar" 
have such "metadata" in the manifest.mf file or somewhere else, so that you 
could specify JVM-version-specific options there instead of providing them on 
command line. Just a thought.




On Mon, Sep 19, 2016 at 3:27 PM, Remi Forax <HYPERLINK 
"mailto:fo...@univ-mlv.fr"fo...@univ-mlv.fr> wrote:

> I wonder what is the best way to fix the code of Guice ?


> Use Unsafe.defineAnonymousClass ?


> cheers,

> Rémi


> ----- Mail original -----

>> De: "Alan Bateman" <HYPERLINK 
>> "mailto:alan.bate...@oracle.com"alan.bate...@oracle.com>

>> À: "Dawid Weiss" <HYPERLINK 
>> "mailto:dawid.we...@gmail.com"dawid.we...@gmail.com>

>> Cc: "jigsaw-dev" <HYPERLINK 
>> "mailto:jigsaw-dev@openjdk.java.net"jigsaw-dev@openjdk.java.net>

>> Envoyé: Lundi 19 Septembre 2016 14:47:58

>> Objet: Re: NoClassDefFoundError: Could not initialize,class   
>> com.google.inject.internal.cglib.core.$ReflectUtils


>> On 19/09/2016 05:35, Dawid Weiss wrote:


>>> Yes, it prints:


>>> java.lang.reflect.InaccessibleObjectException: Unable to make 

>>> protected final java.lang.Class

>>> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,ja

>>> va.security.ProtectionDomain) throws java.lang.ClassFormatError 

>>> accessible: module java.base does not "exports private java.lang" to 

>>> unnamed module @4527468c at

>>> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectExc

>>> eption(Reflection.java:414)

>>> at

>>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(A

>>> ccessibleObject.java:196) at 

>>> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java

>>> :192) at 

>>> java.base/java.lang.reflect.Method.setAccessible(Method.java:186)

>>> at

>>> com.google.inject.internal.cglib.core.$ReflectUtils$1.run(ReflectUti

>>> ls.java:52) at 

>>> java.base/java.security.AccessController.doPrivileged(Native Method) 

>>> at

>>> com.google.inject.internal.cglib.core.$ReflectUtils.<clinit>(Reflect

>>> Utils.java:42)

>>> at

>>> com.google.inject.internal.cglib.reflect.$FastClass$Generator.getPro

>>> tectionDomain(FastClass.java:73)

>>> [truncated]


>> I assume running with `--add-exports-private 

>> java.base/java.lang=ALL-UNNAMED` will allow you get past this.


>> -Alan


Reply via email to