Develop Reference

Java 11 include jdk.compiler/com.sun.tools.javac classes into project

I need to work with com.sun.tools.javac classes that are private and are not visible neither during compile nor run time.
I use:
JDK 11.0.15
Maven build tool
Intellij IDEA
My current state is that my imports are red-highlghited and compilation fails.
My class I want to use sun tools inside (sorry for the pic instead of code, my class is 2000+ lines length, for now I only care about availability of tools in my class):
pom.xml:
...
<properties>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<source>11</source>
<target>11</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
I need to be able to have these classes available as I "type", during mvn compile and in runtime.
com.sun packages I'd like to have:
com.sun.tools.javac.code
com.sun.tools.javac.comp
com.sun.tools.javac.file
com.sun.tools.javac.main
com.sun.tools.javac.model
com.sun.tools.javac.parser
com.sun.tools.javac.processing
com.sun.tools.javac.tree
com.sun.tools.javac.util
Thank you in advance!

I was able to make it work with the following compiler plugin configuration.
<compilerArgs>
<arg>--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
<arg>--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
<arg>--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg>
<arg>--add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
<arg>--add-opens=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg>
<arg>--add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED</arg>
<arg>--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
<arg>--add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg>
<arg>--add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg>
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg>
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED</arg>
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg>
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>
</compilerArgs>
And other thing that broke my code was maven-javadoc-plugin added to my plugins.

The Javadoc for package com.sun.tools.javac in Java 11 says:
This package provides a legacy entry point for the javac tool. See the jdk.compiler module for details on replacement APIs.
👉 Access the module java.compiler, package javax.tools, for the interface JavaCompiler and class ToolProvider.
See the Javadoc for example code.
The com.sun package was never standard, never supported, and never intended for external use.
See JEP 403: Strongly Encapsulate JDK Internals.

Maven :: Multi-Module project built by different JDK per module [duplicate]

My maven project has a few modules: server, web, etc.
I would like to build all but my server module on Java 6. For the server module, I'd like to compile it with Java 7.
Here's my pom.xml below, but I think that if I modify it to 1.7, then all of my modules will be compiled with Java 7. Also, does maven use the JAVA_HOME environment variable to determine which Java version to use?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<memmax>2048m</memmax>
</configuration>
</plugin>
EDIT Also, does the below output of
maven --version
indicate that maven is compiling my java code with 1.7?
vagrant#dev:~/bin/apache-tomcat-7.0.29/bin$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+0000)
Maven home: /home/vagrant/bin/apache-maven-3.0.4
Java version: 1.7.0_07, vendor: Oracle Corporation
Java home: /home/vagrant/bin/jdk1.7.0_07/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.2.0-23-generic", arch: "amd64", family: "unix"
Thanks,
Kevin

There are a number of hacks out there for compiling source code with a different version of the JDK than you are using to run Maven, for example you can use something like
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<executable><!-- path-to-javac --></executable>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
The issue with this approach is that you now have hard-coded the path to the JDK into your POM. Everything will work just fine on your machine but when you have to rebuild your machine because the HDD failed, or when you want to build on a different machine, you will be stuck as the path will most likely not match up.
The correct best practice way to handle this is via Toolchains. This will see you creating a ~/.m2/toolchains.xml file that describes where each of the different toolchains in your system are. Then the version of the JDK can be applied by the Maven Toolchains Plugin, e.g.
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-toolchains-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>toolchain</goal>
</goals>
</execution>
</executions>
<configuration>
<toolchains>
<jdk>
<version>1.6</version>
</jdk>
</toolchains>
</configuration>
</plugin>
...
</plugins>
The next thing is that you don't need this as often as you would think. For example by using the source and target values you can generate the correct bytecode for the JRE that you are targeting... the only issue that you will then hit is the use of methods that are new in JRE 1.7... which is where Mojo's Animal Sniffer Plugin comes in. Animal Sniffer can be used to ensure that you only use the methods of the JRE that you are targeting. The general community consensus is that the use of source and target configuration options in the Maven Compiler Plugin configuration coupled with the use of Mojo's Animal Sniffer virtually eliminates the need for toolchains on the Compiler end of things.... on the Surefire end of things there is still need for toolchains... and I have a few edge cases that I need to update the compiler plugin and the toolchains plugins for to handle but, realistically you will not hit those edge cases ;-)
Just to be sure that your original question is completely answered (since the above answers the question you wanted to ask - as opposed to the one you asked)
At present you are compiling with JDK 1.7 however depending on the version of the Maven Compiler Plugin you are using, you may be compiling with either <source>1.4</source><target>1.4</target> or <source>1.5</source><target>1.5</target> unless you have changed the configuration of the Maven Compiler Plugin in your pom.xml. That will dictate which language features are available to you, but not which classes... so you would be generating code that will work on JRE 1.7 and provided you have not used any new classes/methods introduced since 1.4/1.5 (Such as String.isEmpty()) should also work on JRE 1.4/1.5... the only way to be sure if it works on such an old JVM is to either: run it on the old JVM OR use Animal Sniffer.

