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.
Related
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.*.
I'm confused about the status of Java Web Start.
On Oracle's Support Roadmap we can read this:
Support of Deployment Technology
The web deployment technology, consisting of the Java Plugin and Web Start technologies, has a shorter support lifecycle. For major releases through Java SE 8, Oracle provides five (5) years of Premier Support for these technologies. Extended Support is not available for the deployment stack, and will not be available for support beyond Java SE 9. See the Oracle Lifetime Support Policy for details.
Deployment Technology for Java SE 6 and Java SE 7 may be removed at any time after Jun 2017. Although the deployment stack may be included in Java SE 9 or later releases, Java SE 8 is the recommended and only supported version of the deployment stack.
Now, we have known for quite some time that applets and the Java Plugin were to be removed in a future version of Java, but I had never read about Java Web Start being a candidate for removal.
In Oracle's Java Platform, Standard Edition Deployment Guide#Getting Started (a Java 9 documentation page), Java Web Start is advertised as an alternative to the deprecated applet technology:
Although available and supported in JDK 9, the Applet API and the Java Plug-in are marked as deprecated in preparation for removal in a future release. Alternatives for applets and embedded JavaFX applications include Java Web Start and self-contained applications.
Am I worrying for nothing or I have missed an announcement about the deprecation of Java Web Start?
According to http://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html
Java Deployment Technologies are deprecated and will be removed in a future release
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.
There is a related discussion on the OpenJDK discuss list here: http://mail.openjdk.java.net/pipermail/discuss/2017-November/004586.html
Oracle will not include Java Web Start in Java SE 11 (18.9 LTS) and later.
Source: Java Client Roadmap Update 2018-03-05 (Oracle)
This applies to Premier, Extended and Sustaining Support. Just from the quoted text:
only Premier Support covers the Deployment Technology;
the Deployment Technology could be removed in future Java SE 6 and 7 releases;
as the applet API and plug-in are deprecated, the Deployment Technology could be removed in a future major release;
Java 9 Premier Support only lasts until March 2018.
Consequently, Java 8 is the only release that will include the full Deployment Technology with mid-term Premier Support (March 2022).
Note that it does not mean Java Web Start will disappear but removing the Applet API and the plug-in means breaking apart the Deployment Technology.
One solution might be the WebStart replacement that Karakun is currently working on: https://openwebstart.com
Currently it is not clear when and how this will come since it is based on a kind of crowd-founding but since everyone can get involved (even with low cost) this is a very good possibility.
Since this is a duplicate of Applet/JNLP on Java 11 migration I just copied my answer
I saw this on an Oracle Blog entry
Tuesday, January 30, 2018
Extension of Oracle Java SE 8 Public Updates and Java Web Start
support By: Donald Smith | Sr. Director of Product Management
Oracle has updated the Java SE Support Roadmap. A more detailed white
paper will follow shortly, but here are the key changes made:
The public availability of Java SE 8 updates from Oracle has been extended to at least January 2019. Moreover, Oracle will continue to
provide consumers with updates for personal (non-corporate) use of
Java SE 8 through at least the end of 2020.
Oracle will continue to support Java SE 8 Web Start applications for public and personal (non-corporate) use to the same dates noted
above.
Oracle will continue to commercially support Java Web Start on Java SE 8 for commercial use, or when used in conjunction with Oracle
products that have a Web Start dependency, through at least March,
2025.
As announced in 2015, Applets will continue to be supported in Java SE 8 until at least March, 2019, pending continued support by browser
vendors.
I started using IcedTea Web. It seams to work fine on Ubuntu.
I am a bit worried about something and no matter how much i searched i could not find something or i could not search properly.
I have an application that runs on java 6 SE. Oracle mentions in the website that they will drop the Java 6 SE Deployment in June 2017. So that leaves me with a question. Will my application still run after the Java 6 end or will it crash?
Deployment Technology for Java SE 6 will be available until Jun 2017
Mentioned here
Will my application still run after the Java 6 end or will it crash?
It will continue to run.
If a user downloads and installs a Java 6 JRE / JDK, your application will run as before.
If a user has Java 7, Java 8, Java 9 .... etcetera, your application will run on those platforms provided that it is properly written. Things that might cause it to break include:
dependencies on restricted "internal" classes that have been changed or removed in a later release,
incorrectly written multi-threaded code that breaks due to platform differences,
a tiny number of documented incompatibilities, and
dependencies on 3rd-party libraries that have not been ported.
However ....
You ought to take the time to port your application to run on the latest version of Java. This is probably just a matter of compiling the codebase on the newer / newest Java JDK, and then running all of your unit and system tests. (But if you have extensive dependencies on old libraries that are no longer being maintained, then you may have a problem ...)
If you don't do this, your application is liable to become problematic for users who won't or cannot install an out-of-date (and probably insecure!) version of Java on their systems.
This is even more important for applications that depend on web deployment and Java plugins for browsers.
Yes. No. Maybe.
If you continue to use old JVM nothing will changes. Except you won't get bugfixes and security patches.
If you migrate to new JVM then in theory all should be fine (Java declare backward compatibility), but sometimes problems may occur. That's why you need to test you application with new JVM before you go into production.
As mentioned by some of the others, yes your application will still work. It just means they will be done supporting it.
Oracle’s poor wording is ambiguous
To answer the specific part of your question, let's look at the text of the Oracle page, Oracle Java SE Support Roadmap (retrieved 2016-10).
Support of Deployment Technology
The web deployment technology, consisting of the Java Plugin and Web Start technologies, has a shorter support lifecycle. For all major releases of Java SE starting with Java SE 7, Oracle provides five (5) years of Premier Support for these technologies. Extended Support is not available for the deployment stack. See the Oracle Lifetime Support Policy for details.
Deployment Technology for Java SE 6 will be available until Jun 2017.
This says that for (a) the Java Plugin for Java applet and for (b) Java Web Start specifically you cannot purchase additional technical support from Oracle beyond 2017-06. Other Oracle extended support contracts running beyond that date do not include technical support for the Java SE 6 version of this pair of deployment technologies.
That last sentence is poorly worded. I believe we can assume it should have begun with “Technical support for”. I understand the cause for your Question here.
As others have said, Oracle has never time-bombed any Java technology product nor have they ever announced any plans for doing so.
Oracle support for the plugin and for applets is practically moot as various operating systems and web browsers in recent years have been limiting or ending their support for Java applets due to security vulnerabilities. Java Web Start remains a viable platform for distributing local Java apps, though I recommend such apps move to later versions of Java.
The Java Preferences application on my OS X Lion workstation indicates that I have Java SE 6 v1.6.0_29-b11-402 installed (both 32- and 64-bit versions). Unfortunately, I need additional features at are only available in the Enterprise Edition.
A comment by 'Jesper' in 'How install a specific jdk on Mac OS X?' suggests that I need to use the Java supplied by Apple, rather than the one from Oracle/Sun. Unfortunately, it doesn't seem that Apple offers an Enterprise Edition of Java 6.
This leads me to ask a number of questions:
Did I miss something? Does Apple offer an EE of Java 6?
If 1 is true, how do I get it? Can it be installed 'side by side' with the Java SE 6?
If 1 is false, can a Oracle/Sun version be used? Is there a recommended installation location? I'm guess that the /System/Library/Frameworks/JavaVM.framework/Versions/ folder is not recommended.
The Oracle/Sun version seems to include a lot of extras (e.g. Glassfish) that I would prefer not to install. Can I install the core SDK w/o the extras? Will Tomcat 7 work as an alternative to Glassfish?
** edit **
This question is a result of another question that I posted: RESTful web service: java.lang.NullPointerException service.AbstractFacade.findAll. It seems that this particular error is a result of a missing annotation (#Stateless). This annotation is 'contained' in the javax.ejb.* namespace, which is contained in a .JAR file that is not on my workstation.
This led me to conclude that I needed the 'Enterprise Edition' of Java 6 (which would have the missing .JAR file and other dependent files). I suppose if there was a way to determine which .JAR file is missing (Netbeans 7 doesn't seem to help with this) I probably could just add it to the project and skip the EE hassles.
There is no such thing as a special runtime called Enterprise Edition of Java for any platform.
There is Java SE and there are simply some interfaces that an Enterprise Edition container implements.
Sun confused the market with the naming convention years ago when they came up with J2EE. It never was a separate version of Java, just some tacked on APIs that if a server implemented them and passed some certification, could call themselves a J2EE container.
They further confused the market when they started calling it Java EE 6.
If you are developing against these APIs all you need is the .jar files that contain these interface declarations. You can download these API .jar files which used to be called J2EE. But they are pretty useless by themselves.
But I doubt that you are wanting to write a Java EE server, you want to use one. If you want to use a server then you need to download a Java EE compliant server and use the .jar files it provides.
Every IDE worth using includes these in some form, usually by defining a Server that you will be deploying against. Tomcat isn't a fully EE container. It is a Servlet container, which is a subset of the full EE specifications.
As of OSX Lion, Apple doesn't supply a JDK anymore, it is only the Oracle one, which you apparently already successfully acquired.
Java EE 6 is a spec, with some accompany API represented as interfaces. Java EE 6 in and of itself is not an implementation of those APIs. If you wish to use the Java EE 6 APIs you will need to avail your self of a compatible Java EE Application Server. Glassfish is the reference implementation of Java EE 6, however there are other servers as well that are compliant. JBoss is another popular option.
These install easily on Mac OS X.
There is a Java EE download. http://www.oracle.com/technetwork/java/javaee/downloads/index.html On its own though, its not particularly useful unless you're trying to develop an application that is intended to run in multiple containers.
What you will typically want to do is to download a container and develop with that. e.g. Glassfish (available at same link above). This task can be made easier with support from an IDE such as Netbeans. You can download a version of Netbeans that already includes Glassfish and the Java EE APIs and just start working. Other IDE/container combinations are possible, usually there is some sort of plugin available.
The Java 6 JDK/JRE for OSX is still from Apple. They transitioned most of the code to Oracle however, and the OSX version of JDK 7 is close to release status, and it may be mature enough for your purposes. My best guess is that it is.
I'm not sure how to phrase this question, but considering the differences in .NET listed below, is there any comparison to Java and all it's deployments?
Platform
The same version of .NET can run on either a server or workstatation
Since the full version of .NET may be too much for some deployments, there is a client profile only version
Silverlight and .NET are not binary-compatible.
There are additional versions of .NET that are meant for other platforms. They are not binary compatible, and may have different API's available: (.NET Micro, Mobile, CE, Embedded, Mono)
Changes between versions
The CLR is version "1.x" in .NET versions 1.0 and 1.1
The CLR is version "2.x" in .NET versions 2, 3.0, and 3.5
.NET 3.0 adds WF and WCF
.NET 3.5 is mostly a feature pack on top of the .NET 2.0 "base"
A .NET 2.0 application will run if only .NET 3.x is installed, but what may appear as a version mismatch doesn't apply to any other assembly/.NET build combination
Given all the different versions of Java SE EE and all the acronyms, I'm sure there may be more under the hood I need to learn besides the spelling difference between each implementation.
Can you tell me what I need to know regarding the various versions that exist and when is one more appropriate than the other.
http://www.oracle.com/technetwork/java/index.html
Until now if a program ran under any release of Java SE - Java 1.1, Java 1.2, Java 1.3, Java 1.4, Java 5, Java 6 - it runs under any later release too (except for unintentional bugs, but these has been very few).
Sun has given this extreme attention, and it has meant that upgrading has been a non-issue. You just do it. With the advances achieved in the JVM this has also been highly desirable.
Hence, unless you have very good reason not to, your users should use Java 6. The Sun Java 6 gives very good performance but at the cost of memory to do so.
I have only worked with the "web application" part of Java EE, but here the Servlet API has been very stable and well supported. A given WAR file can be deployed on any web container, plus some configuration glue. This includes web containers much newer than the specification the web application was written against.
I think all you need to know is that Java JDK 6 is the only one that's currently supported by Oracle. The other earlier versions have all passed their useful support life.
There's no good reason on earth for anybody to be running a JDK or JRE version 1.4 or earlier. It doesn't even have generics, and it's missing a number of important improvements to the memory model.
JDK 5 is defensible, but I believe it's already reached the end of its support life as well.