How do I add sun.misc and sun.security dependency in Gradle?

Help/Discuss
1

Hello,

New here, trying out Gradle. I’m trying to convert one of my existing project into Gradle, but it shows that all the sun.xxxx stuff are not found. I tried to add new entries in the dependency section but I can’t find any repo that has anything for sun.misc or sun.security… the thing is though, is supposed to be part of the JDK 1.8 (C:\Program Files\Java\jdk1.8.0_131\jre\lib\ext)

What’s the proper way to tell gradle where it is? There is NOTHING on the web about this…

I’m getting warnings such as:

warning: CRLDistributionPointsExtension is internal proprietary API and may be removed in a future release
import sun.security.x509.CRLDistributionPointsExtension;
warning: DistributionPoint is internal proprietary API and may be removed in a future release
import sun.security.x509.DistributionPoint;
warning: GeneralName is internal proprietary API and may be removed in a future release
import sun.security.x509.GeneralName;

Should I just ignore those?

2

This doesn’t really have anything to do with Gradle. This warning is coming from the JDK. The javac compiler outputs this warning because you’re only supposed to use public APIs, not internal ones. The warning is not that they weren’t found, it’s that they were, but you’re not supposed to use them. If you try to compile a class that imports those classes with just javac, you will see the same warning.

These classes are in the JDK, and you don’t need any additional dependencies for them if you really don’t care that you’re not supposed to use them. If you’ve already decided you’re going to use them anyway, there’s really nothing more to gain from the warnings.

3

When i use this option: options.forkOptions.executable = ‘javac’

I get the message:

The executable property on ForkOptions has been deprecated and is scheduled to be removed in Gradle 5.0. Please use javaHome instead.

There isn’t much on how to use “javaHome” from the documentation. How can i use “javaHome”?

4

There’s a section with example on Java Cross Compilation, but you haven’t said anything that even indicates you need Java cross compilation, so I’m not sure why you’re trying to set a value other than the javac that ships with your current JDK.

5

I don’t need Java Cross Compilation. However, if i don’t set that, then it would complaint:

error: package sun.security.pkcs10 does not exist
import sun.security.pkcs10.PKCS10;

What is the proper way to do things? In order for it to compile without throwing errors, this is what i currently have in the build.gradle file:

allprojects {
	eclipse { jdt { javaRuntimeName = "jre1.8.0_131" } }
	compileJava {
		options.fork = true
		options.forkOptions.executable = 'javac'
		options.compilerArgs += ["-XDignore.symbol.file", "-Xlint:unchecked"]
	}
}
6

It sounds like you’re trying to use JDK 1.8 with classes that were only available until JDK 1.7 (hence the reason classes like this warn about it possibly being removed in a future release, if they work). I would guess you’re trying to build a Java 7 app with Java 8, but your code is incompatible and your environment is inconsistent on which Java version is on the PATH vs. set as JAVA_HOME.

7

All the sun.security.* that I use are in JDK 1.8 though.
Are these issues even related though?

ForkOptions has been deprecated and is scheduled to be removed in Gradle 5.0.

It Gradle complaints about ForkOptions will be gone, what will be the proper way to use “javaHome”? I did tried this section to use “javaHome” but it just throws more errors about JavaDoc instead:
https://docs.gradle.org/3.5/userguide/java_plugin.html#sec:java_cross_compilation

8

From what you posted, you are using:

sun.security.pkcs10.PKCS10
sun.security.x509.CRLDistributionPointsExtension;
sun.security.x509.DistributionPoint;
sun.security.x509.GeneralName;

Only the last 3 are in JDK 1.8. You can’t use sun.security.pkcs10.PKCS10 unless you use JDK 1.7.

No, the deprecation warning from Gradle is about using a mechanism for cross compilation that is deprecated. It has nothing to do with the warnings or error about the classes in sun.security.* that you’re using.

The basic change with ForkOptions is that you’re supposed to provide a path to JAVA_HOME for the JDK as javaHome instead of the equivalent of $JAVA_HOME/bin/javac as executable. You would normally provide a full path to either. By just providing javac as the executable, you’re basically specifying the one on your PATH which must be different than the one you’re running with for the difference in behavior.

I don’t know what JDKs you have on your machine, how you’re configured, or what your application actually requires. My primary point of emphasis here is that it is better to identify the underlying issue with the code (you either require Java 1.7 or have an unintended import) before adding configuration that should not be relevant for your use case.

9

Yeah, well I’m still trying to figure the whole gradle thing out myself.
I have the normal Java JDK 1.8 installed on my machine, there is nothing fancy to it.
Correct me if i am wrong, but looking into the rt.jar, I could see the pkcs10.PKCS10 class is there, just that is not a “not API” and was giving me Access Restriction errors.

And since it wasn’t public API, I had to force it in eclipse to set the JRE System Library to be Alternate JRE in order to get rid of the non API access restriction. So to do that, I had to put the following in my build.gradle file javaRuntimeName = "jre1.8.0_131"

Could this be the side-effect of using the javaRuntimeName then?

10

The class sun.security.pkcs10.PKCS10 was removed from the JDK. You’re seeing that class in the JAR that is used at runtime by the JRE. It’s likely there to maintain backwards compatibility, but using a class that was internal and already removed from the JDK is going a step beyond just using an internal API.

No, that will only affect Eclipse, but as you’re providing more information, it’s becoming clearer what’s causing the difference in behavior. The difference is whether or not the -XDignore.symbol.file argument is supported by the compilation method. Depending on whether or not you specify forkOptions.executable or forkOptions.javaHome, you get the command line compiler or the Java Compiler API. The former supports -XDignore.symbol.file, while the later does not.

I still think it would be better if you switched to something non-internal (BouncyCastle is an option), but if you’re not willing or able to do that, I would probably set the forkOptions.javaHome to be the same Java home that you’re currently using. If you’re going use those classes and -XDignore.symbol.file, you need cross-compilation behavior, even if you don’t care about cross-compilation for the usual reason.

compileJava {
    options.forkOptions.javaHome = file(System.properties['java.home'])
}
1 Like
11

Thank you. I will eventually try to switch everything to BouncyCastle, but that’s a lot of old code to get refactor. However, I believe your suggestion is the right way to go.

Thank you James!