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.
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.
We have an old project using gwt 2.6 and therefore we need to compile with -source 1.7 option.
The JRE and JDK used are 1.8, but compile with 1.7 source code option.
We want to use the new compute function from ConcurrentHashMap which is only available from java 8. When using eclipse and maven everything compiled well. On the other hand IntelliJ is complaining. My question is, will it work or will we have issues with it?
Will this project run?
Searching in google for ConcurrentHashmap compute, java 8 and source code level 1.7 did not give any info.
If at all, this would require a lot of careful "manual" work.
When you look at this question for example, you can find that there are various different ideas how people want to enable "stream based" functional programming with Java 7. Maybe, after doing a lot of research, you might be able to find similar things regarding such "enhanced collection" features.
But then, all of that might be quite fragile. The fact that some examples might work fine wouldn't mean that you would be able to run a large production code base on a Java 7 VM.
Thus more of a non-answer here: be careful how to invest your time and energy. Instead of trying to backport libraries to Java 7, rather look into moving your whole project onto Java8 at least. Especially keeping in mind that the release cadence for Java has changed significantly, and going with outdated Java versions for many years is simply even less desirable compared to a few years ago.
Well, the simple answer is that it will not work. The target runtime will not have the updated API (i.e., the compute*** methods won't be on the version of Map that Java 7 has).
So if you deploy that code, the runtime will understand the class version, but will raise NoSuchMethodError and similar errors.
In addition to this, there are many reasons for upgrading your runtime.
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 have two Java artifacts being built. One needs to be built in 1.6, because PowerMock isn't compatible w/ 1.7 and we are using it in a lot of unit tests. Refactoring PowerMock out right now isn't an option as it will take too much time.
However, I want to use this artifact in a Java application built in 1.7 and run the whole thing in 1.7. I think that it should be Ok since it is just building some class files, which I doubt changed much if any probably as far back as 1.2 or earlier. Anyway, I obviously have a fuzzy understanding of this and I am interested to get a Java experts deep dive explanation as to when this would matter, when it wouldn't, and why.
Thanks!
Java is usually backwards compatible between versions so anything compiled on an old version should run fine on a newer JVM. In fact a lot of common libraries are compiled in as old a version as possible (usually Java 5 now a days) unless they need a newer feature to allow more people who are still stuck on old JVMs.
Having said that, there are a few gotchas you need to worry about. One problem I had on some Java 6 to 7 conversion was TreeMap with an initial value of null http://hariharanselvarajan-java.blogspot.com/2013/02/treemap-in-java-6-and-java-7.html
EDIT
Here is a link to Oracle discussing what isn't compatible between 6 and 7 although I would imagine this only affects things that are recompiled: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
The compiled code should be backwards compatible, so if you run it all on java7 it shouldn't matter than some was compiled using java6.
When you try the other way you get an invalid major/minor version number error.
I would assume that you can mix & match java 6 and 7 code too, just as you can (with caution) mix and match pre & post generics java.
My old projects use Java 6 (1.6), and I don't know when I update (Java 7), they can run fine ?
There is an official list of known incompatibilities between java 6 and java 7 from Oracle (including descriptions of both binary and source-level incompatibilities in public APIs).
Also you can look at the independent analysis of API changes in the Java API Tracker project: http://abi-laboratory.pro/java/tracker/timeline/jre/
The report is generated by the japi-compliance-checker tool.
They should do, yes. Java has a reasonably strong history of backward compatibility. However, if these are in any way important projects you should still perform a thorough test pass before deploying anywhere production-like.
There shouldn't be any compatibility differences as the JVM is basically the same. However it is early days so there may be subtle differences which cause a problem which people are not yet aware of.
e.g. Eclipse looks at the Supplier in the java.exe on Windows and sets the command line arguments differently for different suppliers. It has a problem with Java 6 update 22 because Oracle wanted to change it from "Sun" to "Oracle". I believe this has been changed so it is "Oracle" in Java 7 (but still "Sun" for Java 6)
My point being, that if you write generic Java code, you shouldn't have a problem. However, if you are doing something a bit unusual, you are likely to need to re-test your application.
As was already stated backward compatibility is a very important aspect in new Java releases, so in general there should be no problems in switching to a newer Java version. In this case, however, Java 7 seems to have a few bugs in the new hotspot compiler optimizations. The Apache Software Foundation has issued a warning that their products Lucene and Solr are affected by these bugs.
http://lucene.apache.org/#28+July+2011+-+WARNING%3A+Index+corruption+and+crashes+in+Apache+Lucene+Core+%2F+Apache+Solr+with+Java+7
The affected loop optimizations can be switched off by starting java with -XX:-UseLoopPredicate.
AFAIS here, there's no Java 6 features which get deprecated in Java 7 so yes, your project should run fine.