Gradle change java version

2 Set java home in Gradle properties

Setting up a consistent environment for your build is as simple as placing these settings into a gradle.properties file. The configuration is applied in following order (if an option is configured in multiple locations the last one wins):

• gradle.properties in project root directory.
• gradle.properties in GRADLE_USER_HOME directory.
• system properties , e.g. when -Dgradle.user.home is set on the command line.

3 Changes to project build.gradle

Tell build.gradle files that you will be using java 9

sourceCompatibility = JavaVersion.VERSION_1_9 targetCompatibility = JavaVersion.VERSION_1_9

Java 9

You don’t need to manually change the build.gradle files, they are already modified

4 Dowload and install openjdk 9

cd Downloads tar xvf openjdk-9.0.4_osx-x64_bin.tar.gz sudo mv jdk-9.0.4.jdk /Library/Java/JavaVirtualMachines

Update JAVA_HOME environment variable.

4.1 Mac OS X

Check jdk1.9 is properly installed

/Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home

To check all Java versions installed

Matching Java Virtual Machines (6): 9.0.4, x86_64: "OpenJDK 9.0.4" /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home 1.8.0_131, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home 1.8.0_77, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home 1.8.0_60, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home 1.7.0_75, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_75.jdk/Contents/Home 1.7.0_67, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home

Open ~/.bash_profile in any text editor and add:

export JAVA_HOME=$(/usr/libexec/java_home -v 9)

Open a Terminal and run the source command to apply the changes:

Now we can check the value of the JAVA_HOME variable:

/Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home

The result should be the path to the JDK installation:

4.2 Linux

To set JAVA_HOME in Linux for a single user, we can use /etc/profile or /etc/environment (preferred for system-wide setting) or ~/.bashrc (user specific setting).

Open ~/.bashrc in any text editor and add:

export JAVA_HOME=/path/to/java_installation

Run the source command to load the variable:

Now we can check the value of the JAVA_HOME variable:

The result should be the path to the JDK installation:

4.3 Windows

4.3.1 Windows 10 and 8

1. Open Search and type advanced system settings
2. In the shown options, select the View advanced system settings link
3. Under the Advanced tab, click Environment Variables
4. In the System variables section, click New (or User variables for single user setting)
5. Set JAVA_HOME as the Variable name and the path to the JDK installation as the Variable value and click OK
6. Click OK and click Apply to apply the changes

4.3.2 Windows 7

1. On the Desktop, right-click My Computer and select Properties
2. In the System variables section, click New (or User variables for single user setting)
3. Set JAVA_HOME as the Variable name and the path to the JDK installation as the Variable value and click OK
4. Click OK and click Apply to apply the changes

Open Command Prompt and check the value of the JAVA_HOME variable:

The result should be the path to the JDK installation:

C:\Program Files\Java\jdk1.8.0_111

5 Most Common Challenges

5.1 Dependencies On Java EE Modules

There’s a lot of code in Java SE that’s actually Java EE related. It ended up in these six modules:

• java.activation with javax.activation package
• java.corba with javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages
• java.transaction with javax.transaction package
• java.xml.bind with all javax.xml.bind.* packages
• java.xml.ws with javax.jws, javax.jws.soap, javax.xml.soap, and all javax.xml.ws.* packages
• java.xml.ws.annotation with javax.annotation package

For various compatibility reasons (one of them being split packages, which we will look at next), code on the class path does not see these modules by default, which leads to compile or run time errors.

5.1.1 JAXB deprecated

Java’s standard library isn’t exactly small and lightweight. In the course of the past 20+ years, many features have been added to it, mostly because at the time it was thought that it would be a good idea if Java supported a particular technology out-of-the-box.

One of these was support for XML-based web services. When Java SE 6 was released in December 2006, XML-based web services were popular, so the developers of the Java language thought it would be a good idea if Java would have support for calling web services as a standard feature. It was decided to add the necessary APIs, that were originally developed as part of Java EE, to Java SE. Among these were JAX-WS (Java API for XML-Based Web Services) and JAXB.

With today’s trend towards microservices, it’s important that the Java runtime environment is small and lightweight, so having a large runtime library with built-in support for every possible technology isn’t as advantageous anymore.

Therefore, a proposal was made in JEP-320 to remove the Java EE and CORBA modules from the JDK.

• In Java SE 9 and 10, the module java.se.ee, which contains JAX-WS, JAXB and a few other Java EE APIs, is still included but is deprecated, and not included in the module path by default. You need to explicitly enable it if you want to use it.
• In Java SE 11, the module java.se.ee has been removed. To use JAX-WS and JAXB you need to add them to your project as separate libraries.

Adding JAXB as a separate library

The proper solution is to add the JAXB as a dependency to your project – in the same was as you would have done long ago, before Java 6.

The official JAXB API dependency can be found in the Maven Central repository, so if you’re using Maven, you’ll want to add the following dependency to your project:

Like many Java EE APIs, JAXB is just an API – a specification of a number of classes and interfaces. To use JAXB you not only need to have a dependency on the API, you also need to make sure that an implementation of the API is available in the runtime environment of your program.

