2

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.

danmaze
  • 319
  • 3
  • 8

2 Answers2

2

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.

danmaze
  • 319
  • 3
  • 8
0

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/ .

Florian Hergenhahn
  • 56
  • 5
  • Thanks for your answer. I just wanted to be sure since Eclipse's prevention against the use of available packages that are not part of the "public" Java API already suggests this. Does this mean that JavaFX is proprietary? – danmaze Oct 20 '19 at 12:23
  • No JavaFX is not proprietary anymore, but it was originally developed by Sun Microsystems but later got acquired by Oracle. https://en.wikipedia.org/wiki/JavaFX – Florian Hergenhahn Oct 20 '19 at 12:40
  • @typicaldanny Regarding Eclipse, it's most likely being safe when it says JavaFX is not public API. For one, not every JDK/JRE distribution includes the JavaFX libraries, even in Java 8. Then there's the fact that—if I remember correctly—the JavaFX libraries are not part of the `rt.jar` file but are rather in their own JAR file (e.g. something like `javafx-rt.jar`). However, note that JavaFX has it's own public API (e.g. `javafx.*` packages) and private API (e.g. `com.sun.javafx.*` packages). – Slaw Oct 20 '19 at 12:53
  • @typicaldanny [OpenJFX is an open source, free software library licensed under the _GNU General Public License with Classpath Exception_](https://wiki.openjdk.java.net/display/OpenJFX/Main). However, I don't know how much of that relates to JavaFX 8. Note that since Java 11 the JavaFX libraries have been removed from the JDK and now have to be pulled in like any other dependency. Current version is JavaFX 13 – Slaw Oct 20 '19 at 12:56
  • 1
    I’m skeptical about this answer. The general question Eclipse is trying to get you to ask is “Could this class go away in a future standard library release? Does this matter?” There are a lot of “internal” classes (if I recall correctly, often starting with sun in their package names) that the standard library devs might want to clean up in the future. But that seems unlikely for javafx.application.Application. – Benjamin Berman Oct 20 '19 at 13:09
  • Also, you may want to check out the docs for newer java releases – Benjamin Berman Oct 20 '19 at 13:10
  • @Slaw, thanks for the clarification. So, what I now understand is that JavaFX is mostly "public". However, since the JavaFX libraries are no longer a part of the standard JDK as of Java 11, the future of JavaFX has become unclear. – danmaze Oct 20 '19 at 13:39
  • This means that as @Benjamin points out, Eclipse is probably trying to get me to think about the implications of this for my project. – danmaze Oct 20 '19 at 13:40
  • @typicaldanny The future of JavaFX, as of now, is that it continues to be developed as OpenJFX which is part of the OpenJDK project. Currently OpenJFX is mirroring the Java six month release cycle, including the two patch releases between the major releases. Gluon is currently offering (paid) long term support for JavaFX 11 and, as I said, the latest release is JavaFX 13. – Slaw Oct 20 '19 at 13:44
  • That answer refers to Java7 api, but FX was integrated into Java8 and pushed out in Java11 (if I remember well). – Jean-Baptiste Yunès Oct 20 '19 at 13:46
  • @Jean You are correct, at least for the Oracle distributions. – Slaw Oct 20 '19 at 13:50
  • @typicaldanny And to add more regarding the whole "public API" thing. JavaFX, as a library, is stable. It is okay to rely on its public API (i.e. the visible members in the `javafx.*` packages). What is _not_ stable is its presence within the JDK/JRE, and I suspect that's all Eclipse is worried about. – Slaw Oct 20 '19 at 13:57