I wanted to try some of the features provided by the java SE 9 (Module System Quick-Start Guide) http://openjdk.java.net/projects/jigsaw/quick-start, when I try to download Java SE 9 jdk I get this statement "Java SE 9 has reached end of support. Users of Java SE 9 should switch to Java SE 10" why is that so, and should I step away from java 9? can someone give me a technical explanation. Thanks
For starters, Java 9 is no longer getting patched and there's at least one significant bug which will never be fixed. The new Java release cycle means that long-term support will not be given to every release. If you want a stable platform, you must either migrate to Java 10, and then to Java 11 when it's available (which will receive long-term support), or remain on Java 8.
Also var is cool.
Because the "service" model for Java has changed significantly (see the Oracle guidance document for example).
There are specific "long term services" releases (the first one will be Java 11).
All other releases are only supported for a limited amount of time (think: the release of the next Java version, plus some courtesy time).
Of course, that is (kind of) the "production environment" answer. When doing a bit of Java development on the side, there is no pressing reason to move on. On the other hand, when you are using some JDK for "education purposes", then you should simply go forward with each new Java version, simply to be able to learn what "latest greatest" Java has to offer.
why is that so, and should I step away from java 9? can someone give me a technical explanation.
The technical reason for the advice is that since it has been EOL'd Java 9 will not receive any more bug fixes or security patches. (Unless you are prepared to pay for a commercial support contract.) See the Oracle Java SE Support Roadmap.
It is up to you to decide whether that is relevant. (It will depend on whether you will be affected by un-fixed bugs ... and that is hard to predict. But you could track the release notes for the Java 10.0.x releases as the come out to see what fixes you may be missing.)
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 currently use Glassfish 4.1 and I really want to use Java 8. Will Glassfish 4.1 work with Java 8 or will I have to upgrade my application container?
Simple answer,
Yes.
GlassFish 4.1 will work with Java 1.8.
In general: updating the jvm version alone rarely leads to issues.
Keep in mind that a lot of work goes into making sure that new Java versions are backwards compatible. And most importantly: a new jvm can always run byte code compiled for an older version of Java. The other way round (upgrading your application server for example) is much more likely to cause significant problems.
So, the (unspecific) answer here is: just try it. And for the record: Java 9 (or newer) with the new module system is a completely different story. But at least for now, the corresponding checking can be disabled on the command line.
Of course, there can be subtle issues for large applications. A new jvm may use different defaults for say, garbage collection settings (or use a different gc in the first place). That can of course change the runtime characteristics of large applications running in a large stack.
The best (and easiest) approach for determining whether Java version 'x' will work Glassfish version 'y' is to refer to the Release Note for that specific Glassfish release.
The Release Note will have a section titled Hardware and Software Requirements, and within that a sub-section titled Required JDK Versions.
For Release 4.1 the answer is:
GlassFish Server Open Source Edition Release 4.1 requires Oracle JDK 7
Update 65 or later, or Oracle JDK 8 Update 20 or later.
Notes:
The word "later" in the part stating "Oracle JDK 8 Update 20 or later" is ambiguous, but it is referring only to the update level for the specified JDK version. Do not interpret "later" as implying that Glassfish 4.1 might work with Java 9 or higher. It would be much clearer if the wording was:
GlassFish Server Open Source Edition Release 4.1 requires Oracle JDK 7
using Update 65 or later, or Oracle JDK 8 using Update 20 or later.
It is incorrect to state that "Glassfish 4.1 will work with Java 7 or Java 8", because in both cases a minimum update level is also required.
You can also get the minimum JDK requirements from Glassfish itself. Under the root of the unzipped download in a file named README.TXT there is a section titled 0. Prerequisite. For Glassfish 4.1 it is worth noting that the information given conflicts with that in the Release Note!...
GlassFish 4.1 requires Oracle JDK 7 Update 65+ or Oracle JDK 8 Update
5+.
In the odd cases where the requirements in the documentation conflict I'd always be inclined to choose the higher update level, and most of the time this is unlikely to be an issue.
in detail:
if we use public API for example, write java program for example , in JDK 1.4, if should run correctly in all version above it. in all update version in 1.4, in 1.5, 1.6 and 1.7?
Also , what is the combability rule between different updater versions , for example 1.6.22 and 1.6.23 what can not be changed, what can be changed?
of course, public API definition can not be changed, how about others? javadoc? internal API definition, implementation?
It will be great if someone can point a concrete official document on this topic. thanks,
there is one example in java document bug, that they intended not to change between updater version. see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6475885
this should be one of its big picture, but we better to have a complete description on this.
need to know the complete story so that we feel safe to upgrade to bigger version.
The general rule is that any code that is written and compiled against the APIs of Java X should run on Java Y where Y >= X.
There are occasional exceptions to this; e.g. where the application's behaviour depends on some undocumented behaviour (typically a bug) in Java X that was corrected in a later version.
AFAIK, there is no single document that lists these incompatibilities. The release notes for all of the Java major releases include a list of changes that could result in breakage of older code.
Having said that, the prudent approach is make sure that you thoroughly test / retest your software when you upgrade to a more recent Java release. And if your software is shipped to customers / clients, let them know if / when it is safe for them to upgrade, and (if necessary) provide them with fixes for any problems that your testing has uncovered.
need to know the complete story so that we feel safe to upgrade to bigger version.
Feeling safe is beside the point. Thoroughly test your application on the later version. That is the only practical solution. And that would be the case even if each and every incompatibility was exhaustively documented.
Think about it. How can you know for sure that your application won't somehow be affected by change XYZ? Or that some 3rd-party library that you use won't be affected? Answer: you can't.
No manner of complaining here that you think that Oracle should handle this issue differently is going to make any difference. Not that I think that they could handle this better without changing their business model. How much would you be prepared to pay for a Java platform that guaranteed there were no version compatibility issues?
This is not a full answer but I will add that will-it-run and will-it-compile are two different things. Keywords introduced in 1.5 will prevent some 1.4 code from compiling but the byte code will run just fine.
Almost anything can be changed between versions there are no set rules for such things. Use the release notes to publish changes or review them between versions such as:
http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html
Usually only bug fixes are the cause of minor versions (like you detail 1.6.22 - 1.6.23), or simple enhancements which are only ever good things. When the major version numbers change then you can expect more major changes but you still "hope" for reverse compatibility.
I don't think JDK ever changes an API that breaks backward comparability (except unintentionally).
They introduced #deprecated tag in the very beginning, probably thinking that they may need to do some API cleanup in future. But that never happens. No #deprecated API has ever been removed, or behavior changed.
if we use public API for example, write java program for example , in JDK 1.4, if should run correctly in all version above it. in all update version in 1.4, in 1.5, 1.6 and 1.7?
See this table, that shows breaking changes in public jdk APIs
See these official documents about versions compatibility:
Java SE 7 and JDK 7 Compatibility
Java SE 6 compatibility with J2SE 5.0
Incompatibilities in J2SE 5.0 (since 1.4.2)
Java SE 1.4.2 Compatibility with Previous Releases
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.
It's been a while when I received some of the subscription from free resource
talking about the Java updates and many.
I realized that Sun has been taken over by Oracle.
And so Java is now in their control.
Last info I received, is that Java 7 is openly released with its API for public.
And I am interested to grab it on! But, here I'm a bit wondering.
Firstly, about Java 6.
It is located on the Oracle website....
But Java 7 is not stored there.
Instead, it is stored in a different location... on the java.net website.
Actually, why is it separated like that?
Wouldn't it be great if Java 7 was already stored at Oracle also?
It is not BETA anymore, is it ?
Hopefully there's a bit of light for me regarding these questions....
You can get the early access release here
The Open Source project is here
Java 7 is going to be released on 28th July 2011
Java 7 has not been released yet. If everything goes according to schedule, it will be released in a few days.
Since it is not released, any version of Java 7 you might encounter must be a Beta release, (or worse yet, an Alpha release). That said, the process by which Java 7 was put together was quite open, which is the reason that you've probably seen news articles about the contents of Java 7, even though Java 7 isn't really available yet.
Java 7's specifications have been released to the public, but JDK 7 is still in beta under the OpenJDK project.