Develop Reference

Which versions of JDK are compatible with Vaadin 8?

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.

When Java 6 will be dropped will my application continue to work?

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.

What is the status of JMX 2.0?

It was supposed to be released with Java 7, but the status is Dormant. On the other hand, the same page says
Use generics in the JMX API, for example have MBeanServer.queryNames return Set<ObjectName> rather than just Set.
and this did happen in Java 6. So, did some of the changes get in? Are there significant differences between Java 6 and Java 7 JMX implementations? Looking at Javadocs, I didn't notice any, but this only covers the API.

I asked this question also to the current product manager for JMX at Oracle, Tuva Palm some times ago (September 2011), and she promised me, that JMX 2.0 is not dead and there will be a technical roadmap in Q1/2012.
However, nothing have happened until now and even worse, JSR-255, the JMX 2.0 spec (but also JSR-262, ther WebService connector stuff) has been marked as withdrawn since 2016 with the following reason:
JSR 255 specified changes to javax.management.* which were subsequently abandoned due to lack of resources, and were not included in the Java SE 6 or 7 Platforms. (The changes were distinct from other changes to javax.management.* specified by JSRs 3, 160, and 336 for inclusion in the Java SE 6 and 7 Platforms.) It was determined in 2014 that future changes to JMX technology would be specified directly by the umbrella JSR for the Java SE Platform.
So JMX 2.0 in its original form is factually dead.

Apparently, it was postponed to JDK 8, and all already made changes reverted, so JDK 7 final implementation should be the same as JDK 6.

Install Java EE 6 on OS X Lion

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.

Are there features or functionality in JavaFX which will benefit by the language/VM improvements of later Java versions?

I wonder whether JavaFX will keep using the "main" JVM shipped by JavaSE and therefore receiving all improvements to the VM or if they will use their own spin-off of the Hotspot VM specially optimized for them.
Will it be possible to target JavaFX with every version of the Java language or are there limitations or backward compatibility problems?
Are there features planned for later versions of the Java language from which JavaFX could benefit?

One of the features planned for Java FX is "Tighter Integration with Java SE". Also, from the JavaFX FAQ, questions 5 it is clear that JavaFX will still be using Java SE as its JVM, as it says
starting with JavaFX 2.0.2 and Java SE 7 Update 2 (December 2011),
Oracle has started rolling out a solution through which the
installation of the JavaFX Runtime when the Java SE 7 Oracle JRE is
installed. Additionally, the JavaFX SDK is now part of the Java SE SDK
(JDK). When Java SE 8 reaches General Availability (GA), the JavaFX
Runtime will become part of the Oracle JRE
Java FX 1.1, 1.2 and 2 have not been completely backwards compatible. And integrating JavaFX with JavaSE might mean loosing some compatibility between versions of Java SE and versions of JavaFX. Somewhat soon to tell.
The JavaFx Roadmap and future releases announced don't show any sort of advantages for JavaFX among the new Java SE features. Given the touted integration I would not discount this, though.
Now, all of this is based in Oracle plans at the moment. Who's to say what might change from here to the arrival of JavaFX 3?