I got interested in looking at JSF 2.0 as a potential technology to use. Does anybody know when this version is scheduled to come out and how active is the project in general?
Does anybody know when this version is scheduled to come out
JSF 2.0 is part of Java EE 6 (i.e. any Java EE 6 container supports it) and has been elaborated under JSR-314 (which is final since 01 Jul, 2009) but, as mentioned on the JCP web page:
Sun will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK). The RI will be made available standalone and as part of the Java EE 6 platform.
The RI is Mojarra and is already available. As written in Mojarra 2.0.0 is available! (Oct 19, 2009):
There are several ways to obtain the
release.
GlassFish V3 promoted build 69 (out later this week)
Download directly from http://javaserverfaces.java.net
Download using Maven2 using information provided here
You actually don't need a full Java EE 6 server. For example, check out the post JSF 2.0 and Tomcat or Integrating JSF 2.0 and Weld with Tomcat6. But I'd simply go for GlassFish v3 (or JBoss 5.2+ which also supports JSF 2.0 + CDI).
how active is the project in general?
What project? The RI? What do you mean exactly? Well, Mojarra is used in GlassFish so I consider it as a serious project, with dedicated man power. However, I don't expect extreme activity now that the spec is final, only maintenance and bugfix releases.
JSF 2.0 was already final several months ago (19 october 2009) and it's indeed included in the Java EE 6 which was made final about one month ago (10 december 2009).
Although it's been released along with Servlet 3.0 API in Java EE 6, JSF 2.0 is backwards compatible with Servlet 2.5. So you can either download it separately and run on any Servlet 2.5 capable webcontainer like Tomcat 6.0, or just download a full fledged Java EE 6 implementation including it like Glassfish v3.
JSF 2.0 is included in Java EE 6, and Glassfish v3 currently supports it. It'll also run in WebSphere 7, with some effort.
Related
I have developed a HTTP servlet that implements MessageListener and connects to a JMS-based MQ system using javax.jms.ConnectionFactoy.
The connection factory is injected to the servlet via a Resource annotation.
#Resource(name = "jms/ConnectionFactory")
private ConnectionFactory connectionFactory;
The resource is defined in the context.xml configuration file.
What I have experienced is that when I compile the servlet using Java 11, the javax.annotation.Ressource is simply ignored, while I can still lookup the resource based on its name in the context directly.
But, when I compile it using Java 8, the resource is injected to the annotated field in the servlet.
Can someone explain this?
Another point is that the javax namespace is replaced by the jakarate one, when migrating from Java EE to Jakarta EE. Most of the JMS library are still implemented using the javax.jms.* interfaces, like ConnectionFactory, Queue, etc.
Does anyone has experience how compatibility looks like or is a reimplementation of JMS libs necessary?
tl;dr
For Java 11 deployment, use Tomcat 10.1.x, Jakarta EE package naming, Servlet 6 API, and Jakarta Messaging 3.1 API.
Earlier versions may run on Java 11 too, but these versions are built specifically for Java 11 as a minimum requirement.
This combination will likely work on Java 17 as well as Java 11. Java 17 is the latest Long-Term Support (LTS) version. While support is not officially required in Jakarta EE, the various teams seem to be aiming for their latest versions to run well on Java 17.
Use Tomcat Version 10.1 for Java 11
According to Apache Tomcat Versions, Version 10.1 of Tomcat supports Java 11 while versions 9 and 10.0 are aimed at Java 8.
Package name
You will need to change your import statements from javax.*package to jakarta.*. This change in package naming is due to the transition from Oracle to the Eclipse Foundation as the stewards of Jakarta EE technology (formerly Java EE).
Servlet API
Switch to the appropriate version of the Servlet API, version 6. See Servlet specifications page.
Messaging API
Note that JMS has become Jakarta Messaging. You’ll need to adjust your import statements and version number accordingly. See specifications page.
Likewise, update your Jakarta Messaging implementation.
I would like to know if there is currently any compatibility problem between version 7/8 of VAADIN and tomcat 10
tl;dr
Tomcat 9 and 10 are essentially the same.
Only difference is javax.* package naming versus jakarta.*, respectively.
Currently for Vaadin, use Tomcat 9, not 10.
Ditto for competitors to Tomcat. Example: Use Jetty 10, not 11.
jakarta.*
Yes, there is one simple but big problem.
Vaadin is still coded to the javax.* package naming of the Java EE technologies on which it is built. This includes Servlet technology.
With Oracle transferring responsibility for Java EE technologies to the Eclipse Foundation, the naming of those technologies has changed from Java EE to Jakarta EE (Java™ being a trademark of Oracle). As part of that transition, the package names of the interfaces and classes defined in Jakarta EE technologies are changing from javax.* to jakarta.*.
This new package name is a breaking change for all the decades of software written for Java EE. While an unfortunate problem, the fix is utterly simple: Rename the package line at the top of all the source files.
The Jakarta EE project has done just that in version 9 of Jakarta EE. Most of the relevant technologies have had their individual version numbers incremented, but are otherwise substantially the same as their previous versions (renaming their package is the only significant change). See the 2020 newsletter from Eclipse Foundation, Understanding Jakarta EE 9 .
The Tomcat project now runs two parallel versions: 9 and 10.
Tomcat 9 uses the old package naming: javax.*
Tomcat 10 uses the new package naming: jakarta.*
Both are simultaneously being developed; 10 is not “better” than 9.
If starting a greenfield project, and you are using only libraries that have made the package name change, you may choose to use Tomcat 10.
If using libraries that have not yet made the package name change, use Tomcat 9. Vaadin is one such library still using the old package name.
➥ So, for now, your Vaadin projects should be run with version 9 of Tomcat rather than 10. No loss here, as Tomcat 9 and 10 are essentially the same.
There is no urgent need to make the javax.*-to-jakarta.* transition yet. Eventually, I expect we will see releases of Vaadin transition to the new package naming. There is talk of tooling to help with this change, both in the Vaadin camp as well as the wider Jakarta EE world, though I am not aware of their current status.
Of course, the other alternatives/competitors to Tomcat are going through the same transition pains. For example, Eclipse Jetty 11 uses the new package naming while Jetty 10 is in parallel development with an identical feature set, as explained in this post by WebTide. If using Jetty for your Vaadin development or deployment, you would be using Jetty 10 rather than 11.
Servlet 3.1
All versions of Vaadin today (2021-05) are built against the Servlet 3.1 specification, rather than Servlet 4 or Servlet 5. See the documentation page, Apache Tomcat Versions for a table of which Tomcat supports which Servlet spec.
So no need even for Tomcat 9 in that regard. Tomcat 8.5 supports Servlet 3.1, so it will suffice for current Vaadin apps. FYI, Tomcat 8.5 was originally forked from early Tomcat 9, and contains mostly the same features.
I have a Java application which shows Apache Tomcat Embed as 9.0.35 version. I need to update this to 10.0.4. I'm very new to Java and have very minimal knowledge on it. This upgrade is needed to resolve some vulnerabilities with in the application.
How can I do this from IntelliJ IDE?
Tomcat 9 & 10 are equivalent products
Apache Tomcat 9 and 10 are equivalent products. The only difference is support for changes for the package names in the Jakarta Servlet and related technologies from javax.* to jakarta.*.
This package name change is for legal reasons involved in the transfer of responsibility for Jakarta EE (formerly Java EE) technologies from Oracle Corp to the Eclipse Foundation.
For more info, read Understanding Jakarta EE 9.
To quote the documentation:
Users of Tomcat 10 onwards should be aware that, as a result of the move from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later. A migration tool is under development to aid this process.
Move to the latest 9 rather than 10
Tomcat 9 and 10 track the same development changes. If your goal is simply to gain some security fixes, as far as I know you'll get the same fixes in both 9 and 10. Do not take my word for this, just study the Tomcat Release Notes.
So for the fastest easiest migration path, just upgrade to the latest 9 instead of 10. The current latest version of 9 is 9.0.44.
Stick with Tomcat 10
Alternatively, if you want to proceed with using Tomcat 10, change the import statements across your code base to use jakarta.* in place of javax.*.
IDEs such as IntelliJ have added features to assist in this migration chore.
And you’ll need to update any third-party libraries using javax.* to new versions using jakarta.*.
This question already has answers here:
Servlet 5.0 JAR throws compile error on javax.servlet.* but Servlet 4.0 JAR does not
(3 answers)
Closed 1 year ago.
I am just trying to learn some JSP but I am getting that error repeatedly. I've tried everything on the internet and nothing happened. I am using the Tomcat v10 and JDK15.0.2. This error occurs when I create a new JSP file.
Java EE ⇝ Jakarta EE
Read the front page of downloading documentation for Apache Tomcat 10. To quote:
Users of Tomcat 10 onwards should be aware that, as a result of the move from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later.
And read the first page of the main documentation for Apache Tomcat 10. To quote:
Apache Tomcat version 10.0 implements the Servlet 5.0 and JavaServer Pages 3.0 specifications from Jakarta EE …
As part of Oracle turning over responsibility for what was known as Java EE (Enterprise Edition) to the Eclipse Foundation, the package names in Jakarta EE are changing from javax.* to jakarta.*. You can read about this on the Tomcat page, Which version? — Apache Tomcat Versions, and on the internet.
Tomcat 10 is for people moving forward to Jakarta EE versions 9 and later, using the jakarta.* namespace with the latest Servlet & JSP specs.
Tomcat 9 is for people sticking with the javax.* namespace using the popular Servlet 4 spec and related APIs.
If you want to use the latest APIs, change your import statements to use jakarta. rather than javax.. Or switch out your Tomcat 10 for Tomcat 9 to use the older javax. namespace.
If you are learning and experimenting, I suggest using the jakarta. namespace along with Tomcat 10.
If you are using important libraries or tools that are not yet updated to the jakarta. namespace, stick with the older APIs and Tomcat 9.
There has been talk of tools to help by automating some of this namespace switch. But I do not know of the state of affairs there.
You need an update from https://download.eclipse.org/releases/2021-03/ . Support for Apache Tomcat 10 and Jakarta EE JSPs is extremely new.
I suppose you could also just use Tomcat 9.
I want to move from Java SE to Java EE. I will be using some of the sample projects that come with the Java EE. I have uninstalled the JDK but I think this may have been a mistake?
When I download the latest Java EE (6), upon installation it asks me for the location of the JDK (which is uninstalled). I was under the impression that the JDK was specific to each version of Java i.e. SE or EE. Am I wrong here? I would have thought that when I download Java EE 6 that it was actually the EE JDK?
Can anybody please clarify this for me?
Java EE is simply a set of APIs on top of Java SE. You'll need to re-install your Java SE JDK.
The JavaEE downloads from Sun's site are just the reference implementations. They build on top of the existing JDK. If you want to use the reference implementation, then go ahead... however, there are lots of other implementations instead.
If you're only doing web applications, you can get away with just a Servlet container.
Reference:
GlassFish v3 - Full JavaEE 6
GlassFish v3 Web Profile - Servlet-only JavaEE 6
Servlet-only:
Apache Tomcat - JavaEE 5
Jetty - JavaEE 5
Open Source Full:
Apache Geronimo - JavaEE 5
JBoss - JavaEE 5, partial 6
Commercial implementations:
IBM Websphere - JavaEE 5
Oracle Weblogic - JavaEE 5
No, Java EE builds on top of Java SE. To get started developing Java web applications, you can download Apache Tomcat.