We Keep Coding

How can I get early access to Oracle Java updates, so I can test my RIA and avoid fire-drills when these updates are made public?

Having had our application stop working when customers installed the 7u45 update, we're wondering what more we can do in the future to be ready for these updates up-front and avoid release-day support nightmares.
(Per the Java version numbering scheme, the next Critical Patch Update, planned for January 14, will be 7u51. The next Limited Update (date unknown) will be 7u60.)
I've poked around the Oracle and OpenJDK websites, and not found anything particularly useful. The main Oracle page for Java SE has an Early Access Downloads section. It has three links that have potential, but don't pan out:
https://jdk7.java.net/, which still talks about 7u40 -- no mention of 7u45, let alone 7u51 or 7u60.
http://openjdk.java.net/projects/jdk7u/, which says "We're open for fixes for 7u60 in the jdk7u-dev forest", but doesn't appear to provide any pre-built binaries. It's also not clear to me whether the deployment components (applet plug-in and webstart), the main source of our past compatibility issues, are even part of OpenJDK to begin with.
The Java Compatibility and Performance Program sounds like just what I want, but nobody knows how to sign up for it.
An answer to the second question I linked above points to an OpenJDK bug report that was filed back in August. (It has a "CAP" label, which might stand for "Compatibility and Performance"?) So clearly some people are able to test their applications against these updates. Any pointers on how to join that club are much appreciated!

OpenJDK Bug System
According to this post on the jdk7u-dev mailing list, the OpenJDK bug system may provide a subset of the answer.
The mailing list post says that bugs with the CPU-critical-request label are under consideration for inclusion in the next CPU and bugs with the CPU-critical-approved label have been approved for inclusion in the next CPU. However in practice, it seems that they're using more-specific labels. For the 7u51 update planned for January 2014, the labels appear to be CPU14_01-critical-request and CPU14_01-critical-approved.
You can browse the full set of labels to make your own educated guesses about labels for subsequent CPUs. You can also see bugs whose "fix version" is 7u51.
Java Platform Group, Product Managment blog
The Java Platform Group, Product Management blog looks to be another avenue for partial information. In this comment to the "Updated Security Baseline (7u45) impacts Java 7u40 and before with High Security settings" entry, Erik Costlow of Oracle says:
One of the reasons we created this blog is that it gives us a way of
providing as much information as we can, even more than it already
done on the various OpenJDK mailing lists.
There are some changes that we can't provide advance notice about, and
my hope is to keep that to a minimum. For other changes, not only are
we posting about them here, I am actually going out into other
projects and not only telling them, but (as appropriate) making
contributions. See
https://issues.apache.org/bugzilla/show_bug.cgi?id=55542 for an
example.
Oracle Programs
The Java Compatibility and Performance Program is dead, according to my Oracle account manager. Access to an analogous program for CPUs is tightly controlled (even within Oracle) due to the risk of vulnerabilities being reverse-engineered. (I am not a member and do not plan to pursue it further.) OpenJDK is Oracle's preferred method of compatibility testing, even though it is known not to be bit-for-bit identical to what will be in the next CPU.
Oracle also refers us to the Security Track at JavaOne 2013, in particular the "One Year of Security Enhancements in the JRE" talk, whose slides are available online. Those slides, in turn, say that the blog mentioned above will give "as much advanced notice as possible".

Totally partial answer : 7u60 Build b01 is now available at https://jdk7.java.net/download.html.

Netbeans 7.4 was just released last night. And one of the new features is Java 8 preview capability. Although this might not help you through each release, at least it could help you get ready for Java 8.
https://netbeans.org/community/releases/74/

I noticed that Rory O'Donnell was the one posting release info to all the mailing lists, and sent him an email, and got on an unofficial maling list with announcements of new releases.
Not the "official" answer, I guess, but it might work for you as well.

What popularity measures of Java versions (1.3/1.4/1.5/1.6/...) exist?

After avoiding Java for years, I got back to it and found it more useful, thanks to features introduced in version 1.5 and 1.6 of the language. But how much are these features actually used? My impression of Java projects and programmers is, that most are stuck at 1.4 for several reasons, but I might be wrong. Are there any popularity measures, which Java versions are actually used? For instance has anyone done up to date statistics of open source projects? Analyzing the revision control systems, you could even analyze how fast new Java features got adopted.

There probably are some stats around, but from personal experience I'd say that there are very few 1.4 projects left. 1.5(6) has been heavily adopted and the usage of Generics, AutoBoxing, etc heavily adopted. Most especially generics.