Maven Toolchains
To use multiple Java versions, you need to use Maven Toolchains, which require you to create a toolchains.xml file in your ~/.m2 Maven folder, containing all Java versions installed on your machine:
<toolchains>
<toolchain>
<type>jdk</type>
<provides>
<id>Java13</id>
<version>13</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_13}</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<id>Java9</id>
<version>9</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_9}</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<id>Java8</id>
<version>8</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_8}</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<id>Java7</id>
<version>7</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_7}</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<id>Java6</id>
<version>6</version>
</provides>
<configuration>
<jdkHome>${env.JAVA_HOME_6}</jdkHome>
</configuration>
</toolchain>
</toolchains>
The JAVA_HOME_13, JAVA_HOME_9, JAVA_HOME_8, JAVA_HOME_7, JAVA_HOME_6 environment variables are configured so that they reference the path where the associated Java version is installed.
The FlexyPool parent pom.xml configuration file
The parent pom.xml Maven configuration file of the FlexyPool project defines the global Java version settings
<properties>
<jdk.version>8</jdk.version>
...
</properties>
Now, we need to instruct both the compiler and the test plugins to use the configured java version.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-toolchains-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<goals>
<goal>toolchain</goal>
</goals>
</execution>
</executions>
<configuration>
<toolchains>
<jdk>
<version>${jdk.version}</version>
</jdk>
</toolchains>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven-compiler-plugin.version}</version>
<configuration>
<source>${jdk.version}</source>
<target>${jdk.version}</target>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
</plugin>
</plugins>
</build>
The FlexyPool child Maven module pom.xml using a different Java version
The flexy-pool-core-java9 child Maven module that requires a different Java version only needs to override the default jdk.version Maven property:
<properties>
<jdk.version>9</jdk.version>
</properties>
And that's it, we can now build each module using its own minimum viable Java version.

use the setup for the JDK6 on your top pom, it will be inherited by all the module, and overwrite it for your server pom with the different configuration required.
As for the path of the JDK, you can specify it, see here: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html

Maven skip compile

