I recently added another "jar" file to my AndroidStudio project, rt.jar. It's the second module I've brought in, so I brought it in the exact same way as the first.
However when I try to debug I get this wonderfully long error in AndroidStudio below. I get the sense that I might need to recompile the jar file mysef? But am not sure. I thought someone here might tell me exactly what I need to do so I don't waste a while lot of time.
p.s. I thought of perhaps doing through the source files for each class I need in my app, it's just a few. But somehow I fear that might be too kludgy.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.Channel$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ChannelSftp$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ChannelSftp$2) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ConfigRepository$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ChannelSftp$3) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ConfigRepository$2) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.JSch$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.Util$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
trouble processing "java/applet/Applet.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
Related
There are a lot of questions about illegal reflective access in Java 9.
I have found plenty of discussion about working around the error messages, but I would love to know what an illegal reflective access actually is.
So my question is:
What defines an illegal reflective access and what circumstances trigger the warning?
I have gathered that it has something to do with the encapsulation principles that were introduced in Java 9, but I can't find an explanation of how it all hangs together, what triggers the warning, and in what scenario.
Apart from an understanding of the accesses amongst modules and their respective packages. I believe the crux of it lies in the Module System#Relaxed-strong-encapsulation and I would just cherry-pick the relevant parts of it to try and answer the question.
What defines an illegal reflective access and what circumstances
trigger the warning?
To aid in the migration to Java-9, the strong encapsulation of the modules could be relaxed.
An implementation may provide static access, i.e. by compiled bytecode.
May provide a means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules, i.e. to code on the classpath. If the run-time system is invoked in this way, and if by doing so some invocations of the reflection APIs succeed where otherwise they would have failed.
In such cases, you've actually ended up making a reflective access which is "illegal" since in a pure modular world you were not meant to do such accesses.
How it all hangs together and what triggers the warning in what
scenario?
This relaxation of the encapsulation is controlled at runtime by a new launcher option --illegal-access which by default in Java9 equals permit. The permit mode ensures
The first reflective-access operation to any such package causes a
warning to be issued, but no warnings are issued after that point.
This single warning describes how to enable further warnings. This
warning cannot be suppressed.
The modes are configurable with values debug(message as well as stacktrace for every such access), warn(message for each such access), and deny(disables such operations).
Few things to debug and fix on applications would be:-
Run it with --illegal-access=deny to get to know about and avoid opening packages from one module to another without a module declaration including such a directive(opens) or explicit use of --add-opens VM arg.
Static references from compiled code to JDK-internal APIs could be identified using the jdeps tool with the --jdk-internals option
The warning message issued when an illegal reflective-access operation
is detected has the following form:
WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM
where:
$PERPETRATOR is the fully-qualified name of the type containing the
code that invoked the reflective operation in question plus the code
source (i.e., JAR-file path), if available, and
$VICTIM is a string that describes the member being accessed,
including the fully-qualified name of the enclosing type
Questions for such a sample warning: = JDK9: An illegal reflective access operation has occurred. org.python.core.PySystemState
Last and an important note, while trying to ensure that you do not face such warnings and are future safe, all you need to do is ensure your modules are not making those illegal reflective accesses. :)
There is an Oracle article I found regarding Java 9 module system
By default, a type in a module is not accessible to other modules unless it’s a public type and you export its package. You expose only the packages you want to expose. With Java 9, this also applies to reflection.
As pointed out in https://stackoverflow.com/a/50251958/134894, the differences between the AccessibleObject#setAccessible for JDK8 and JDK9 are instructive. Specifically, JDK9 added
This method may be used by a caller in class C to enable access to a member of declaring class D if any of the following hold:
C and D are in the same module.
The member is public and D is public in a package that the module containing D exports to at least the module containing C.
The member is protected static, D is public in a package that the module containing D exports to at least the module containing C, and C is a subclass of D.
D is in a package that the module containing D opens to at least the module containing C. All packages in unnamed and open modules are open to all modules and so this method always succeeds when D is in an unnamed or open module.
which highlights the significance of modules and their exports (in Java 9)
if you want to hide warnings you could just use "--add-opens" option
--add-opens <source-module>/<package>=<target-module>(,<target-module>)*
for example you have an error:
java.lang.ClassLoader.findLoadedClass(java.lang.String)
First open String java 11 documentation
Class String where you can find module and package name
Module java.base, Package java.lang
Solution:
java --add-opens=java.base/java.lang=ALL-UNNAMED -jar example.jar
If you want to go with the add-open option, here's a command to find which module provides which package ->
java --list-modules | tr # " " | awk '{ print $1 }' | xargs -n1 java -d
the name of the module will be shown with the # while the name of the packages without it
NOTE: tested with JDK 11
IMPORTANT: obviously is better than the provider of the package does not do the illegal access
There are a lot of questions about illegal reflective access in Java 9.
I have found plenty of discussion about working around the error messages, but I would love to know what an illegal reflective access actually is.
So my question is:
What defines an illegal reflective access and what circumstances trigger the warning?
I have gathered that it has something to do with the encapsulation principles that were introduced in Java 9, but I can't find an explanation of how it all hangs together, what triggers the warning, and in what scenario.
Apart from an understanding of the accesses amongst modules and their respective packages. I believe the crux of it lies in the Module System#Relaxed-strong-encapsulation and I would just cherry-pick the relevant parts of it to try and answer the question.
What defines an illegal reflective access and what circumstances
trigger the warning?
To aid in the migration to Java-9, the strong encapsulation of the modules could be relaxed.
An implementation may provide static access, i.e. by compiled bytecode.
May provide a means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules, i.e. to code on the classpath. If the run-time system is invoked in this way, and if by doing so some invocations of the reflection APIs succeed where otherwise they would have failed.
In such cases, you've actually ended up making a reflective access which is "illegal" since in a pure modular world you were not meant to do such accesses.
How it all hangs together and what triggers the warning in what
scenario?
This relaxation of the encapsulation is controlled at runtime by a new launcher option --illegal-access which by default in Java9 equals permit. The permit mode ensures
The first reflective-access operation to any such package causes a
warning to be issued, but no warnings are issued after that point.
This single warning describes how to enable further warnings. This
warning cannot be suppressed.
The modes are configurable with values debug(message as well as stacktrace for every such access), warn(message for each such access), and deny(disables such operations).
Few things to debug and fix on applications would be:-
Run it with --illegal-access=deny to get to know about and avoid opening packages from one module to another without a module declaration including such a directive(opens) or explicit use of --add-opens VM arg.
Static references from compiled code to JDK-internal APIs could be identified using the jdeps tool with the --jdk-internals option
The warning message issued when an illegal reflective-access operation
is detected has the following form:
WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM
where:
$PERPETRATOR is the fully-qualified name of the type containing the
code that invoked the reflective operation in question plus the code
source (i.e., JAR-file path), if available, and
$VICTIM is a string that describes the member being accessed,
including the fully-qualified name of the enclosing type
Questions for such a sample warning: = JDK9: An illegal reflective access operation has occurred. org.python.core.PySystemState
Last and an important note, while trying to ensure that you do not face such warnings and are future safe, all you need to do is ensure your modules are not making those illegal reflective accesses. :)
There is an Oracle article I found regarding Java 9 module system
By default, a type in a module is not accessible to other modules unless it’s a public type and you export its package. You expose only the packages you want to expose. With Java 9, this also applies to reflection.
As pointed out in https://stackoverflow.com/a/50251958/134894, the differences between the AccessibleObject#setAccessible for JDK8 and JDK9 are instructive. Specifically, JDK9 added
This method may be used by a caller in class C to enable access to a member of declaring class D if any of the following hold:
C and D are in the same module.
The member is public and D is public in a package that the module containing D exports to at least the module containing C.
The member is protected static, D is public in a package that the module containing D exports to at least the module containing C, and C is a subclass of D.
D is in a package that the module containing D opens to at least the module containing C. All packages in unnamed and open modules are open to all modules and so this method always succeeds when D is in an unnamed or open module.
which highlights the significance of modules and their exports (in Java 9)
if you want to hide warnings you could just use "--add-opens" option
--add-opens <source-module>/<package>=<target-module>(,<target-module>)*
for example you have an error:
java.lang.ClassLoader.findLoadedClass(java.lang.String)
First open String java 11 documentation
Class String where you can find module and package name
Module java.base, Package java.lang
Solution:
java --add-opens=java.base/java.lang=ALL-UNNAMED -jar example.jar
If you want to go with the add-open option, here's a command to find which module provides which package ->
java --list-modules | tr # " " | awk '{ print $1 }' | xargs -n1 java -d
the name of the module will be shown with the # while the name of the packages without it
NOTE: tested with JDK 11
IMPORTANT: obviously is better than the provider of the package does not do the illegal access
There are a lot of questions about illegal reflective access in Java 9.
I have found plenty of discussion about working around the error messages, but I would love to know what an illegal reflective access actually is.
So my question is:
What defines an illegal reflective access and what circumstances trigger the warning?
I have gathered that it has something to do with the encapsulation principles that were introduced in Java 9, but I can't find an explanation of how it all hangs together, what triggers the warning, and in what scenario.
Apart from an understanding of the accesses amongst modules and their respective packages. I believe the crux of it lies in the Module System#Relaxed-strong-encapsulation and I would just cherry-pick the relevant parts of it to try and answer the question.
What defines an illegal reflective access and what circumstances
trigger the warning?
To aid in the migration to Java-9, the strong encapsulation of the modules could be relaxed.
An implementation may provide static access, i.e. by compiled bytecode.
May provide a means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules, i.e. to code on the classpath. If the run-time system is invoked in this way, and if by doing so some invocations of the reflection APIs succeed where otherwise they would have failed.
In such cases, you've actually ended up making a reflective access which is "illegal" since in a pure modular world you were not meant to do such accesses.
How it all hangs together and what triggers the warning in what
scenario?
This relaxation of the encapsulation is controlled at runtime by a new launcher option --illegal-access which by default in Java9 equals permit. The permit mode ensures
The first reflective-access operation to any such package causes a
warning to be issued, but no warnings are issued after that point.
This single warning describes how to enable further warnings. This
warning cannot be suppressed.
The modes are configurable with values debug(message as well as stacktrace for every such access), warn(message for each such access), and deny(disables such operations).
Few things to debug and fix on applications would be:-
Run it with --illegal-access=deny to get to know about and avoid opening packages from one module to another without a module declaration including such a directive(opens) or explicit use of --add-opens VM arg.
Static references from compiled code to JDK-internal APIs could be identified using the jdeps tool with the --jdk-internals option
The warning message issued when an illegal reflective-access operation
is detected has the following form:
WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM
where:
$PERPETRATOR is the fully-qualified name of the type containing the
code that invoked the reflective operation in question plus the code
source (i.e., JAR-file path), if available, and
$VICTIM is a string that describes the member being accessed,
including the fully-qualified name of the enclosing type
Questions for such a sample warning: = JDK9: An illegal reflective access operation has occurred. org.python.core.PySystemState
Last and an important note, while trying to ensure that you do not face such warnings and are future safe, all you need to do is ensure your modules are not making those illegal reflective accesses. :)
There is an Oracle article I found regarding Java 9 module system
By default, a type in a module is not accessible to other modules unless it’s a public type and you export its package. You expose only the packages you want to expose. With Java 9, this also applies to reflection.
As pointed out in https://stackoverflow.com/a/50251958/134894, the differences between the AccessibleObject#setAccessible for JDK8 and JDK9 are instructive. Specifically, JDK9 added
This method may be used by a caller in class C to enable access to a member of declaring class D if any of the following hold:
C and D are in the same module.
The member is public and D is public in a package that the module containing D exports to at least the module containing C.
The member is protected static, D is public in a package that the module containing D exports to at least the module containing C, and C is a subclass of D.
D is in a package that the module containing D opens to at least the module containing C. All packages in unnamed and open modules are open to all modules and so this method always succeeds when D is in an unnamed or open module.
which highlights the significance of modules and their exports (in Java 9)
if you want to hide warnings you could just use "--add-opens" option
--add-opens <source-module>/<package>=<target-module>(,<target-module>)*
for example you have an error:
java.lang.ClassLoader.findLoadedClass(java.lang.String)
First open String java 11 documentation
Class String where you can find module and package name
Module java.base, Package java.lang
Solution:
java --add-opens=java.base/java.lang=ALL-UNNAMED -jar example.jar
If you want to go with the add-open option, here's a command to find which module provides which package ->
java --list-modules | tr # " " | awk '{ print $1 }' | xargs -n1 java -d
the name of the module will be shown with the # while the name of the packages without it
NOTE: tested with JDK 11
IMPORTANT: obviously is better than the provider of the package does not do the illegal access
How to suppress "warning: Ignoring InnerClasses attribute for an anonymous inner class" with Gradle?
This not a duplicate question
This not during Proguard nor do I want to suppress using Proguard
I would like to suppress doing normal ./gradlew assembleDebug (since this is assertj-core - ./gradlew testDebug)
Dependency:
dependencies {
testCompile "org.assertj:assertj-core:1.7.1"
}
Warning:
Dex: warning: Ignoring InnerClasses attribute for an anonymous inner class
(org.assertj.core.internal.cglib.reflect.FastClassEmitter$3) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
Something like:
tasks.withType(JavaCompile) {
sourceCompatibility = JavaVersion.VERSION_1_7
targetCompatibility = JavaVersion.VERSION_1_7
configure(options) {
compilerArgs << "-Xlint:-options" // Turn off "missing" bootclasspath warning
}
}
What compilerArgs can I add to suppress this warning?
References:
I have an answer here but none of these suppress this warning: How do I suppress warnings when compiling an android library with gradle?
I had the same issue when I tried to use a third party lib a while ago. That lib was compiled for Java 1.3. I was able to fix it by getting the source of that lib and build a jar file on my own. This works only, of course, if the sources to that lib are available and ready for build.
#SuppressWarnings("unchecked") with replacing the unchecked does not help?
More examples are here:
http://www.codejava.net/java-core/the-java-language/suppresswarnings-annotation-examples
I dived into Antlr a while ago, but I've noticed that the compile times are unbelievably long (the progress will sit at 100% for 5 minutes while Eclipse complains about Antlr). When all Antlr references are removed, but antlr-3.4-complete.jar is still included, the problem persists. As soon as it is removed from the build path, the compile time goes back down to infinitesimal.
Also, compiling more than once in a Eclipse session causes an out of memory error.
What could be going on? Is it really recompiling the whole ANTLR library every time? How can I compile it in a timely manner?
Edit: The complaints eclipse gives are warning about inner classes (as shown below).
[2012-08-13 22:23:39 - HoloCalc] Dx warning: Ignoring InnerClasses
attribute for an anonymous inner class
(antlr.TokenStreamRewriteEngine$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is not an inner class.