Number of bugs reported on 1.6.0_xx releases indicates there are many more users for java 1.6 (JDK and JRE). - than older versions. Oracle and other JVM developer may have accurate numbers..

Reasons and advantages for upgrading to Java 6 for a non-technical decider (at the client)

I'd like to upgrade from Java 5 to Java 6.
We all know about the technical advantages and benefits, but:
I have the problem that a major client refuses to upgrade from java 5 to java 6 because of "the risks" and "no/too few benefits for us" (banking sector).
What can be answered to a non-technical decider at the client what benefits he'll get from an upgrade - or otherwise which problems/consequences may arise if he'll stay with java 5?
It's not a "fire and forget"-product, it's activly extended with new functionality/features - the development is and will be constantly going on - the dev team would definitly benefit from the jdk 6 features/tools.
EDIT: The reached EOL of Java 5 is a valid point indeed, but it doesn't convince the client because he is using the IBM JRE/JDK 5, which seems that it has not reached its end of life yet. And, beside that the client stated:
"Java 5 is running fine for years and its unlikely that new, unseen problems arise"

Java 5 is now well past its end-of-life date. Sun/Oracle will no longer issue public updates to it.
Java SE 5.0 is in its Java Technology
End of Life (EOL) transition period.
The EOL transition period began April
8th, 2007 and will complete October
8th, 2009, when Java SE 5.0 will have
reached its End of Service Life
(EOSL).
If you find a bug in Java5 now (e.g. a hotspot crash - they do happen), you're screwed. If you have a dedicated support contract with Sun/Oracle, which they do offer for those stuck on obsolete versions, then they can fix it for you.
You could argue that the risk of staying on an unsupported platform is greater than the (more manageable) risk of migrating.

Over time, the client will increasingly need to upgrade because of things like:
Java 5 not being supported on some new hardware or operating system platform,
poor performance relative to newer Java releases,
greater coding and testing costs relative to newer Java releases; e.g. due to the "clunkiness" of older APIs, not being able to use streams, etc
increasing cost of vendor support1: you have to pay for support to get security patches, and the older the release the more you pay (I think)
difficulty of retaining Java developers to work on Java 5 projects,
third party Java libraries no longer being developed and supported for Java 5,
compliance issues; e.g. https://stackoverflow.com/a/3434063/139985
and so on.
But the longer the client delays upgrading, the larger the Java version jump involved, and more work (and potentially pain) that will be involved.
And the longer the client delays, the larger the accumulated costs of things like hardware provisioning, developer costs, deferred projects and so on.
To illustrate, suppose that you had waited 10 years to upgrade from Java 1.1 to Java 1.2. That would mean that you would have spent extra 10 years developing applications that used Hashtable and Vector as their primary data structures. And when you finally upgraded you would have 10 years worth of additional "legacy" code that is more difficult to maintain than if it had been written using Java 1.2 collections.
But the bottom line is that if the client insists on staying an old version of Java, you need to either go along with their wishes (and make sure that you pass on the extra costs!), or find a way to exit your contractual relationships with the client.
1 - The End of Life / End of Service dates vary from one vendor to the next, but AFAIK all major vendors have EOL'd Java 5 by now. Indeed Oracle have EOL's Java 6 and Java 7 as well.

From the source:
Q: How is Java SE 6 different from
the previous version (J2SE 5.0): what
are the improved and updated areas,
such as functionality, security,
performance?
A: Anyone who has existing Java
applications, will benefit immediately
from the performance, reliability, and
UI improvements in Java SE 6. Coupled
with the expanded monitoring and
diagnositics capacities built into the
platform, the release delivers
dramatic out-of-the-box benefits
without any coding changes or even a
re-compile necessary. Simply running
existing Java applications on this
latest release is all that is needed.
More on the same matter (may be of help to elaborate more to the client):
Top 10 Reasons to Upgrade to Java 6
Why should I upgrade to Java 6?

Rather than convince him that there are no risks, I would suggest instead working with him to come up with a risk mitigation strategy.
In other words, agreeing that if you can show that the system running under Java 6 passes tests X, Y and Z he'll be happy to upgrade.

Staff recruitment/retention becomes an issue if the application is seen to be old fashioned. Developers do not usually want to stick around if they see no progression.

Just tell him that's it's a minor upgrade: show him that the version goes from 1.5 to 1.6 using the "-version" command. :)

