Many of the users of my Java applets/applications don't have Java 7 installed (about 80%, surprisingly). If I compile my programs with Java 6,
Will the Java 7 users be exposed to the security vulnerabilities in Java 6?
Will my applet/application work with Java 6 and 7?
Are there any disadvantages? I am not really using any of the new Java 7 features (except the diamond operator which is easily fixed).
Will the Java 7 users be exposed to the security vulnerabilities in Java 6?
AFAIK, It's Java 7 which has the most serious security vulnerabilities. How you compile the code doesn't matter, only what the code does and which JVM version you use.
Will my applet/application work with Java 6 and 7?
If it has not bugs, yes. If it has bugs, it is most likely to do the same thing on both, but possibly not. i.e. it might be that a bug appear in one version but no the other or in different ways on different versions.
Are there any disadvantages? I am not really using any of the new Java 7 features (except the diamond operator which is easily fixed).
The disadvantage is just that you cannot use the new syntax or the new Java 7 libraries.
How the code runs or performs is not changed.
Security flaws have been discovered with both Java 7 and Java 6 when running in browser sandboxes; i.e. when running applets. The most recent one was Java 7 only, but previous ones have applied to Java 6 or multiple versions.
The problem is that people who run your applets need to have Java enabled in their browsers. And that makes them vulnerable to attack by people planting bad applets; e.g. on hacked 3rd party websites.
The best security advice we can give to users is to disable browser Java because of past and potential future vulnerabilities. (On some platforms, a complete uninstall is advisable). These measures will have the side-effect of rendering your applets useless.
IMO, you should be removing your applet functionality entirely rather than trying to make it work with multiple Java versions.
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.
I have an old web application compiled with Java 5, which for various reasons is not easily upgradeable to a newer version of Java, and which currently runs under Java 5.
My question is whether running the old web application with a newer version of Java (without recompiling the application with the newer Java version and assuming this will not lead to runtime errors) going to mitigate in any significant manner the security risks of the older Java runtime environment?
(I am speaking specifically of security risks related to the older Java runtime environment, I am aware of the fact that passing to a newer Java version will not reduce security risks related to XSS and the like).
Generally it is best to keep your Java runtime up-to-date. If there are any security risks mitigated by upgrading depends on the application, of course. A "Hello World!" application is likely not to be affected, as it has no security requirements, no attack vectors and doesn't use much runtime components anyway (attack surface).
However, a web application commonly runs on an application server, which will likely use Java for its TLS implementation. That means that it is likely that your TLS implementation has not received an upgrade in years. Although Java has some advantages compared to C thwarting some attacks, other vulnerabilities will certainly be present. For instance, Heartbleed is extremely unlikely to be an issue because it depends on buffer overruns, and Java has internal protection against those. PKCS#1 v1.5 padding oracles are likely to apply because it depends on the actual implementation.
As the Java executable itself is not particularly riddled with easy to exploit bugs, it mainly depends on what functionality is used from the runtime classes of your server, libraries and application (in that order, the server is much more likely to have a large footprint). Upgrade your Java version and your server + libraries. Some utility libraries may have less priority depending on their functionality, but stay vigilant. You don't want to have a vulnerability if e.g. Apache Commons Codec has sprung an issue.
Even more important: create an update and upgrade strategy for your system and adhere to it. The amount of testing depends if you have to update or upgrade your system; if well implemented you could go for automated testing for updates and do a full round of testing for upgrades. Hopefully the libraries use semantic versioning so upgrades can be distinguished from updates.
If running it on newer versions won't lead to runtime errors depends on the application; it won't if it was build with Java portability in mind, in all likelihood. It is however possible to abuse the Java language to such a degree that it will fail. For instance, I've seen an application crash from one runtime to another that incorrectly implemented equals while that element was kept in a list.
For such an old application I think it is time you a full round of testing and possibly a code review to assess if compatibility issues are a topic or not. I've had Java 1.2 apps run without a hitch, but as stated, it depends on how the application was programmed. I'd certainly recompile the classes (where possible) to the latest version, both for compatibility and performance issues.
You may first want to migrate to Java 8 before going to Java 11 (both are long term support releases). Java 8 is end of life, but you may want to do a double step because you've been so far behind. Probably that Java 8 version is then just for a short functionality test.
You're probably already need licensing for your Java installation, but I'd make sure that you cover things commercially as well. With Java 8 and 11 there should be a few options worth perusing.
Note that Java 10 onwards is 64 bit only. I've seen 32 bit versions of Java 10 from other vendors, but I'd not upgrade to those as you'll put yourself in another corner to get out of.
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 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)
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.