This question already has answers here:
Legacy Java code use of com.sun.net.ssl.internal.ssl.Provider()
(3 answers)
Closed 2 years ago.
I'm migrating an old Java(Maven) project to Java 11. I've changed the pom.xml to support Java 11 (maven compiler plugin with <release>11<release>) and executed mvn clean compile to see whether the code compiles.. but it fails on a line which refers ssl provider from com.sun.net package
java.security.Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider())
The compilation error message is as follows
[ERROR]
/D:/Workspace/sampler/src/com/sampler/test/cloudtest/CloudTest.java:[32,70]
package com.sun.net.ssl.internal.ssl is not visible (package
com.sun.net.ssl.internal.ssl is declared in module java.base, which
does not export it)
Please help me to resolve this by providing proper ssl provider in Java11.
This was removed as a part of this bug https://bugs.openjdk.java.net/browse/JDK-8218932:
Clean up the code and remove the internal package com.sun.net.ssl.
Note that an application may still use the name "com.sun.net.ssl.internal.ssl.Provider" as the SunJSSE provider name. For compatibility, the name is still supported in the JDK. The actual implementation refers to the sun.security.ssl.SunJSSE class.
With this update, the SunJSSE provider can be specified with one of the following names:
SunJSSE
com.sun.net.ssl.internal.ssl.Provider
Both "SunJSSE" and "com.sun.net.ssl.internal.ssl.Provider" are existing names.
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.
This question already has answers here:
Accessing com.sun.tools.javac.util from Java 9
(2 answers)
Closed 3 years ago.
I've been trying to modify the AST using annotation processors. I tried extending Lombok, but that seemed too hard, so I decided to use things from com.sun.source.* and com.sun.tools.javac.* However, I am using java 11, and the document I was learning from, "The Hacker's Guide to Javac" http://scg.unibe.ch/archive/projects/Erni08b.pdf, uses Java 6. The api they used is now internal and my module cannot read it.
In IntelliJ, it gave me a few errors, but I clicked on the suggestions (which said things like "Add --Xxx-xxx to xxx" without paying attention to them. When I tried compiling with Maven, it failed, since the module does not read the internals of jdk.compiler.
These are some of my imports:
import com.sun.source.util.Trees;
import com.sun.tools.javac.tree.JCTree;
import com.sun.tools.javac.tree.TreeMaker;
import com.sun.tools.javac.tree.TreeTranslator;
import com.sun.tools.javac.util.Context;
My module-info file contains
requires jdk.compiler;
requires java.compiler;
I got messages like "[ERROR]package com.sun.tools.javac.util is declared in module jdk.compiler, which does not export it to module OtherAnnot" and "[ERROR] (package com.sun.tools.javac.tree is declared in module jdk.compiler, which does not export it to module OtherAnnot)"
Edit: I guess this is a duplicate, but I wanted to know if there was some alternative API for AST transformations in java 9.
With the introduction of Project Jigsaw, the JDK has been modularized, allowing users to create their own modules as well. These modules allows you to export packages of yours, allowing programs that require your module (in their module-info.java) to use the exported packages.
Ideally, you'd be prohibited from using classes that reside in packages that are not exported. However, to not break backwards compatibility, VM flags were introduced that allow you to forcefully export packages (that don't belong to you) to your module.
Given your error message, the respective VM flag to add is:
--add-exports jdk.compiler/com.sun.tools.javac.tree=OtherAnnot
The pattern here is:
--add-exports THEIR_MODULE/THEIR_PACKAGE=YOUR_MODULE
If the compiler complains that packages aren't exported to the unnamed module, then you can use the following:
--add-exports THEIR_MODULE/THEIR_PACKAGE=ALL-UNNAMED
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'm trying to export a signed obfuscated version of my Android application and I keep getting this error. I recently added the v4 compatibility library and haven't been able to export a signed APK since then. Any help would be appreciated.
Notes: Using SDK 12 and the default proguard.cfg
Here's the console output:
Proguard returned with error code 1. See console
Warning: android.support.v4.os.ParcelableCompatCreatorHoneycombMR2: can't find superclass or interface android.os.Parcelable$ClassLoaderCreator
Warning: android.support.v4.os.ParcelableCompatCreatorHoneycombMR2: can't find referenced class android.os.Parcelable$ClassLoaderCreator
Warning: android.support.v4.os.ParcelableCompatCreatorHoneycombMR2: can't find referenced class android.os.Parcelable$ClassLoaderCreator
Warning: there were 3 unresolved references to classes or interfaces.
You may need to specify additional library jars (using '-libraryjars'),
or perhaps the '-dontskipnonpubliclibraryclasses' option.
java.io.IOException: Please correct the above warnings first.
at proguard.Initializer.execute(Initializer.java:308)
at proguard.ProGuard.initialize(ProGuard.java:210)
at proguard.ProGuard.execute(ProGuard.java:85)
at proguard.ProGuard.main(ProGuard.java:499)
-dontwarn **CompatCreatorHoneycombMR2 was the answer.