Since you seem to be aware of all obvious benefits of java 6, and the client has good reason to be conservative, all that's left is to stress that not switching to java 6 will hamper development.
Development will be slower because you will undoubtedly spend time on implementing functionality you get for free in newer releases. And perhaps worst of all, not upgrading on a regular basis makes an upgrade more painful as time goes by, up to the point where it becomes practically impossible.
Typically, overdue upgrades result in a highly unpredictable scenario, with a resulting production loss across the entire company over a longish period of time. (assuming the software impacts a large enough user base within the company)

We upgraded from 1.4 to 1.6 last year. It's been a tremendous help for development, but not without its hiccups. While this was not our motivation, today we are required to "keep up to date" by PCI (credit card handling requirements). Your app may be running smoothly, but I'm sure that Java 1.5 has some security holes that have been fixed since in 1.6.

In Short Java 6 is more optimized,better performance ,reliable and currently supported. It also provides advance options like diagnostics, debugging etc.
Most of Java based technology are already migrated or migrating to Java 6. Even they would stop support for earlier versions.

I'm going to answer from the point of view of the client.
Our systems development shop is still using Java 5. To migrate to Jave 6, we have to test our entire portfolio.
When we moved from Java 4 to Java 5, the process took 6 months, and involved some code changes (mostly changing enum variable names to enumerate).
At this time, our systems development shop has decided that the benefits of Java 6 are not worth the migration pain,
Your bank client feels the same way. They will not migrate until they are forced to migrate to Java 6.

We've had this problem with a client last year and we stood firm and said that future development (against Java 1.4 as it happens) would at a minimum be significantly more expensive in the future and as time went on we it may no longer even be possible with us. It was a risk but we felt it was worth it as it allowed us to greatly reduce our development costs. Obviously we weren't as blunt as the opening line makes out. We showed the client all the reasons why it would get progessively more expensive to stay as they were.

Java is open-source, so what? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I always hear that Java being open-source is a big benefit, but I fail to see how Java being open-source should draw me to use it as opposed to .NET which is closed-source. This website has some Q&A sections (What is the significance of these developments to the industry? in particular) that give a little info, but is being free the only (or the biggest) advantage to Java being open-source?
Since I am a beginner, have any of you pros noticed any major difference since the change was made?
EDIT:
Please disregard the .NET part of this question, I was simply using it as a comparison. What I really care about is knowing what benefit becoming open-source has been to Java.

If you are a mainstream user, there is probably no immediate benefit for you.
However, the open-source base of Java makes it easier for people to adapt it to more niche requirements that the closed-source vendor sees no need to support. Smaller vendors (or open source projects) can come up with solutions to these special needs.
For example, Java runs on a great variety of platforms and operating systems, most of them supported by companies other than Sun (granted, that was the case even before it was open source).
have any of you pros noticed any major difference since the change was made
I like the fact that Linux distributions now include the "official" Sun JVM and JDK, rather than making you install it separately or use the "mostly-compatible" alternative implementation that was provided.

Not entirely fair to say .NET is closed source - Microsoft's .NET runtime and development tools are closed-source.
Mono is an open-source implementation of many things in the .NET world - the CLR and C# being the biggest.

The primary implementation of .NET is closed source, though there are competing open-source implementations.
The primary implementation of JVM is open source, though there are competing closed-source implementations.
The standard for Java remains entirely under control of Sun (Oracle). Others are allowed to provide input, but final decisions are up to Sun.
The standard for CLR is entirely under control of the ECMA and ISO. Microsoft is allowed to provide input, but the final decision is up to the standards bodies. If Microsoft did ignore their decision, it's open to question whether the standard would remain relevant.

The improvements to OpenJDK since it was open-sourced have been immeasurable, here is just a few:
The Zero project, contributed by Redhat, has ported Hotspot to many new platforms like PowerPC (32 and 64 bit), IA-64, ARM and zSeries, and made future ports to other platforms much easier. The Shark subproject has also given it better performance on some of those platforms
The OpenJDK has been ported to new operating systems, such as Haiku and BSD
Many bugs have been reported and fixed by individuals and companies
Apple has joined the OpenJDK project and a MacOS port is in the pipeline
So has IBM
Various innovative projects, such as IcedRobot have become possible
OpenJDK jtreg tests are now available to other Java implementations
Some of the direct benefits to the average Java programmer are:
You can investigate and fix bugs in the JDK source code
You can build custom versions of the OpenJDK (eg. strip it down to make it smaller)
You don't need to pay license fees to ship OpenJDK on embedded devices

