I will be making a Java application using Java FX. I want to use SE8, but I'm concerned that Java FX isn't as usable in SE8 as SE7; has anyone used Java FX in SE8 and can confirm that it isn't buggy or difficult to use? Thanks, I don't want to have to switch platforms in the middle if it gets messy!
Review the answer to: Is there a JavaFX 8 changelog?
Then decide for yourself if you would rather use Java 7 or Java 8, given that:
Many bugs in the JavaFX implementation in Java 7 were fixed in Java 8.
Many features were added to JavaFX in Java 8 which are not present in Java 7.
Numerous architectural performance improvements were implemented for Java 8.
The currently scheduled date for end of public updates for Java 7 is April, 2015.
The JavaFX project developers rarely backport bug fixes from the Java 8 branch to earlier branches.
Is JavaFX in Java 8 bug free? => No.
The Java 8u20 update release will include many (mostly minor) bug fixes for JavaFX.
Future Java 7 update releases will not include the majority of these bug fixes.
Does JavaFX in Java 8 have fewer bugs than JavaFX in Java 7? => Certainly.
The major issue with JavaFX development on Java 8 at the moment is the SceneBuilder tool for Java 8 is only in early access release. However, it will have a production release quite soon and the latest early access release builds for SceneBuilder are quite usable.
Related
I have a program for work that I'm told will only use Java version 8 update 192 to run correctly. When I downloaded eclipse, it's suggesting that I use JRE 17.0.2 but I recalled my coworker saying I need Java 8 update 192 otherwise it won't work. Does the JRE version matter? Is it irrelevant?
Perhaps I need to download JRE 8.192? I'm not sure. Any help would be appreciated.
I have a program for work that I'm told will only use Java version 8 update 192 to run correctly.
I would doubt the accuracy of that statement. I would say that someone is making a statement without evidence ... if that is what they actually said.
Maybe a more accurate statement is that the program is only known to run on that particular version ...
Anyway, it will probably run on a later version of Java 8, or Java 11. Java 17 is less certain because of the issue of package sealing / blocking of access to internal packages that occurred in Java 16. (Some of the sealing / blocking started in Java 9 ... but there are easy workarounds ...)
Q: Do you need a JRE?
A: No. A JDK will work just as well. (A JDK distro includes a JRE.) But unless there are strong counter-indications, you need the latest version of Java 8, 11 or 17. Java 8 u192 is years out of date.
The only way to be sure that the application will work on a particular version of Java is to try it. In general, there are no shortcuts.
Java 8 is still available, as the first Long-Term Support (LTS) version. The current release is Update 331. I would suggest starting with the latest update of Java 8.
Be aware that Java 8 is not receiving regular updates for the public except for critical security patches. You may want to consider paying for a support contract from any number of vendors such as Azul Systems or Oracle to get support including possible additional updates releases through the rest of this decade.
Generally Java apps will run on later versions of Java without any modifications needed. The Java team at Oracle and the OpenJDK community place a very high priority on preserving that compatibility.
However, there are exceptions to the compatibility policy. In particular: Java 9 introduced the Java Platform Module System which caused some problems in some apps. And in later versions of Java some libraries that were previously bundled are now removed. Some of those removed libraries were transferred to the Jakarta EE project at the Eclipse Foundation. Some were abandoned for lack of interest such as CORBA.
Some few parts of Java that were for years marked as “deprecated for eventual removal” have now been removed.
If you consider moving beyond Java 8, I suggest your first step be sitting down to read through the Release Notes for every release of Java. They are quite well-written. They should alert you to any issues that may affect your app.
FYI, Java 17 is the latest LTS version. Java 18 is current.
As in the other answers, an application built for Java 8 will probably work fine in Java 17, with some caveats, but if you absolutely need the final product to run under Java 8, go get a real Java 8 runtime and set it up in your IDE. Building a Java application for any specific Java version is best done by having an actual copy of that runtime present, preferably a JDK. By having an exact version of its standard library to compile against, you can avoid accidentally referring to packages, classes, and methods added to, or removed from, later versions. You can get an OpenJDK build of Java 8 from https://adoptium.net/?variant=openjdk8 . Be sure to ask your co-worker why they're mentioning an outdated patch version.
Additionally, keep in mind that Eclipse is itself a large Java application. Running it requires Java, and a growing number of downloads include a Java runtime for that simple reason, even the ones that do not include Java development tools. You don't have to compile your code against that version of Java, though--you probably don't even want to since JDK downloads will include JavaDoc for the standard library, among other useful extras.
Here's the thing:
Me and my teammates are now working on a Java project, but I'm almost new to Java development. The thing is that I recently updated my local Java version to 15.0.2, however, they created the project with JDK 1.8 (Java 8 perhaps?).
We are worried that this might cause some conflicts since our Java versions are not corresponding, and I'm also not familiar with the relationship between Java version and JDK version (Just like Java 8 and JDK 1.8).
Could somebody give me some explanations of this? Thanks a lot!
We are worried that this might cause some conflicts since our Java versions are not corresponding ...
Yes, you could run into problems:
There are significant differences in the Java language and Java standard class libraries between Java 8 and Java 15. Code written for Java 15 using Java 15 may not compile on Java 8.
Java 8 and Java 15 tool chains produce compiled code with different classfile version numbers. Code compiled for Java 15 will not run on a Java 8 platform.
It is possible to work around these problems, but it is much simpler if all project members use the same Java version.
If you are new to Java, my recommendation is to install and use Java 8. Note that it is possible to have different versions of Java installed simultaneously, and use different versions for different projects.
... and I'm also not familiar with the relationship between Java version and JDK version (Just like Java 8 and JDK 1.8).
It is pretty straightforward. Java 8 is JDK 1.8, Java 9 is JDK 1.9, and so on. This started with Java 5 / JDK 1.5
The weird numbering is a result of a Sun Management / Marketing decision when naming Java 5:
"The number "5.0" is used to better reflect the level of maturity, stability, scalability and security of the J2SE."
Source: https://docs.oracle.com/javase/1.5.0/docs/relnotes/version-5.0.html
(You could also say that the people who made this decision didn't understand the principles of semantic version numbering.)
I need to migrate my swing application from Java 1.7 to 1.8.
Application only works for Window environment.
Did this Java upgrade especially for swing API cause any feature stop working or any of its UI components behaviour change?
There was an interesting bug report on StackOverflow recently. But seems that the situation described in that question is very specific. We successfully migrated our quite huge Java 7 Swing application to Java 8. There were only several minor things to fix not related to Swing. In particular some complex generic parameters may work in Java 7, but produce a compilation error in Java 8. After several months of using Java 8 no Swing-related problems were noticed in our application.
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).
I compiled my old JAR files in Java 7 and my production environment has Java 8. Is there anything I need to be careful about directly deploying the JAR files onto Java 8 Environment? I test ran them on Java 8 and it worked fine. Could I encounter any problems or should I be fine? I was wondering this because I was debating removing Java 8 and installing Java 7.
EDIT: A side question: Do companies update their code when they update their Java version? I can't imagine how painful this must be so have your app working on a previous version and then completely fail on the new version.
I was wondering this because I was debating removing Java 8 and installing Java 7.
I assume you mean the other way around?
Java attempts to maintain backwards compatibility as far as it can, so theoretically at least you should be ok.
In practice however, issues do sometimes come up, so I'd advocate testing thoroughly. These may be due to regression bugs, or (more likely in my experience) buggy code that might have run fine under Java 7, but not under 8. (FWIW, I had a couple of FX apps that mixbehaved under 8 but ran fine under 7, it turned out both were due to bugs in my code that coincidentally had no unusual side effects when running with 7.)
Usually, there should be no problem. Otherwise you would have a hard time to use any third-party libraries not explicitly compiled for Java SE 8.
I recommend to run your automated tests on a continuous integration server such as Jenkins using Java SE 8 and see if you have any issues.
It is safe to package Java 8 application with jar dependencies compiled with Java 7. Given that said, however, keep in mind differences in JDK 7 and 8, that can result the same Java code could behave differently when running on JDK 8 vs JDK 7 (refer to JDK 8 release notes)