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/ .
Related
I am using Pair data structure in my code with java 8, it runs fine in local.
But in jenkins build, I get this issue:
error: package javafx.util does not exist
import javafx.util.Pair;
Your code uses the Pair class that comes with JavaFX. Unlike Swing, JavaFX has never been a standard part of Java SE. You must make an implementation of JavaFX available to your app.
It would seem that 👉 your local machine has an implementation of JavaFX, but your Jenkins machine does not. You need to get an implementation of JavaFX onto that Jenkins machine.
The OpenJFX subproject on the OpenJDK project is an open-source implementation of JavaFX. The Gluon company leads OpenJFX, in cooperation with Oracle.
One solution is for you to bundle OpenJFX as part of your app. The common way to do this is to configure a dependency management tool such as Apache Maven or Gradle.
An alternative solution is to use a JDK that comes bundled with an implementation of JavaFX.
Vendors of JDK products are free to bundle an implementation of JavaFX.
Oracle chose to do so with early releases of their commercial Java 8 product. 👉 The company ceased bundling in later releases of Java 8. I guess that your local machine has an earlier release of Java 8 while your Jenkins machine has a later release of Java 8, with and without JavaFX bundled respectively.
At least two JDK vendors currently bundle OpenJFX with some editions of their JDK products:
Azul Systems provides ZuluFX
BellSoft provides LibericaFX.
Of course, going this route means you must also get OpenJFX onto your app’s deployment machines.
As commented, if you are not really making a JavaFX app, then bundling OpenJFX just for that Pair class is overkill.
Some folks use the map entry interface and implementations as a pairing class. See the Map.Entry interface with links to the mutable and immutable concrete classes.
I suggest you roll your own.
The easiest DIY implementation in Java 16+ is as a record.
record PairOfInts ( int x , int y ) {}
Tip: You can declare a record locally within a method, in addition to nested in a class or standing alone as its own class.
How can I use an user interface (GUI) in Java ME? I followed some tutorials and all them point to the javax.microedition.lcdui package, but it just doesn't exist in Java ME 8 SDK.
Since I can't find that package, and SDK 3.4 gives me errors in Netbeans (I activate it and add it as platform, but it doesn't appear when I have to choose a simulation platform when creating a project.
You can see here how I don't have the LCDUI package:
I need some help in order to use GUIs in this Java version.
Thank you.
As far as I know JavaME 8 is targeted at the embedded space and isn't supported on phones etc. It should have a profile without any UI elements and might have JavaFX embedded.
I am unaware of any device in the field that supports JavaME 8 but might be missing something.
I need to target Java 7 and would like to use JavaFX and FXML on that project. We have some working code for Java 8 and it would save an immense amount of time if we can retro-fit those modules to Java 7.
I'm posting because I'm getting compile errors on the first attempt. In the first instance, I can't find the #FXML annotation, package:
import javafx.fxml.FXML
In Java 8 JDK. However that just a for instance example.
I was hoping to find Java 7 JDK JavaFX documentation. The searches and tutorials seem to be either aimed at Java 8 and/or not about things that work differently between the two
The solution is some documentation describing what's different in Java 8 JDK JavaFX to Java 7's JavaFS JDK? Google isn't giving me much satisfaction and most of the Stackoverflow questions are going the other way. I suppose it is rare for someone to ask how to go back a version. Any one seen, know of or some release notes on code differences (or a migration guide??). Many thanks in advance.
JavaFX 2 is the version of JavaFX included in Java 7. All of the Oracle JavaFX 2 documentation is currently available online (it may be removed at some time in the future in the same way JavaFX 1 documentation was removed). FXML is supported in Java 7, there were no significant changes to FXML for Java 8, so any FXML specific information you read for Java 8 will also be relevant for Java 7.
You don't really need a backward migration guide I think (not that any such guide would exist anywhere anyway). You can just compile your program against the most recent version of Java 7 and fix any compile errors that occur by removing any lambda references and coding against the older API. Unless you are using JavaFX 3D or printing or some such feature which was completely new in Java 8, I can't really see backward conversion being much of a problem or an extremely large task (90%+ of the public API will be unchanged).
One reason you are getting compile errors such as class not found is because you need to explicitly add the JavaFX 2 runtime to the compile and runtime classpath (for Oracle Java 8, this requirement was removed). See the answer to Compile code using JavaFX 2.0 (using command line) for more details.
I'd recommend against backporting code anyway as there were so many improvements in JavaFX 8. Also Java 7 has a limited support life. If you bundle your app as a self-contained application, then you have control of the Java runtime that the app runs on, so Java 8 would be an obvious choice for such a scenario. But I guess you may have some constraint which forces you to code to Java 7 (which you don't need to outline here).
This question already has answers here:
It is a bad practice to use Sun's proprietary Java classes?
(7 answers)
Closed 8 years ago.
I'm actually developing a Java applet to access an HSM in order to sign data.
So I'm using a lot of Sun packages (PKCS11 wrapper and sunPKCS11 provider).
I saw that link : http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html that tells us it is discouraged to use sun packages.
But I want to make sure why. I'm actually compiling my code in Java 1.6 x86 JDK.
Is it possible that end-users won't be able to use my application when updating their version of Java ?
Or will the problem appear only if I change my JDK to compile my code ?
Or is it both situations ?
Thanks in advance for your clarifications.
It's stated pretty clearly in the documentation your linked :
A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.
So end-users might not be able to use your app if they're not using the same JDK as you.
And yes, in the future you might have problems too with a newer version of your JDK.
The main problem is that those packages/classes might not exist in other JDKs or versions of the same JDK. You might get problems compiling your code on another JDK but it's mainly the users which you should think about: if their runtime lacks the classes that are needed they eventually try to run some code that isn't available and depending on how you structured your application the result might range from functionality simply being unavailable to a crash of the application.
Note that this might also be the case if you're hosting the application, i.e. when it is a web application. We ran into the same problem with some of the imaging classes which prevented us from upgrading the Java version on our servers without having to change the application as well.
I am involved in a project that will need to run via web and have access to java's compiler tools and/or javacc api. My team is thinking of using a java applet to make it web based. I'm wondering if there are certain limitations on what an applet can and cannot do in this case. I would assume that since access to the compiler would be done on the server, not the client's machine, that this wouldn't be a problem. Does an applet allow us to separate the two as described?
An applet (and even a JavaFX applet) can work in this situation if the applet is signed. There are numerous subtle pitfalls with applets, so I would advise prototyping before committing to that technology. Follow the JavaFX deployment guide to see how to deploy a JavaFX based applet.
I had thought that to compile Java, you needed to have the full Java Development Kit installed (which would be tricky to ensure in an applet deployment situation). But it seems that the compile API is included in the javax.tools API included with the standard Java Runtime Environment. So this likely means that you could develop your solution, including client based deployment and compilation of Java code, without requiring the user install the full Java Development Kit.
You may alternately wish to consider a client/server solution where the compilation can be performed on the server. An example of such an approach (with a Java WebStart based solution) is the TopCoder Algorithm Competition Application. Here is a jnlp file (http://apps.topcoder.com/wiki/display/tc/The+Algorithm+Competition+Arena) to run this application. I suggest you register an ID at TopCoder using the application and try out writing and compiling some code using it. The TopCoder implementation uses plain Swing as it was written before JavaFX existed, but you could equally use JavaFX for your implementation if you preferred.
If you additionally need an editor (with syntax aware text styling) for the code you will be compiling, you could use something like this CodeMirror based editor embedded in JavaFX. The CodeMirror based solution wraps the editor in html based WebView control. For JavaFX 8 you will probably be able to make use of the new TextFlow control for a syntax highlighting text editor, but that API is not part of a supported public release yet.
Update
I got this work using the strategy outlined in this answer.
The image is an html page allowing access as an applet or a webstart application to the client code editor. The top area of the image is the code editing area which is based on a WebEngine with an embedded syntax highlighting CodeMirror JavaScript editor that supports Java editing. The bottom area of the image is the output of compiling the code in the editor locally on the client machine and subsequently running it. The output constists of any compilation errors, any program output to sysout, as well as any runtime exceptions printed to syserr. The tricky parts of the solution were:
Working out how to capture sysout and syserr and redirect them to a JavaFX control.
Finding the Java compiler.
The default Oracle Java Runtime Environment Provider merely provides a generic interface to a Java Compiler implementation, but it provides no java compiler implementation itself - that implementation is only included in the tools.jar included with the jdk. So when I packaged my applet, I included the tools.jar in the packaging for the applet. I had some difficulty getting the service provider interface to get me an instance of the javac compiler, so in the end, I just instantiated it using the following line:
JavaCompiler compiler = new com.sun.tools.javac.api.JavacTool();
The above is somewhat brittle as sun may change their private com.sun classes at any time - but at least it worked in this instance.
Another thing to be aware of is that if you ship a tools.jar with a javac compiler which is earlier than the runtime environment that you have available for your system, then you might get some warnings such as below:
warning: C:\Program Files\Java\jre8\lib\rt.jar(java/lang/Object.class): major version 52 is newer than 51, the highest major version supported by this compiler.
It is recommended that the compiler be upgraded.
The above warning occurred because I shipped the applet with a java 7 tools.jar and ran the applet with a java 8 runtime (note that the applet worked fine regardless of those warnings).
Update
I put the code for this solution in a github repository (project name conception). The updated solution uses the Eclipse Compiler for Java rather than the Oracle Java Compiler. Mostly because, for the Eclipse Compiler, it is a separate jar (only 1.8meg rather than the 14meg tool jar of the oracle distribution) and the licensing is a bit clearer. Because the Java compiler interface is pluggable, the Oracle compiler can still be used if tools.jar is placed on the classpath.
Yeah applets can access them and can be a good choice. But it has very limited/ dull look and feell. Go for JavaFx in this you can define your own StyleSheet so it will give you a very good look and feel and yeah definitely it will separate the two layers too.
JavaFx Oracle Documentation