So far we have been using the Findbugs JSR-305 annotations (com.google.code.findbugs:jsr305) and everything including tool support (Sonar, Eclipse, Findbugs, …) has been working fine.
However it is our understanding that Jigsaw in Java 9 is going to break JSR-305 annotations (one package in two modules is not allowed). This was confirmed at JavaOne 2015. Oracle's reasoning is JSR-305 never happened and JSR-250 would have to endorse these annotations.
We're looking for replacements for JSR-305 annotations that work in both Java 8 and Java 9. If history is any guide the time between Java 9 GA and Java 8 EOL will be rather short and we would like to fix any incompatibilities in our code in advance. In theory we could upgrade the annotations module of the JDK but doing this across our toolchain seems like a lot of work.
It’s true that two modules cannot, ordinarily, define types in the same
package. Until recently, putting jsr305.jar on the class path of a
JDK 9 build would have no effect: That JAR file defines types in the
javax.annotation package but that package is defined in the platform’s built-in
java.xml.ws.annotation module, and the latter takes precedence.
Owing in part to the widespread use of jsr305.jar, however, and also to make
it easier for existing application servers to migrate to JDK 9, we changed
the default set of root modules to exclude the annotations module, among
others. Putting jsr305.jar on the JDK 9 class path works out-of-the-box
with both JDK 9 and JDK 10; details are available in
JEP 261. It will continue
to work out-of-the-box with later releases since the annotations module, along
with all the other Java EE and CORBA modules, were removed in JDK 11
per JEP 320.
Related
knowledge-api maven version don't have new version?
What is the impact will be if other drools libraries upgraded to 7?
As new versions of Drools are released, some Jars are end-of-life'd as their functionality is either subsumed into other jars or no longer supported.
The knowledge-api jar was a part of Drools 6.x, but is not part of Drools 7. This is logical since it was intended to be an adapter from the Drools 5 drools-api jar to the KIE APIs. Since the adapter's purpose was to facilitate backwards compatibility for the previous release, it makes sense it wasn't included in Drools 7 at all, since everything relying on the Drools 5 functionality should have been long since upgraded.
At least for this particular library ...
Version
Jar
Drools 5
drools-api
Drools 6
knowledge-api
Drools 7
kie-api
... though note that these jars are likely not drop-in replacements depending on what you're using from the library itself. The package names and class names usually change between major releases.
knowledge-api was replaced by kie-api
Is it possible for Eclipse to tell you when you're using classes that are available in Java releases beyond your project's compliance level (even though the JDK I'm compiling with technically supports/has those classes)?
I'm using a Java 7 JDK for both my Java 6 and Java 7 execution environments in Eclipse (Version: Kepler Release, Build id: 20130614-0229).
I've set the compliance level of my project to Java 6 since we're compiling to Java 6 compatible byte code to support older JREs and I'm using a JavaSE-1.6 Exeuction environment but backed by a Java 1.7.0_15 JDK.
I recently found myself using something in the java.nio.* package and was surprised that I didn't get an error/warning in Eclipse telling me that my compliance level was Java 6 and this class was not available in Java 6.
Of course, I can always switch to a Java 6 JDK, but I'd prefer to use a Java 7 JDK for both execution environments.
Thanks!
A 7 runtime fulfills the requirements of a 6 Execution Environment. Targeting an actual Java 6 runtime is what you're supposed to do if you want compilation errors using anything that's not in there. Remember, it's not just new classes in 7, it's new methods.
I did several projects using Seam 2 on JBoss5/6 and liked the feature that certain java classes (usually GUI handlers and util classes) could be put in a special src folder and be hot replaced through a special class loader after saving the file and an explode target running automatically afterwards.
Now I like to switch to Java EE 6 + CDI and use JBoss7, so I started with a maven based Java EE web project generated by JBoss tools in eclipse Juno. If I only change xhtml files, I can see the changes after the automatic re-publish, but not so with changes in java files.
Is there a way to get a similar behaviour in my new project setup than I had before with Seam 2 without using 3rd party tools like JRebel?
Edit 2012/07/23:
I add another point to the question - with newer containers like JBoss7, restart of an application seems to go quite fast - so is it even necessary trying to integrate code replacement tools and hoping for the best?
When I evaluated JRebel about a year ago for that stack (Java EE 6 / CDI / JBoss AS 6), even that tool did not cope with CDI. This might have improved in the last 12 months, but generally speaking:
I'm not aware of any advanced hot-deployment support of Java EE 6 on JBoss AS, with or without tooling support.
(If you read the thread to the end the situation seems to be better for GF, but that's out of the scope of your question)
Take a look at JRebel. CDI parts are constantly being improved and although there's still a way to go, it can be quite a time saver. If you find the cases when JRebel fails to deliver, report at the forum and the devs will do their best to improve the experience.
In regards to the second question, even if container startup takes no time, like in case of Tomcat or Jetty, the application deployment time will not get much faster and might still take considerable amount of time.
So the answer is - yes - code replacement tools are still relevant even with the lightweight containers.
This question has always bothered me. And the NetBeans wiki does not say anything about that... Besides, JDK 1.5 will complete the End of Life process very soon and 1.6 has been around for quite a while.
So why do they still use version 1.5 even if 1.6 is available on all Netbeans-supported platforms?
The NetBeans team requires JDK 1.5 to ensure that the resulting jars will run on a 1.5 JVM.
You don't need to build it with JDK 1.5 if it's just for your own use. But if you're planning on developing modules, you'll need to use 1.5 to ensure everyone else can use your modules.
If you compile with 1.6, you can use the -target 1.5 to generate classes that will load into a 1.5 JVM. The downside is it will not prevent you from using classes or methods introduced in 1.6 (eg: StringBuilder). It will load in a 1.5 JVM, but will fail with the likes of ClassNotFoundException, NoSuchMethodErrot, or NoSuchFieldError.
I've only used Netbeans a few times, but I know you can download Netbeans 6.7 with the latest version of the Java SE 6 SDK (6u14).
Unless you meant with the Java EE 5 SDK. J2EE 5 is just a specification, implemented by Sun's GlassFish stack, Jetty, Apache Geronimo (and partly by Apache Tomcat), etc...
Sun's Java EE 5 SDK is just the Java SE 6 SDK with the GlassFish application server and other optional downloads that implement other parts of the specification.
Do anyone know when Eclipse plans to move its codebase to > 1.5 (i.e. using generic & annotation)?
Even the latest plan for the upcoming eclipse 3.6 Helios still mentions:
Most of the Eclipse SDK is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself.
Portions are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.1, J2SE 1.4, Java 5, etc).
In general, the 3.6 release of the Eclipse Project is developed on a mix of Java 1.4, Java 5 and Java 6 VMs.
As such, the Eclipse SDK as a whole is targeted at all modern, desktop Java VMs.
Most functionality is available for 1.4 level development everywhere, and extended development capabilities are made available on the VMs that support them.
So as long as they want to support platforms with an old JDK, the incentive to rewrite a large portion of the codebase in recent JDK is low.
Note: e4 (Eclipse 4.0) will be based on Java 5.
In general, the 1.0 release of the e4 Project is developed on Java SE 5.
Some of Eclipse codebase (the Java EE part) is already using 1.5 level. As for the rest of it, I don't think they have any plans - I doubt if it is worth the effort.
More here -> http://www.eclipse.org/downloads/moreinfo/jre.php