We Keep Coding

Is JavaFX part of the public API?

I am working with code that involves using the JavaFX platform and I encountered the following error from Eclipse while trying to import the Application class from the javafx.application package:
Access restriction: The type 'Application' is not API (restriction on
required library rt.jar)
I encountered the above error when trying to import classes from the javafx.application, javafx.scene, and javafx.stage packages.
Thanks to this answer, I know so far that the problem arises from access restrictions placed by Eclipse by default to prevent the accidental use of classes which it thinks are not part of the public API. Is this the case for JavaFX? Also, I'm also not sure I'm completely clear on what it means for a package or class to be in the public API.

Thank to responses from #Slaw and #Benjamin to #Florian's answer, I think I can now provide an answer to my question:
JavaFX 2.2 and later releases are fully integrated with the Java SE 7 Runtime Environment (JRE) and the Java Development Kit (JDK). However, JavaFX is no longer a part of the standard JDK, as of Java SE 11. This is probably why Eclipse is worried and requires explicit access rules for the library.
Also, the comments have helped to clarify that this does not mean that the stability and future reliability of JavaFX is completely uncertain. JavaFX, as of now, is stable and is being developed as OpenJFX which is part of the OpenJDK project (a free, open-source implementation of the Java SE). The latest release is JavaFX 13.
In summary, JavaFX has a "public" API such as the javafx.* packages and a "private" API such as the com.sun.javafx.* packages. However, the implication of the current state of JavaFX is that as a library, it will have to be pulled in like any other external dependency since it is not bundled with the standard JDK/JRE.

To make it short, JavaFX is not in the "public" Java API.
The Java API contains the most common tools a developer needs, for example collections, network, different parsers, etc...
Therefor JavaFX is not in the public Java API.
If you want to see which tools are included you can check out this link https://docs.oracle.com/javase/7/docs/api/ .

CA-sv will supported in Java 8?

CA service virtualization can be configured by Java 8
As I checked with CA sv document I had seen its supports only limited Java versions.
Kindly help me to get info.

As far as running DevTest Server and DevTest Workstation are concerned, the Windows installer automatically includes a compatible JDK. As of the latest GA release (10.1.0), that would be Java 8. Most recent releases have been Java 8.
On Unix, you must provide your own JVM, and there are different settings for Oracle and IBM JVMs.
https://docops.ca.com/devtest-solutions/10-1/en/installing/preinstallation/system-requirements#SystemRequirements-SupplyingYourOwnJVM
That link is specific to 10.1.0 which requires Java 8. If you have an older version, please check the version specific documentation.
Note that OpenJRE is not supported at any version.
The JDK that DevTest runs on is only important if you're writing custom extensions. You don't want to build an extension with a Java version newer than what the server uses.
Scripts within a VSM, however, are another matter. The deprecated JavaScript step, I believe, only understands JDK 1.4. I'm not certain about the JSR-223 step but, if you select Beanshell, you're probably still limited to 1.4.
You're also limited to JDK 1.4 in Beanshell expressions like:
{{=new java.util.Date();}}

Why are there differences between openJDK and oracleJDK

I have problems with the following method:
sun.security.x509.AuthorityKeyIdentifierExtension.getEncodedKeyIdentifier()
It exists in openJDK but it does not exist in oracleJDK. I always thought that except for some special cases regarding licensing those JDKs should be the same ...
While I can work around that issue, I fear there are other incompatibilities I might not be aware of.

Classes that are not part of the standard packages and classes that are deprecated can be not part of a jdk.
In your case you can try to solve the problem using the classes of the package javax.security.cert. Searching for it on google you can find some tutorials like this one.
Just to complete the answer is true that "generally" both compiled code comes from the same source code in the open jdk and in the oracle jdk. But oracle jdk and open jdk have different licences so there are also few little differences. Generally the differences are not related to the source of common classes, but to the presence or absence of classes or entire packages. As an example see the font library.
This is not the only difference. As you noted in your code also the security packages are different, because the open jdk added also the old sun version of x509 certificate classes and the oracle jdk not. There is no guarantee on what classes are included or not if they are not part of the standard packages. So if you have problems running your code on different jdk environments use only standard packages or explicitly import libraries as you need.

That class is not part of the public Java API and is therefore not guaranteed (or even likely) to exist in every JRE implementation, nor every release of the same provider's implementation.
If it's not part of the standard APIs, then you can't count on it.
Java Standard Edition 8 - all JDKs should provide these
Java Enterprise Edition 7 - some environments and libraries will provide these
While the OpenJDK and OracleJDK implementations happen to be very similar as they share a common history, they could diverge (or converge) in any private APIs or implementation details at any time, simply because they are separately-run projects.
Instead you should be using the appropriate implementation-agnostic APIs in java.security and javax.security for dealing with certificates.

