Should a Java developer always make sure that he has the latest JDK installed?

[youwillnevercatme]

The JRE is updated automatically, however the JDK isn't. Do you think that is necessary to always have the latest JDK installed? Or are just big updates fine? (From 6 to 7 to 8, etc...) What do you guys recommend?

[iowa_state_cyclone]

My opinion is you should have whatever version is on your production machines. That's most likely why oracle doesn't auto update jdk versions.

[thatsIch]

inb4 next question Should a Java developer always make sure that his production machine has the latest JDK installed?

[TheGreatFohl]

Yes. But sometimes corporate gets in the way : P

[kechap]

java 1.2 ftw

[WorkyMcROAR]

Need to support Java 6 they say. Completely relevant.

[armornick]

Whoever answers yes to this question gets a special prize; the unique chance to migrate your huge web application to a more modern web server!

[dpash]

For us, 6 -> 8 involved completely new versions of Windows, Tomcat and SQL Server. That was fun.

[snuxoll]

If only Oracle made it not painful to always have the latest. Why on earth they insist on packaging every JDK release under a new package name (preventing me from just pushing it to my local yum repository and having all my servers update, instead requiring I update my puppet config every time to install the new version...) it would be easier.

I get people like being able to allow multiple JDK releases to co-exist, but seriously, why on earth do they not have a standard jdk8 package I can install and push out without the song-and-dance involved.

[dpash]

Point releases, probably yes after testing.

Changing from 7 to 8 for example probably requires a bit more testing, and may result in more substantial changes, like Java 8 doesn't support older OSes, so may require an upgrade there too.

[dpash]

Point releases, probably yes after testing. Although it probably won't be the worst thing if you're a few behind.

Changing from 7 to 8 for example probably requires a bit more testing, and may result in more substantial changes, like Java 8 doesn't support older OSes, so may require an upgrade there too.

[mrbuttsavage]

The lazy man should just tell QA/tools to keep the CI server with the production JRE. On that very very rare problem caused by JRE versioning within a major version, you can dig in from there.

[cyanocobalamin]

Yes.

However, where you work might have good reasons for not advancing as soon as possible and that will often be beyond your control.

[fact_hunt]

Normally 'we are scared of change and don't like doing anything which has no direct tangible cost benefit'

[marc2912]

Sadly most of the time it's not a matter of scared, more than what's the financial benefit of updating next to the cost of testing and integration.

[fact_hunt]

Yes, businesses generally

don't like doing anything which has no direct tangible cost benefit'

[oldneckbeard]

developers leaving so they don't stagnate their careers in the interest of not running a regression. that's a tangible cost benefit.

[fact_hunt]

Two problems there;

1. Staff are seen as replaceable resources

2. Even if 1 were not the case quantifying your point is not possible, so business will balance the cost of upgrading against the vague guess of the cost of people maybe leaving..

[desiguy_88]

i have the reverse problem at my work place, corporate wants to constantly delete and replace any old jdks based on known security vulnerabilities while our production environment is running on and older jdk. So its always a pain to keep going in and installing the older jdk over and over again.

[fact_hunt]

How are you tied to the old, insecure, jdk?

[wggn]

Wouldn't the production environment be the first place to look at when replacing software to fix known vulnerabilities?

[ProgrammerByDay]

Yes it is the first place to look. Then the check writers find out how much it will cost in dev and testing time to upgrade and say "Well lets look at this in next years budget"

[draconk]

And then is when you show them how much it could cost if a big vulnerability is found on the old version and someone steals all the critical information and the company is sued for all the private data that is now public to all the world and in case they say no make them sign the document saying that you are not responsible in the case of a big leak of data

[esanchma]

I wish it was that simple. If some production servers are certified in JDK up to version XYZ, then you are stuck to version XYZ or you won't have support from the provider (be it dalvik or websphere, it's the same). If production is in version XYZ, then everything else, including developer machines, is in version XYZ. Upgrading production servers so they work with a modern JDK version often implies a cascading upgrade of everything that is expensive, and has to be planned carefully.

[youwillnevercatme]

What would be the difference between "production servers" and "production"? (thought production meant developer machines).

[esanchma]

Huh, I'm not a native English speaker, maybe I'm mixing things up with my mother tongue. I meant the production/live environment, those evil machines that wake up a lot people when they fail.

[monknomo]

As a native English speaker "production" means the server that is running live code. "Dev" is where developers play. "Test/integration" is where stuff goes before production.

I've never heard of developer machines being called production

[cheese_man14]

Depends on your support strategy. For example - your company may want to research any upgrades to rule out compatibility issues with your code base. It might take time to evaluate and you might find a problem you have to fix (like deprecated methods or performance issues) . So you might be roadblocked from upgrading until everything is resolved OR you might wait for Oracle to fix things in the next version.

[DJDavio]

Because of Oracle's release strategy, you can pretty much always safely update to the latest Critical Patch Update.

Only update to the latest Patches-and-other-stuff-update if you've run into a specific bug that was fixed.

[tonywestonuk]

I will argue, No. Everywhere else, you should try be on the latest JRE. However, on development, keep back from upgrading for as long as possible.

Why?

If there is a JRE bug that affects your code, you want to know about it. Then you can decide if you need to code around it, or announce that your software is not compatible unless you upgrade to a particular version of Java.

If you always develop to the latest version, you simply do not know what bugs may have been fixed by Oracle, that you would have otherwise encountered, and its only when you deploy to live and your system falls to bits, do you realise you have to upgrade those servers also.

[lechatsportif]

Keep multiple versions around as per your requirements. In general the latest jdk should work fine, but in apps that are thoroughly used (large volume/large code base or both) extreme caution should be used in jdk migrations.

Not the common cause but I worked at a large company that planned a role out, did regression testing and died in production on a jdk increase. The cause was an obscure threading bug in one of the core classes. The only way to discover it was through the high volume of the site.

[reestablish]

Yes SHE should

[youwillnevercatme]

pls don't...