When your program is running in a Java EE container, there might already be an implementation of JAXB available so you won’t need to add it. When you run your program on a plain Java runtime environment, you’ll need to include an implementation yourself.

You have several options at this point. You can use the reference implementation of JAXB, which was what was formerly included in the JDK, or you can use an alternative implementation such as EclipseLink MOXy.

Using the reference implementation

There are Maven artifacts available for the official JAXB reference implementation.

he JAXB Users Guide refers to the following artifact:

 org.glassfish.jaxb jaxb-runtime 2.3.1 runtime 

Using EclipseLink MOXy

EclipseLink MOXy is an alternative implementation of the JAXB API that you might want to use. To use this, include the following dependency in your project next to the dependency on javax.xml.bind:jaxb-api:

 org.eclipse.persistence org.eclipse.persistence.moxy 2.7.3 runtime 

5.2 llegal Access To Internal APIs

One of the module system’s biggest selling points is strong encapsulation. It makes sure non-public classes as well as classes from non-exported packages are inaccessible from outside the module. First and foremost, this of course applies to the platform modules shipped with the JDK, where only java.* and javax.* packages are fully supported. Most com.sun.* and sun.* packages, on the other hand, are internal and hence inaccessible by default.

The most obvious and sustainable fix for dependencies on internal APIs is to get rid of them. Replace them with maintained APIs and you paid back some high-risk technical debt.

If that can’t be done for whatever reason, the next best thing is to acknowledge the dependencies and inform the module system that you need to access it.

Access to certain internall JDK apis has been restricted

5.2.1 com.sun.net.ssl.internal.ssl.Provider

Luckily exists and alternative in the accessible API for com.sun.net.ssl.internal.ssl.Provider , just replace:

java.security.Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());

java.security.Security.addProvider(Security.getProvider("SunJSSE"))

5.2.2 sun.security.x509

In this case, we must make the package accessible by adding the following compilers args to the build.gradle file:

tasks.withType(AbstractCompile) < options.compilerArgs += ["--add-exports", "java.base/sun.security.x509=ALL-UNNAMED"] >

6 IDE setup

6.1 Intellij

6.1.1 Setting java 9 JDK

1. Target bytecode version: go to Settings > Compiler > Java Compiler and update the Target bytecode version
   
2. Setup the project SDK : go to File > Project Structure > Project > Project SDK and add the link to the local Java installation. If the jdk doen’t show up, it can be added with the New.. option
   
3. Set Java Runtime Environment: We need to edit the Run/Debug Configurations. With the Navigation bar visible (View | Navigation Bar), the available run/debug configurations are displayed in the run/debug configuration selector in the Run area. Select the option Edit configuration and in the dialog box, select the appropriate JRE

6.1.2 Illegal acces to internal API or ‘module XXX is not visible’ issues

Should the IDE compiler complain about illegal access to internal API, it can be solved in Settings > Compiler > Java Compiler > Override Compiler parameters per module . The following parameters are required:

Module	Compilation options
axional-server-console-test	—add-modules=jdk.httpserver —add-exports=java.base/sun.security.x509=ALL-UNNAMED
axional-server-dbstudio_main	—add-modules=jdk.scripting.nashorn —add-exports=jdk.scripting.nashorn/jdk.nashorn.internal.runtime=ALL-UNNAMED

6.2 Eclipse

1. Setup JDK: go to Windows > Preferences > Java > Installed JRE’s and check if your required jre/jdk is available or not as given in image below:
2. Compiler compliance level : go to Windows > Preferences > Java Compiler and as per the image set the compliance compiler level as per your requirements. If you don’t want tochange the compliace compiler level for all the workspace, click on the project and right click, then go to Properties > Java Compiler an set the compliance compiler level as per your requirements.

6.2.1 Illegal acces to internal API Issues

Should the IDE compiler complain about illegal access to internal API, it can be solved in:

Project properties > Java Build Path > Libraries tab > Modulepath > JRE System Library > is modular > Edit. .

Contents tab > Avaliable modules select jdk.httpserver and jdk.scripting.nashorn

and make them explicitly indcluded vis the right arrow in between the boxes.

By clicking the Add button in the Details tab > Added exports > the following window will show up: The following modules must be added:

Source module	Package	Target modile
java.base	sun.security.x509	ALL-UNNAMED
java.base	jdk.internal.misc	ALL-UNNAMED
jdk.scripting.nashorn	jdk.nashorn.internal.runtime	ALL-UNNAMED

• 1. Upgrade gradle wrapper
• 2. Set java home in Gradle properties
• 3. Changes to project build.gradle
• 4. Dowload and install openjdk 9
  • 4.1. Mac OS X
  • 4.2. Linux
  • 4.3. Windows
    • 4.3.1. Windows 10 and 8
    • 4.3.2. Windows 7
    • 5.1. Dependencies On Java EE Modules
      • 5.1.1. JAXB deprecated
      • 5.2.1. com.sun.net.ssl.internal.ssl.Provider
      • 5.2.2. sun.security.x509
      • 6.1. Intellij
        • 6.1.1. Setting java 9 JDK
        • 6.1.2. Illegal acces to internal API or ‘module XXX is not visible’ issues
        • 6.2.1. Illegal acces to internal API Issues

        Источник