Java and .Net are both standards for which anyone can write an open-source implementation. .Net 3.0 just happens to have no complete open-source implementations.
Regardless of openness, the difference for you (and the reason many people choose Java at all) is portability. There are far more implementations of Java, and most are closed.
Java can create apps for cell phones. Java can create web apps. Java runs on Mac. Not .Net.
Sun is just advertising the simplification and standardization which a common open-source core may provide. But if you look closely at the page you linked, you'll see that it's using the future tense.

Opening up the JVM source helps in porting it to other architectures such as ARM for embedded use.

More choices. Flexibility. Java Community Process. I think mainly lower cost of ownership - Eclipse+ApacheServer+Linux - are all free.

Running Java bytecode on the Android - Sun JVM on top of DalvikVM

Since both the java implementation (OpenJDK) and Android's virtual machine DalvikVM are opensource it must be possible to implement Sun's JavaVM on top Google's DalvikVM. This would make it possible to run JVM based apps and languages (Clojure, Jython) out-of-the-box on the android.
Is there an ongoing effort to produce such an implementation of the Sun JVM?

The OpenJDK makes use of native code so it would be a non-trivial port... there is at least one VM (JikesRVM) that is written in Java, unfortunately it is not a completely working implementation of Java.
Since DalvikVM runs classes that were converted from .class files it should be possible to convert the classes over. Then the "only" issue is when languages generate bytecode on the fly - for that it would require the extra step of converting the generated bytecode over to the DalvikVM format while the program is running on the DalvikVM.
Hmmm.... sort of a JITT (Just In Time Translator) that covertes class files to a DalvikVM files at runtime on the phone. I wonder how slow that would be.

Porting OpenJDK to Android platform is possible. There are effort like : Shark, Zero and caciocavallo that vastly ease the port process (= no ASM, simple AWT peer). Plus Android is nothing but a linux kernel behind. The only question is when will it be done by anybody ?
By the way, both iphones and android phones got Jazelle compatible processor, somebody with very strong processor hacking skills would be very welcome to add Jazelle support to OpenJDK.
Doing so, we could choose between : very light resource acceleration (Jazelle) and JIT ;-)
About iPhone, it is the same thing : a port is possible. Only Apple has put a section in the the iPhone license that clearly forbid VM usage. As per European law, to me, this license section is unlegal. Two reasons : You can not force/link buy of two of your product. Here I tune and Iphones are linked. You can not refuse to sell something that you can sell. Here as soon as a VM would be build for iPhone, if it is refused to be put on the iTune store, then this point will apply. Is there anybody that want to chalenge Apple licence legality on earth ? I don't think so, unhappy people will be flying to Android or any other platform.

In the meantime I have found a possible solution (only JavaME):
"MicroEmulator is a pure Java implementation of Java ME in Java SE."
Running Java ME applications on Android

technically it should be possible to interpret hotspot byte-code on dalvik vm or dalvik's byte-code on hotspot, but it will never be efficient (not mentioning elegant) design for a long run. the cost of doing that might become very high especially with respect to maintenance in the future evolution of such a split ecosystem.
i think, from the very beginning, dalvik vm is a matter of power/market control rather than innovative effort to improve java virtual machine ecosystem. dalvik vm and hotspot vm are lake two highway bridges across the same river build in parallel five meters from each other. it divides and brings confusion to java technological ecosystem.
google is, in my opinion, definitely the technological leader with innovative contributions over last decade that dwarf far more conservative oracle, but in this very subject they have shaken the java ecosystem in nearly destructive way. we (programmers) should strive for a single uniform solution to this problem. that is the main idea behind the concept of "virtual machine" anyway - it should not belong to neither google nor oracle.

try GNURoot app (proot ptrace container) with debian Wheezy;
apt-get update
apt-get install openjdk-7-jre
/usr/lib/jvm/java-7-openjdk-armel/jre/bin/java ...
(including long path)

I don't think the problem is technical. In theory you can migrate OpenJDK to the iPhone for example, but there are legal restriction in place.

See http://davy.preuveneers.be/phoneme/ for MIDP, Foundation and Personal Profile jvms for Android ARM apks. (Thank you Davy!!!)
I have repackaged the Foundation jvm for command line use and host it at vkfox.com/android/bin/foundation-jvm.bin for your pleasure. One could use the eclipse compiler in the JavaIDEdroid free app, or the old kopi or kopisusu compilers with this jvm, togeather with the stubbed cdc + foundation jar file from a J2ME jdk for an onboard development system. Using the features of TerminalIDE -- console and sun compiler -- with indicated ref jars would also get you there. This is essentially equivalent to a headless jdk1.4 with the possibility of MIDP or awt graphics.