I see that Apache Tomcat 10 (alpha) is now available. The major feature there is support for Jakarta EE 9 where package names for APIs have changed from javax.* to jakarta.*. Jakarta EE 9 now has a milestone release available.
Can the current versions of Vaadin Flow (14 or 16) be made to work with the new Jakarta 9 and its name changes?
Vaadin does currently not support Jakarta EE 9 because of the package name changes. We're watching to see how the situation develops to e.g. see whether application servers would include helpers to automatically also support parts that use the old package names.
In the mean time, you can try applying those changes manually using e.g. https://github.com/apache/tomcat-jakartaee-migration or https://github.com/eclipse/transformer/.
Related
I am using OpenJDK 11 for Vaadin 8.
Have anyone used a later version of OpenJDK for Vaadin 8 successfully?
If yes, which version of OpenJDK?
I want to know if I can upgrade OpenJDK to a later version for Vaadin 8.
tl;dr
Yes, I would try deployment of a Vaadin 8 app to either Java 11 or Java 17 as both are LTS. Java 17 should generally prove to be as compatible as Java 11.
But test thoroughly.
Probably, Yes, deploy to Java 17/18
The Release Notes for the current version of Vaadin 8 states:
The server-side Vaadin Framework 8 is compatible with Java 8 and 11. Note, that the client-side Java code, compiled using GWT to be run as JS on the browser side, only supports language features up to Java 9 and a subset of JDK libraries. Vaadin Framework 8 is developed and tested with Oracle JDK, but other compliant Java distributions should work as well. More about Java support in FAQ.
…
Vaadin Framework 8 requires Java Servlet API 3.0 but also supports later versions
So, Java 11 is officially supported for Vaadin 8.
If you can deploy Vaadin 8 on Java 11 (LTS), then I would expect you could also deploy to Java 17 (LTS) and Java 18 (current).
The only major breaking change in modern Java that comes to my mind is the Java Platform Module System that arrived with Java 9. But if Vaadin 8 officially supports Java 11, then the JPMS must not be a blocking problem.
One other breaking change is that the parts of Java SE that were related to Java EE were removed in Java 11. Some of those parts have replacements to be found in libraries that you can add to your app. Some parts have been abandoned due to a lack of interest. See JEP 320: Remove the Java EE and CORBA Modules.
The changes after Java 11 have not involved any major breaking issues that I can recall. Most any Java apps that run on Java 11 can run on Java 17/18.
Of course you should:
Consider compatibility of any libraries used by your app.
Test thoroughly.
Consider migrating to Vaadin Flow
While not an urgent matter, I would suggest you make plans to transition your app from Vaadin 8 to the latest version. Vaadin Ltd makes the same recommendation.
Free-of-cost support for Vaadin 8 is ending. See the company blog post. Paid support for Vaadin 8 from Vaadin Ltd will continue to be available, but the company nevertheless recommends migrating to current Vaadin Flow (v23 now) if practical.
Simpler apps may be easy enough to rewrite from scratch in Vaadin Flow, provided you have learned the new features such as routes, data-binding, and differently-designed widgets & layout managers. The basic concepts are the same between Vaadin 8 and Vaadin Flow, but many details have changed.
For assistance, Vaadin Ltd encourages use of their Discord server and Stack Overflow. (Their own support forums have been closed, now read-only.)
In addition, Vaadin Ltd sells products and services to assist in your migration from Vaadin 8 to Vaadin Flow.
Paying customers have access to technology to directly run your old Vaadin 8 app unchanged within a new Vaadin Flow app. See Multiplatform Runtime product page.
To help ease that learning curve of new components & layout managers, the company sells access to the Classic Components pack. This recently released set of widgets is built in Vaadin Flow but are meant to work in the same manner as their Vaadin 8 counterparts. Using these retro components makes rewriting your app from scratch much easier, as you may be able to do a lot of copy-pasting without as many changes to your layouts.
Vaadin Ltd. sells consulting services to assist in the transition. An initial consult is free-of-cost (see blog post linked above).
While code migrations are never fun nor easy, there is one bright thought to consider: This is likely to be the last major architectural change to Vaadin for many years. Versions 6, 7, and 8 all involved major changes. But now that HTML5, CSS3, modern JavaScript/Typescript, and standardized Web Components, are all technologies that have matured into a rich stable platform for modern web apps, and now that Internet Explorer is finally dead, I expect Vaadin Flow to be evolving more gradually with incremental improvements rather than the past earth-shaking shifts.
Jakarta package naming
Another issue is the transfer of Java EE technologies from Oracle Corp to the Eclipse Foundation. As part of that transition, the package naming has changed from javax.* to jakarta.*. This is a breaking change.
So some of the Servlet container products such as Apache Tomcat and Eclipse Jetty are maintaining two versions of products, developed in tandem. These dual versions sport the same features and same performance, but different package naming.
Vaadin has not yet been modified to support the new package naming. So be sure to choose a Servlet container version aimed at the old package naming.
I would guess that only Vaadin Flow will make the package naming change, not Vaadin 6, 7, and 8. This may eventually become yet another reason to consider migrating from Vaadin 8 to Vaadin Flow.
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.*.
The way to implement WebSockets in Tomcat changed between version 7 and version 8.
Tomcat 7:
public class ChatWebSocketServlet extends WebSocketServlet { ... }
Tomcat 8:
#ServerEndpoint(value = "/chat")
public class ChatAnnotation { ... }
What I want to know is if it's possible to build both versions into a single application. I already tried
#ServerEndpoint(value = "/chat")
public class ChatServlet extends WebSocketServlet { ... }
but it never compiles against both websocket-api.jar and catalina.jar. I guess it's possible to check if a class is defined and use one or the other at runtime, but I'm not sure how to implement that exactly, or even whether it's a good idea.
I could package the websocket-api.jar into the final product, but would that cause problems deploying it to Tomcat 7?
From Tomcat 7 and Tomcat 8 documentation
Application development
Tomcat implements the Java WebSocket 1.1 API defined by JSR-356.
From Tomcat 7 documentation:
Deprecated proprietary API
Prior to the development of JRS-356, Tomcat provided a proprietary WebSocket API. This API has been deprecated in Tomcat 7 and will be
removed in Tomcat 8. There is unlikely to be any further development
of this proprietary API apart from bug fixes.
For information on this API, please see the Javadoc for the org.apache.catalina.websocket package. The Javadoc pages are not
included with Tomcat binary distributions. To view them locally you
would have to download and install "Full documentation" distribution,
or build it from sources. You can also read this on the Apache Tomcat
web site. Start with the WebSocketServlet class.
I doubt that you can use both implementations at the same time, but according to the documentation you shouldn't have a problem with JSR-356 specific implementations running on both versions. Just stay away from the proprietary implementation.
As the first version of Tomcat 7 was released in 2010/2011, but JSR-356 was first released in 2013, there are ancient versions that don't have the standard websocket implementation, and I'll leave to you to find out in which version the JSR-356 implementation was included first. However, due to bugfixes, including security relevant ones, you should have an easy time to only support the latest version of Tomcat 7. Don't worry about those that didn't update their server software for several years.
I am having a problem with Netbeans and when I tried to create a Java Web by following their instructions:
Choose File | New Project.
Under Categories, select Java Web.
Under Projects, select Web Application.
Click Next. Web Server-- Apache Tomcat 7.0.42
but Java EE version-is only EE6 and EE5. Why does it not Show EE7??
should i need to install any plugin?
I have the follwong installed:
JDK 1.7_upadte_42
Netbeans 7.3.1
Apache Tomcat 7.0.42
Tomcat is not a Java EE compliant application server to begin with, it is a servlet container1. It is clearly stated in the official site:
Apache Tomcat™ is an open source software implementation of the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies.
In order to use Java EE 7+ capabilities, you need to use a Java EE 7+ compliant server. Currently, AFAIK this is done by GlassFish 4 only. When you visit the official site, it is stated in the top: World's first Java EE 7 Application Server. Make sure you configure your project to use GlassFish 4 and then you may use Java EE 7 benefits for your applications.
Note that this is also covered in Netbeans 7.3.1 community news:
NetBeans IDE 7.3.1 is an update to NetBeans IDE 7.3 and includes the following highlights (emphasys mine):
Support for Java EE 7 development
Deployment to GlassFish 4 (not Tomcat)
Support for major Java EE 7 specifications: JSF 2.2, JPA 2.1, JAX-RS 2.0, WebSocket 1.0 and more
1 At least not until Tomcat 7. Looks like from Tomcat 8 it will support Java EE 7 profile (from the official site linked above):
The Apache Tomcat Project is proud to announce the next release candidate for Apache Tomcat 8 - 8.0.0-RC5 (alpha). Tomcat 8 is aligned with Java EE 7.
Short Answer: You need to use Tomcat 8+ for Java EE 7 web projects. Additionally (as mentioned), you may need to use a later version of NetBeans (7.4+) for full support.
Long Answer:
I'm a little late answering here, but I'm posting an answer for the record in case others see this question and to clear up misconceptions. Contrary to the prevailing belief, you can deploy Java EE apps to Tomcat.
There are two Java EE profiles relevant here: the "Full" profile (which includes the full Java EE stack) and the "Web" profile (a subset of the full profile which is designed to be implemented more easily by servlet containers). As mentioned, if you must use functionality only available in the full Java EE 7 profile you will need to deploy to an app server such as Glassfish 4+, [Jboss] Wildfly 8.1+, or JEUS 8.
However, Tomcat does comply with the Java EE Web profile, so you can deploy Java EE apps to it so long as you stick to just the functionality provided by the Web profile.* Often (if not usually) the web profile is all you need. The web project mentioned by the asker only uses stuff from the web profile. Tomcat 7 complies with the Java EE 6 Web profile and Tomcat 8 complies with the Java EE 7 Web profile, so the OP just needs to upgrade to Tomcat 8 if he wants to use EE 7.
* Oracle makes it easy to stick to one profile or another by distributing specific API jars for each profile ("javaee-api" for the full profile, "javaee-web-api" for the web profile, etc). That's the only dependency you need** to create Java EE apps, and you don't even have to (and shouldn't) bundle it in your WAR. In reality you may need to bundle (but not compile against) some libraries a la carte--or use the TomEE variant of Tomcat--to use all EE 7 web features.
** If you see gobbledygook about "endorsed dirs" and "endorsed APIs" in your build files, that's not a real dependency and is just to ensure that your code compiles against the correct class versions. For example, the standard (non-EE) Java 7 runtime already includes a version of JPA, but Java EE 7 includes a different version so the compiler needs to know which version to use. Don't take out that gobbledygook or you could (but probably won't) have runtime "class version incorrect" issues.
At the moment, Java EE 7 is only partially supported by Netbeans 7.3.1. They will support it in NB 8.0. Also, you need Tomcat 8 for Java EE 7, but their support is still partial too. Glassfish 4.0 is the way for now.
Here are some useful docs:
http://wiki.netbeans.org/JavaEE7
http://tomcat.apache.org/whichversion.html
http://docs.oracle.com/javaee/7/tutorial/doc/
I have Java 6 SE, Tomcat 6, Eclipse Helios for J2EE, Chrome Browser Dev for JS up and working. Sometimes I need the source and doc for java libraries I believe are in the EE kit. What is the best way to get the source and doc and be able to use it in my dev environment without messing it up?
Is this as simple as running the Java 6 EE install package on Vista 64bit?
If I have the download, is there a way to extract the files and manually place them?
This question is confusing. You mention Java EE 6 in the title and then Tomcat 6 in the body but Tomcat 6 doesn't implement any of the standards from Java EE 6. Sure, you can run some parts of the Java EE 6 specification on it like JSF 2.0, CDI, JPA 2.0. But still, Tomcat 6 only implements Servlet 2.5 and JSP 2.1 and has thus little to do with Java EE 6 (and Tomcat 7 also only implements Servlet 3.0, not the Java EE 6 Web profile, and they don't plan to implement it).
I'm not suggesting to move away from Tomcat if it suits your needs, I'm just clarifying that neither Tomcat 7 nor Tomcat 6 do provide a Java EE 6 (Web Profile) implementation.
If Tomcat 6 appears to be what you're looking for, you can download a "Source Code" distribution from their website (go to the bottom of the page) and attach the sources in Eclipse, as suggested by BalusC.
If you really want to "move to Java EE 6", you'll need a Java EE 6 server (either supporting the full Java EE 6 specification or only the Web Profile) like GlassFish 3.0.1, GlassFish 3.0.1 Web Profile, JBoss 6.0, Resin 4.0 (Web Profile implementation). They all provide sources of their implementation. If you go this way, let me know and I'll add more details if necessary.
The Java EE is an abstract API. The application server is the concrete implementation. The Java EE 6 kit provided by Sun Oracle contains basically the Glassfish server. But you already have Tomcat as server. Just get its source from http://tomcat.apache.org. You need to ensure that the source version matches the Tomcat version. If you're using an older version than currently latest 6.0.29, then you need to get it from the archive. It's in the /src folder of the version folder. You can download it as zip, put it somewhere on your disk (I myself put it directly in Tomcat installation folder). Finally have Eclipse point to the zip file whenever you want to view the source for the first time (e.g. HttpServlet and so on).
Noted should be that Tomcat 6 only implements Servlet 2.5 / JSP 2.1 which are part of Java EE 5, not 6. But it may be more than sufficient for your needs. For the remnant of the detail see #Pascal's answer.