In my application that runs on java 8, I am using -bootclasspath:p to add a jar to the boot classpath. In java 9, the option is removed. What is the alternative to do the same in java 9?
You may use -Xbootclasspath/a. Please refer to the release notes which states:-
The boot class path has been mostly removed in this release. The java
-Xbootclasspath and -Xbootclasspath/p options have been removed.
The javac -bootclaspath option can only be used when compiling to JDK 8 or
older. The system property sun.boot.class.path has been removed.
Deployments that rely on overriding platform classes for testing
purposes with -Xbootclasspath/p will need to changed to use the
--patch-module option that is documented in JEP 261.
The -Xbootclasspath/a option is unchanged.
-bootclasspath:p add classes from jar to the begin of default bootstrap class path (prepended). It isn't longer supported in JVM 9 or greater.
-bootclasspath:a add classes from jar to the end of default bootstrap class path (appended). This option is supported in JVM 9 or greater.
https://docs.oracle.com/cd/E15289_01/JRCLR/optionx.htm#i1021218
In my case when I declare variables in this order:
JAVA_OPTS="$SOME_OPT"
JAVA_OPTS="-javaagent:../agent.jar -Xbootclasspath/a:../agent-boot.jar $JAVA_OPTS"
I catch classNotFoundException. And when I reverse order:
JAVA_OPTS="-javaagent:../agent.jar -Xbootclasspath/a:../agent-boot.jar $JAVA_OPTS"
JAVA_OPTS="$SOME_OPT"
ClassNotFound exception disappear.
Related
All the documentation I've been able to find mentions the 'jre/lib/ext' folder but such does not exist on my JRE 13 installation.
I guess somewhere between Java 8 (where I can see the jars in jre/lib/ext) and Java 13, they moved but I've been unable to pinpoint when and how it was done.
Could someone please elaborate what's going on with new JRE's, in terms of where the extension classes reside currently?
The extension mechanism is gone with Java 9, not only moved [:-| , see the Important Changes and Information for Java 9:
The deprecated Extensions Mechanism has been removed. The runtime will refuse to start if ${java.home}/lib/ext exists or the system property java.ext.dirs is specified on the command line.
And also the Changes to the Installed JDK/JRE Image in JDK 9 Migration Guide:
In previous releases, the extension mechanism made it possible for the runtime environment to find and load extension classes without specifically naming them on the class path. In JDK 9, if you need to use the extension classes, ensure that the JAR files are on the class path.
It seems like the SharedSecrets and JavaLangAccess classes from the sun.misc package were removed in Java 9.
Are there any replacements in Java 9 for the functionality provided by these classes?
Both the above classes are packaged in jdk.internal.misc package.
One way you can try and access them is by using the option
--add-exports <source-module>/<package>=<target-module>(,<target-module>)*
for your use case as :
--add-exports java.base/jdk.internal.misc=your.module
Note:- Disclaimer from JEP-261:Module System -
The --add-exports and --add-opens options must be used with great
care. You can use them to gain access to an internal API of a library
module, or even of the JDK itself, but you do so at your own risk: If
that internal API is changed or removed then your library or
application will fail.
According to Bug#JDK-8137056
In preparation for JEP 160, SharedSecrets and friend interfaces should
be moved out of 'sun.misc' and located in a truly private package
And they are now available at jdk.internal.misc
Move SharedSecrets and friends to jdk.internal.misc
This question already has answers here:
Proper fix for Java 10 complaining about illegal reflection access by jaxb-impl 2.3.0?
(4 answers)
Closed 2 years ago.
I have a Java applet which provides a GUI to invoke a web service. It uses Jaxb to parse the XML data and unmarshall it into objects. It runs correctly with Java 1.5 to 1.8. With Java 9, not so much.
I use a container HTML to launch it in Internet Explorer 8 + JDK 9:
<applet code="com.blah.MyApplet" archive="myFatJarWithDependencies.jar" mayscript>
<param name="cache_option" value="no" />
</applet>
The applet loads fine and seems to work; however, once I connect to the web service, it kind of stops working. I have narrowed it down to this code fragment (where Foo is an auto-generated class with XML bind annotations):
System.out.println("1");
JAXBContext jc = JAXBContext.newInstance(Foo.class);
System.out.println("2");
Java's console shows the 1, and then... nothing: it doesn't crash, the applet is still responsive to mouse clicks, it doesn't throw any exceptions... there seems to be no error at all. Except for the fact that it doesn't do anything with the received data, and it never outputs the 2. I've tried alternative JAXBContext.newInstance methods (with a package name, with a package name plus a class loader), but they all do the same.
If I run the project from Eclipse Oxygen with the same JDK 9, it does work. When I connect to the web service, it outputs a few warnings, including these:
WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector
(file:/C:/.../.m2/repository/com/sun/xml/bind/jaxb-impl/2.0/jaxb-impl-2.0.jar) to method
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access
operations
But then it goes on and loads the data (and outputs the 2 to the console). My guess is it's the same problem, even if the warnings are not shown in the Java console. Maybe the JDK defaults to --illegal-access=deny when it's being run from IE? Or "silently-deny-so-the-user-dont-have-a-clue-on-whats-happening"...
Is there any way in which I can pass the --illegal-access=permit option to the JVM? (Keep in mind that I'm not directly invoking the JVM, I only have an <applet> html tag)
Is there any other way to make it work? Perhaps add something extra in my applet's manifest file? (Which, by the way, looks like this):
Manifest-Version: 1.0
Build-Jdk: 1.8.0_144
Application-name: Blah
Permissions: all-permissions
Sealed: true
Name: blah/Blah.class
SHA-256-Digest: kpf244234234..ahjsdfksf=
...
These are the Jaxb dependencies I was using originally:
javax.xml.bind : jaxb-api : 2.0
com.sun.xml.bind : jaxb-impl : 2.0
com.sun.xml.bind : jaxb-xjc : 2.0
I tried updating them from v2.0 to v2.3.0, which are supposed to be compatible with Java 9:
javax.xml.bind : jaxb-api : 2.3.0
com.sun.xml.bind : jaxb-impl : 2.3.0
com.sun.xml.bind : jaxb-core : 2.3.0
com.sun.xml.bind : jaxb-xjc : 2.3.0
But the problem still persists. Also tried these after nullpointer's answer, with no luck either:
javax.xml.bind : jaxb-api : 2.1
javax.xml : jaxb-impl : 2.1
removed the jaxb-xjc, apparently it's not needed...
Maybe the JDK defaults to --illegal-access=deny when it's being run from IE?
No, the current default mode of JDK is permit only.
--illegal-access=permit opens each package in each module in the
run-time image to code in all unnamed modules, i.e., to code on the
class path, if that package existed in JDK 8. This enables both static
access, i.e., by compiled bytecode, and deep reflective access, via
the platform's various reflection APIs.
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.
This mode is the default in JDK 9. It will be phased out in a future
release and, eventually, removed.
Is there any other way to make it work?
For using the jaxb-api would suggest you follow this answer to make sure that your module uses the javax.xml.bind:jaxb-api:2.3.0 instead of com/sun/xml/bind/jaxb-impl/2.0/jaxb-impl-2.0.jar as seen in your logs.
You can configure the maven-compiler-plugin:3.7.0 as stated in the documentation here to compile sources from 1.5 to JDK 8 in different execution and JDK in alternate execution.
For whatever reason I had to change pc's as a result of the change I now have to use Java 6 (the final update) Instead of java 7. When importing my existing project to Java 6 I get the following error in my auto generated code that was generated by Netbeans and is not modifiable
cannot find symbol
symbol: variable Type
location: class Window
frame.setType(java.awt.Window.Type.POPUP); //Type is underlined
The output for the error is as follows:
javac: invalid target release: 1.7
Usage: javac <options> <source files>
use -help for a list of possible options
C:\Users\Adminstrator\Downloads\NetBeansProjects\NetBeansProjects\Pat0.3\nbproject\build-impl.xml:915: The following error occurred while executing this line:
C:\Users\Adminstrator\Downloads\NetBeansProjects\NetBeansProjects\Pat0.3\nbproject\build-impl.xml:268: Compile failed; see the compiler error output for details.
What does this do? Is it necessary, would deleting that the component help? Which component is it, is there a quick fix?
Your build.xml specifies the target="1.7" flag to javac, which java 6 doesn't know how to interpret. Changing it to 1.6 will technically get past that error.
However, the enum Window.Type was added in Java 7, so you simply can't expect changing the target to work; your project's source uses Java 7 features. I'm sure that's not the only one.
Your options are therefore to methodically go through and remove/replace all Java 7 code (likely introducing some bugs) or just to.. install Java 7.
There is somewhere in your project a setting for the java compiler that tells it to generate classes for jre7. javac from jdk6 cannot generate classes for that version, hence the error. So you should look into the properties of your project and set up javac to generate classes for jr6. You might also have fix some of your non-generated code if for example you have used features that came with java 7 such as diamond operator or multy catch block etc.
Also the javadoc for Window.Type states it is available only since 1.7. You might want to re-generate that code or better yet just install jdk7.
I found some classes designed for debugging in package com.sun.jdi like VirtualMachine, but I can't use this because package seems not exist in Sun JDK7.
How to use this package?
BTW. lib/sa-jdi.jar isn't the same I want
According to this page, the VirtualMachine class that you linked to is part of the tools.jar file which is only distributed in a JDK (not a JRE). It says ...
"Update Note 2: The Attach API is in tools.jar, so you will need to add /lib/tools.jar in your CLASSPATH to compile and run the example on JDK 6."
... and the same advice would apply on (at least) JDK 7 as well.