I found this page stating that Java 8 support for Juno is deffered, but I can't find more information how soon people can exspect to be able to write first closures in Eclipse and get productive with that stuff.
Has someone got insight how long we still have to wait? The Java7 features were in 3.7 really quickly, that's why it's kind of odd that this task is deferred.
Any comments, ideas? Or maybe even a good workaround?
One of the key reasons that Java 8 support was deferred is that Java 8 will be available after Eclipse Juno is released. A major release of Eclipse couldn't be shipped with functionality reliant on an unfinished Java release.
Java 7 support went through a similar issue with Eclipse Indigo. Tooling for Java 7 proceeded in a branch that was merged into main indigo stream after Java 7 shipped, so you saw tooling support in Indigo SR1.
I would expect a similar situation for Java 8. There may be a branch open for this work already. The best place to check in on the status is in the bug that is referenced from the document that you found.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=380190
Java 8 will be released at some point after mid 2013, so there is still quite some time to go :-) Full support in Eclipse for Java 8 should not be expected before Java 8's release date, it was the same for Java 7 support.
Currently, there is no branch open for this work. However, whenever that does happen you can expect to see a few blog posts about it :-)
You may give IntelliJ Idea a try which has preliminary suport for it, see http://confluence.jetbrains.com/display/IDEADEV/IDEA+12+EAP
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 am looking for better HotSwapping in the JavaVM. Being able to only apply method body changes is okay but quite limiting.
The options available is JRebel and a discontinued project called Dynamic Code Evolution Virtual Machine (DCEVM).
There is a JEP 159 out there that was written by the core developper of DCEVM. A blog post from 2011 mentioned that the developers of DCEVM now work for Oracle to integrate this into the JDK.
Do we have this kind of support for JDK 8 beta already or was it postponed to JDK 9?
I need hot swapping for adding and removing and renaming private methods mostly. This would help alot. Is there a product allowing me to do so (beside JRebel which PR-campaigns got me upset).
The last supported version of DCEVM is for 1.6u24 and it only provides 32-bit linux binaries. Since I use 1.7 and 64bit Linux this is both a show stopper for me.
There is also another project available on github called Fakereplace. Can this be easily used for my purpose or should I not investigate into this?
There is a fork of DCEVM maintained in the repository on Github. It was recently updated for Java 8. The binaries are available through the GitHub releases or on the downloads page.
For simple things, like adding/removing methods, it should be pretty reliable (verified by automated tests in 16 different configurations). However, it still could eventually crash JVM, so it is by no means should be used in production.
JEPs coming in JDK 8 and JDK 9 are listed in this page. JEP-159 is not among them. From jep index you can see that JEP-159 is not yet targeted to any JDK release, not even jdk 10.
JEP-159 status is currently "Submitted". The process is described as follows:
A successful JEP passes through the following states:
Draft — In circulation by the author for initial review and consensus-building
Posted — Entered into the JEP Archive by the author for wider review
Submitted — Declared by the author to be ready for evaluation
Candidate — Accepted for inclusion in the Roadmap by the OpenJDK Lead
Funded — Judged by a Group or Area Lead to be fully funded
Completed — Finished and delivered
So it's not yet accepted for any roadmap.
What the difference betwen Open JDK and Oracle JDK?
As far as i understand they work the same. I worked with OpenCV and maybe while i was trying download OpenCV library i downloaded also OpenJDK. And now i all the time get such message:
"System Health
OpenJDK shows intermittent performance and UI issues. We recommend using the Oracle JRE/JDK."
I try looking for info about it but don't understand exextly...
And now i should redownload it or i can work with it?
When I Google for the phrase "System Health OpenJDK" I see a few hits in blogs and the like:
The message appears for be coming from Android Studio, not OpenCV
The consensus seems to be that you can ignore it.
Separately to that, these OpenCV for Java build instructions say:
... In order to build OpenCV with Java bindings you need JDK (we recommend Oracle/Sun JDK 6 or 7), Apache Ant and Python v2.6 or higher to be installed.
The "we recommend" could simply be because that the OpenCV team build and test using Oracle JDKs and not OpenJDK. And clearly, those instructions have not been updated in some time, so it is hard to know if any (hypothetical) issues with OpenJDK are still current, or how they relate to running OpenCV.
So which is actually more stable? I don't know, and I can't think of a scientific way to find out.
Personally ... I'd stick with what I had downloaded for now. If I ran into problems that I thought might be the JRE's fault, I would try out the alternative to see if it made a difference.
Oracle has announced that they stop the official updates for JRE 7 and JDK 7.
As much as I know, Google doesn't say anything about JDK 8, I guess the recommended version is JDK 7 for Android development.
Is JDK 8 officially supported for Android development?
The Google Android development page and, from there, the pre-requisites page list JDK7 as a requirement.
This has nothing to do with Oracle's JRE since the code made during Android development is never meant to run on that JRE - it's supposed to be turned into Dalvik bytecode and run under Android.
So the security concerns of Oracle's JRE are not really at issue here. Google supports JDK7 (insomuch as it pertains to Android development) so that's what you should be using, pending a clear statement of intent from Google.
It looks like Google doesn't officially support the JDK 8 for Android development. See paxdiablo's answer.
But let me add some thoughts.
I wanted to try using the JDK 8 anyway. So I downloaded and installed it, and used it (and Apache Ant) to build a simple Android app.
The app doesn't use any features which are new to Java 8, such as lambdas. In addition, Ant passed a parameter to javac asking it to emit bytecode compatible with older JREs.
The app compiled fine.
The app requires that I root my phone before running it. I haven't done so yet, and haven't tested the app yet either.
Please ping me with a comment in a few weeks. Ask me to update this answer and to let you know whether or not the app worked.
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.