For what its worth, while my company does not use Java 1.4 AFAIK. However many of our internal servers are duct-taped with perl 4, running red hat 4 or 3, apache 1, and if they did run java... probably something old. Given that the staff that built it is no longer with us... we just maintain it. Not enough bandwidth to upgrade since it would mean at this point rewriting large chunks of perl scripts.
And every company I have been at big and small generally follows a simple premise: if it aint broke, don't upgrade it. The only time I've seen a company keep their software on a supported up-to-date platform is if it contains data that falls under a regulation that needs to have the security patches.
As for a users system, there are still people running windows 2000, since many of them just need office, and have their outside internet blocked... there is little need with upgrading the OS.
<p>
</p>
<div class="quote-container">
<span>Quote:</span>
<div class="quote-block">
Originally Posted by <strong>Mr. Me</strong> <a href="/t/149675/oracle-releases-first-java-development-kit-and-javafx-sdk-for-mac-os-x#post_2102830"><img alt="View Post" class="inlineimg" src="/img/forum/go_quote.gif" /></a><br />
<br />
<p>
</p>
<p>
</p>
<p>
Fear might not be a good reason, but there are others. Upgrading to the latest and greatest software may have many benefits. However, it also has downsides. There was a design decision in Java development to make the various versions not backward-compatible. This means that each Java-based application require a single version of the JVM and is incompatible with newer versions. Updating an application to a new JVM is neither cost-free nor is it instantaneous.</p>
<p>
</p>
<p>
And BTW, it is not just enterprise applications. Many double-clickable MacOS X applications are Java-based. These include the Microsoft Live Messenger client, Mercury Messenger, and every torrent client that I know.</p>
</div>
</div>
<p>
</p>
<p>
The thread points I was responding to were not related to supporting bleeding edge JVMs or JREs. The guy was espousing the need to support back as far as Java 1.4 or devs must not be dealing with real clients and must be lucky. If you are a dev and looking at that, you need to do your damndest to get the environment made sane or just walk. Deploying to that kind of ancient and insecure infrastructure only makes you part of the liability suit once the installation is hacked.</p>
<p>
</p>
<p>
nht also said it more succinctly, but what you deploy doesn't have to depend on what the default JVM install is. You just need to be willing to pay the bandwidth/size costs to include your target JRE in the app bundle.</p>
For what its worth, while my company does not use Java 1.4 AFAIK. However many of our internal servers are duct-taped with perl 4, running red hat 4 or 3, apache 1, and if they did run java... probably something old. Given that the staff that built it is no longer with us... we just maintain it. Not enough bandwidth to upgrade since it would mean at this point rewriting large chunks of perl scripts.
And every company I have been at big and small generally follows a simple premise: if it aint broke, don't upgrade it. The only time I've seen a company keep their software on a supported up-to-date platform is if it contains data that falls under a regulation that needs to have the security patches.
As for a users system, there are still people running windows 2000, since many of them just need office, and have their outside internet blocked... there is little need with upgrading the OS.
This is true but I found folks typically left legacy systems alone and not tried to add newer things on top exactly because of the fact no one was quite sure how it worked anymore and no one could be expected to fix it except at great cost if it got broken. I would guess most sites would deploy new services on their current version of Solaris, RHEL or Windows Server and leave those legacy systems the heck alone. Or attempt to gingerly move them to their own dedicated VM to consolidate or replace hardware.
The issue with having users run old versions of windows, even without internet access, is that once inside the firewall the bad guys have an instant source of data and machines for use as a botnet. If those 2K machines are hitting domain services they can probably pick up some user credentials along the way fairly easily. Without going into details a client of a former company once found someone had broken into their enterprise, setup a bot net and exfiltrated quite a bit of financial and business data. We found out because they suddenly cut access to everyone including us working on a project for them. Access was down for weeks as they scrubbed systems, updated old users, blah blah.
Penny wise and pound foolish. I dunno what 2-3 weeks of massive disruption cost them but it was probably more than upgrading. On the other hand I think they sell insurance for that so maybe from a pure cost perspective it is worth it.
<p>
</p>
<div class="quote-container">
<span>Quote:</span>
<div class="quote-block">
Originally Posted by <strong>Mr. Me</strong> <a href="/t/149675/oracle-releases-first-java-development-kit-and-javafx-sdk-for-mac-os-x#post_2102830"><img alt="View Post" class="inlineimg" src="/img/forum/go_quote.gif" /></a><br />
<br />
<p>
</p>
<p>
</p>
<p>
Fear might not be a good reason, but there are others. Upgrading to the latest and greatest software may have many benefits. However, it also has downsides. There was a design decision in Java development to make the various versions not backward-compatible. This means that each Java-based application require a single version of the JVM and is incompatible with newer versions. Updating an application to a new JVM is neither cost-free nor is it instantaneous.</p>
<p>
</p>
<p>
And BTW, it is not just enterprise applications. Many double-clickable MacOS X applications are Java-based. These include the Microsoft Live Messenger client, Mercury Messenger, and every torrent client that I know.</p>
</div>
</div>
<p>
</p>
<p>
Yah, but here you have the opposite issue. You need to update to make sure the current Apple JRE is supported. As I noted 1.4 has been gone for a while and 1.5 no longer loaded on SL. Mostly though, older Java apps still work even if certain things are marked deprecated. I've never bundled a JRE for an OSX target but do for Windows. It's is, like Hiro mentioned, a fairly large size hit.</p>
<p>
</p>
<p>
It is a shame that you cannot use Java to write for the App Store. Maybe I'll move to MonoMac for my next project. They can bundle a mono app with all the pieces for submission to Apple. I seriously wish Oracle would get on the ball and make the arrangements required to do what a dinkly little company like Xamarin has managed to do with MonoMac, MonoTouch and MonoDroid.</p>
<p>
</p>
<p>
Advocating supporting J2SE 1.4 is advocating that OSX developers must support Tiger or they will be sorry they didn't. </p>
Comments
For what its worth, while my company does not use Java 1.4 AFAIK. However many of our internal servers are duct-taped with perl 4, running red hat 4 or 3, apache 1, and if they did run java... probably something old. Given that the staff that built it is no longer with us... we just maintain it. Not enough bandwidth to upgrade since it would mean at this point rewriting large chunks of perl scripts.
And every company I have been at big and small generally follows a simple premise: if it aint broke, don't upgrade it. The only time I've seen a company keep their software on a supported up-to-date platform is if it contains data that falls under a regulation that needs to have the security patches.
As for a users system, there are still people running windows 2000, since many of them just need office, and have their outside internet blocked... there is little need with upgrading the OS.
</p>
<div class="quote-container">
<span>Quote:</span>
<div class="quote-block">
Originally Posted by <strong>Mr. Me</strong> <a href="/t/149675/oracle-releases-first-java-development-kit-and-javafx-sdk-for-mac-os-x#post_2102830"><img alt="View Post" class="inlineimg" src="/img/forum/go_quote.gif" /></a><br />
<br />
<p>
</p>
<p>
</p>
<p>
Fear might not be a good reason, but there are others. Upgrading to the latest and greatest software may have many benefits. However, it also has downsides. There was a design decision in Java development to make the various versions not backward-compatible. This means that each Java-based application require a single version of the JVM and is incompatible with newer versions. Updating an application to a new JVM is neither cost-free nor is it instantaneous.</p>
<p>
</p>
<p>
And BTW, it is not just enterprise applications. Many double-clickable MacOS X applications are Java-based. These include the Microsoft Live Messenger client, Mercury Messenger, and every torrent client that I know.</p>
</div>
</div>
<p>
</p>
<p>
The thread points I was responding to were not related to supporting bleeding edge JVMs or JREs. The guy was espousing the need to support back as far as Java 1.4 or devs must not be dealing with real clients and must be lucky. If you are a dev and looking at that, you need to do your damndest to get the environment made sane or just walk. Deploying to that kind of ancient and insecure infrastructure only makes you part of the liability suit once the installation is hacked.</p>
<p>
</p>
<p>
nht also said it more succinctly, but what you deploy doesn't have to depend on what the default JVM install is. You just need to be willing to pay the bandwidth/size costs to include your target JRE in the app bundle.</p>
Quote:
Originally Posted by bloodycelt
For what its worth, while my company does not use Java 1.4 AFAIK. However many of our internal servers are duct-taped with perl 4, running red hat 4 or 3, apache 1, and if they did run java... probably something old. Given that the staff that built it is no longer with us... we just maintain it. Not enough bandwidth to upgrade since it would mean at this point rewriting large chunks of perl scripts.
And every company I have been at big and small generally follows a simple premise: if it aint broke, don't upgrade it. The only time I've seen a company keep their software on a supported up-to-date platform is if it contains data that falls under a regulation that needs to have the security patches.
As for a users system, there are still people running windows 2000, since many of them just need office, and have their outside internet blocked... there is little need with upgrading the OS.
This is true but I found folks typically left legacy systems alone and not tried to add newer things on top exactly because of the fact no one was quite sure how it worked anymore and no one could be expected to fix it except at great cost if it got broken. I would guess most sites would deploy new services on their current version of Solaris, RHEL or Windows Server and leave those legacy systems the heck alone. Or attempt to gingerly move them to their own dedicated VM to consolidate or replace hardware.
The issue with having users run old versions of windows, even without internet access, is that once inside the firewall the bad guys have an instant source of data and machines for use as a botnet. If those 2K machines are hitting domain services they can probably pick up some user credentials along the way fairly easily. Without going into details a client of a former company once found someone had broken into their enterprise, setup a bot net and exfiltrated quite a bit of financial and business data. We found out because they suddenly cut access to everyone including us working on a project for them. Access was down for weeks as they scrubbed systems, updated old users, blah blah.
Penny wise and pound foolish. I dunno what 2-3 weeks of massive disruption cost them but it was probably more than upgrading. On the other hand I think they sell insurance for that so maybe from a pure cost perspective it is worth it.
</p>
<div class="quote-container">
<span>Quote:</span>
<div class="quote-block">
Originally Posted by <strong>Mr. Me</strong> <a href="/t/149675/oracle-releases-first-java-development-kit-and-javafx-sdk-for-mac-os-x#post_2102830"><img alt="View Post" class="inlineimg" src="/img/forum/go_quote.gif" /></a><br />
<br />
<p>
</p>
<p>
</p>
<p>
Fear might not be a good reason, but there are others. Upgrading to the latest and greatest software may have many benefits. However, it also has downsides. There was a design decision in Java development to make the various versions not backward-compatible. This means that each Java-based application require a single version of the JVM and is incompatible with newer versions. Updating an application to a new JVM is neither cost-free nor is it instantaneous.</p>
<p>
</p>
<p>
And BTW, it is not just enterprise applications. Many double-clickable MacOS X applications are Java-based. These include the Microsoft Live Messenger client, Mercury Messenger, and every torrent client that I know.</p>
</div>
</div>
<p>
</p>
<p>
Yah, but here you have the opposite issue. You need to update to make sure the current Apple JRE is supported. As I noted 1.4 has been gone for a while and 1.5 no longer loaded on SL. Mostly though, older Java apps still work even if certain things are marked deprecated. I've never bundled a JRE for an OSX target but do for Windows. It's is, like Hiro mentioned, a fairly large size hit.</p>
<p>
</p>
<p>
It is a shame that you cannot use Java to write for the App Store. Maybe I'll move to MonoMac for my next project. They can bundle a mono app with all the pieces for submission to Apple. I seriously wish Oracle would get on the ball and make the arrangements required to do what a dinkly little company like Xamarin has managed to do with MonoMac, MonoTouch and MonoDroid.</p>
<p>
</p>
<p>
Advocating supporting J2SE 1.4 is advocating that OSX developers must support Tiger or they will be sorry they didn't. </p>