Oracle JDK was previously called SUN JDK and that was before the takeover by Oracle. Earlier, it was the official proprietary implementation of the Java language. After the takeover it was named as Oracle JDK and Oracle’s team maintains the JDK.
OpenJDK is an open source implementation of the Java Standard Edition platform with contribution from Oracle and open Java community.
Actually, Oracle JDK’s build process builds from OpenJDK source code. So there is no major technical difference between Oracle JDK and OpenJDK.
Apart from the base code, Oracle JDK includes, Oracle’s implementation of Java Plugin and Java WebStart. Also includes third party closed source and open source components like graphics rasterizer and Rhino respectively.
How Oracle JDK and OpenJDK is kept in Sync:
All of the development and bug fixes happens in OpenJDK and then they are propagated to the Oracle JDK. Security fixes happens in private forest without public code reviews unlike general fixes, then they are pushed to Oracle JDK and then to OpenJDK.
more on http://javapapers.com/java/oracle-jdk-vs-openjdk-and-java-jdk-development-process/

Java is backward compatible, but why we need to upgrade many libraries when we upgrade jdk from 1.6 to 1.8?

Recently, we upgrade the Jdk version from 1.6 to 1.8 in one of my Java project. But there are some compilation or runtime errors, so I have to upgrade some libraries:
gradle: 1.9 to 1.10
spring: 3.x to 4.x
That because they are using some early versions of ASM, but which supports jdk 1.8 only from 5.x
Java said it is backward compatible, but why the original versions of libraries can't work with jdk 1.8 directly?

ASM is a pretty low-level library.
It processes Java byte-code directly (whereas a "normal" application would just let the JVM load its classes). The byte-code format changes from time to time, and newer versions cannot be used by an older JVM.
Messing with JDK or class format internals is not covered by backwards compatibility.
This is really an edge-case, and ASM is pretty much the only "popular" example.
More importantly (and more common) though are slight behavioural changes in system library code. So your application will technically still run, but do things differently. Most of the time, you want that, as it means improvement (for example better performance), but sometimes it can cause bugs for you.
For example:
switching to 64bit JVM can require more memory
changes in garbage collection can lead to unexpected pauses
inclusion of XML parsers into JDK proper requires changes to web application packaging or configuration
memory and runtime characterics of String#substring completely change in "minor" JDK revision
sorting a collection with a custom (incorrectly implemented) comparator suddenly throws exceptions it did not throw before
Calling Thread#stop(Throwable) (which was never a good idea and has been deprecated for a very long time) throws a UnsupportedOperationException since Java 8
Updated Unicode support changing sorting and casing behaviour for some strings
Changes in generics compilation
Inability to extend BitSet and implement Set due to new default methods
Changes in rounding behavior
And many others changes in API and BPI
But all-in-all the legacy app compatibility story is really good with Java. They have to keep it in mind with all their enterprise customers.

Because ASM is a tool that operates on the Java byte-code. And the byte-code format changed to introduce new features. As such, you had to upgrade the tool to support the new byte-code.
Note, that software compiled with an older version of the JDK does not always work with newer versions of Java. For example, enum was not a keyword in early versions of the JDK.

Java Version Compatibility Issue

I have a client jar made-up using java 1.6 and used enum and other new features of java, my application is built on java 1.4.
I want to use that client jar in my application.
Is it feasible to do ?

Normally: no, you can't.
You could use a library/byte-code rewriter like Retroweaver to rewrite the library to be 1.4 compatible. There's also Retrotranslator which does the same thing and other tools. The last time I used Retroweaver was just after Java 5 was released, so I can't talk about it's current state.
But that will be a hack at best. Using an ancient Java version is a liability at best and you should upgrade to at the very least Java 5 as soon as possible.

Can't you upgrade to JDK1.6?
else you need to add rt.jar of JDK1.6 to your class path but that will cause conflicts for classes common to JDK1.4 and JDK1.6

Your client jar will need JRE 1.6. As for your application, ideally you should be able to run it on JRE 1.6 as Java is backward compatible.
So you need to port your application to JRE 6, recompile and then you should be able to use client jar.
However, upgrading and porting has it own complexity and consequences.

you could try making the jar available via a web service interface and run it as 1.6; should work, but I won't tell you it 'll be easy.

You obviously need JRE 1.6 or higher to run your library code. Due to backward compatibility the 1.4 part of your application should run on a that JRE as well. How you interact between your 1.6 lib and your 1.4 application is another question though.
Your application cannot use enums or other 1.5 features directly. If everything you directly access in your library is 1.4 compatible it should work, I think. E.g. if your application defines an interface and the library provides an implementation of that. (I.e. typical plugin pattern.) If your library's interface needs the application to use 1.5 features, e.g. pass an enum value as method parameter, that obviously won't work with your existing byte code.