I want to use Maven to execute a certain plug-in that only needs the source code but I do not want Maven to compile anything (mostly because the project just doesn't compile).
How do I tell Maven to skip the compile step and just launch its plug-in and then package the generated resources together in a nice JAR? (The procedure of the last step is already known to me.)
Additional Info:
So we tried a lot of things right now, e.g.:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.0</version>
<configuration>
<excludes>
<exclude>**/*</exclude>
</excludes>
<source>1.7</source>
<target>1.7</target>
</configuration>
<executions>
<execution>
<phase>deploy</phase>
</execution>
</executions>
</plugin>
Though when we do a mvn package we get this:
[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) # project ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling ALOTOF source files to /home/myname/dir/dir/project/target/classes
message edited ofc.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<skipMain>true</skipMain> <--Skip
</configuration>
</execution>
</executions>
</plugin>
Set this to 'true' to bypass compilation of main sources. Its use is
NOT RECOMMENDED, but quite convenient on occasion. User property is:
maven.main.skip.
mvn package -Dmaven.main.skip

Maven functionality is partly organized in plugins, that contains goals. These goals can be executed without being part of a lifecycle. Eg for for the jar-plugin's jar-goal you would invoke:
mvn jar:jar
If you browse through the list of available plugins you will probably find the functionality you are looking for. If it is necessary you could even define an "assembly" to select the files you want to bundle into an archive.

To prevent Maven compilation by default, first make sure that the configuration of maven-compiler-plugin has useIncrementalCompilation = false:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<useIncrementalCompilation>false</useIncrementalCompilation>
</configuration>
</plugin>
Also, in case your Maven Profile uses maven-clean-plugin, then by default it discovers and deletes the directories configured in project.build.directory, project.build.outputDirectory, project.build.testOutputDirectory, and project.reporting.outputDirectory.
To disable these default cleanups, add to maven-clean-plugin configuration: excludeDefaultDirectories = true:
<excludeDefaultDirectories>true</excludeDefaultDirectories>

so I used it like this and it worked. ( false)
<executions>
<execution>
<id>default-compile</id>
<configuration>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
<failOnError>false</failOnError>
<compilerArgument>-Xlint:unchecked</compilerArgument>
<compilerArguments>
<source>${maven.compiler.target}</source>
<target>${maven.compiler.source}</target>
</compilerArguments>
</configuration>
</execution>

I would define a separate pom just for building that separate artifact.
In that pom, you only use your resources generation plugin and the packaging ones.
Then you don't have to worry about it doing too much.

Maven: Build code against Java 1.4, but build test code against Java 1.5

In Maven, I have a codebase that I want to build that needs to target the 1.4 JVM. This is very easy to do in the pom, but I have one problem: The tests for this codebase use 1.5+ constructs.
Is it possible to have Maven compile/run the tests inside a 1.6 JVM, but build the main codebase to target 1.4?
Setting source to 1.6 and target to 1.4 don't work. Maven/Java don't allow this combination.

This is possible, but you need to set the parameters for testCompile rather than compile. You can specify a different target/source combination for the testCompile that you use for the compile.
So for compile you've have a target of 1.4, and testCompile 1.5 or 1.6.
Also, to run the unit tests, you can specify the jvm to use in surefire by using the jvm parameter. This would point to a 1.6 jvm.

It's been awhile since I've done this, but the plugin dependency you want is something like this:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<configuration>
<source>1.3</source>
<target>1.3</target>
</configuration>
</execution>
<execution>
<id>default-testCompile</id>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</execution>
</executions>
</plugin>
link to source

I was able to achieve what I wanted with this:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<testSource>1.6</testSource>
<testTarget>1.6</testTarget>
<target>1.4</target>
<source>1.4</source>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>

What is the best way to avoid maven-jar?

I am using a different plugin (ant4eclipse) to jar my files. What is the best way to avoid the maven-jar plugin from executing?
I tried to remove the <plugin>maven-jar-plugin</plugin>
I tried to <exclude> ** / * < / exclude>
I tried to <skip>true</skip>
None worked

In Maven 3.0.x (I tried 3.0.2) you can disable maven-jar-plugin by binding the default-jar execution to a nonexistent phase, as #bmargulies suggested. Unfortunately that doesn't work in 2.2.1, but you can prevent it from interfering with your own jar by setting an alternative <finalName> and <classifier> for the default-jar execution; it will still create a jar, but it will be set as a secondary artifact for the project and won't overwrite the one you've created. Here's an example that should work in both Maven 2 and Maven 3:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<version>0.1-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
<configuration>
<finalName>unwanted</finalName>
<classifier>unwanted</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Once you've disabled maven-jar-plugin, maven-install-plugin may give you trouble too. In Maven 3 it can be disabled the same as maven-jar-plugin: bind default-install to a nonexistent phase. However, in Maven 2 maven-install-plugin requires that the target/classes directory exist, and it will install the dummy jar when there isn't a primary artifact present.

This should do the trick - notice the use of <id>default-jar</id> and <phase/>.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>default-jar</id>
<phase/>
</execution>
</executions>
</plugin>
</plugins>
</build>

In my case, I only wanted to disable the jar plugin because the jar was empty. You can use the skipIfEmpty option in the plugin configuration
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<skipIfEmpty>true</skipIfEmpty>
</configuration>
</plugin>

What happens if you declare this?
<packaging>pom</packaging>
Even if it does what you're looking for, be careful. I'm not sure if there could be negative side effects -- such as other maven projects that depend on your jar not being able to locate it.

Using maven 3.3.9, the following worked for me:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.1.2</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
<configuration>
<finalName>unwanted</finalName>
<classifier>unwanted</classifier>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>3.0.0-M1</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
So in case of the maven-jar-plugin, I bound it to a non-existent phase. For the maven-install-plugin, I used the "skip" configuration parameter. The documentation about it says: "Set this to true to bypass artifact installation. Use this for artifacts that does not need to be installed in the local repository."

Explicitly bind the jar plugin to a phase that doesn't exist.

As other's have said, it's not possible to turn it off, other than using <packaging>pom</packaging>, which turns everything off and is probably not what you want.
Even though it will generate twice, a working solution is to bind your jar process to the package phase, as that is guaranteed to run after the default. By overwriting the same JAR file, you'll find that yours is used wherever the original would have been.

I am using a different plugin to jar my files. What is the best way to avoid the maven-jar plugin from executing?
First, the jar:jar goal is bound by default on the package phase for a project with a packaging of type jar. Second, there is no way to unbind a plugin bound to a phase. So, if you are using another plugin(?), either accept to produce 2 JARs or change the packaging (but I don't think this will work well).

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>