or Connect
AppleInsider › Forums › Software › Mac OS X › Oracle releases first Java Development Kit and JavaFX SDK for Mac OS X
New Posts  All Forums:Forum Nav:

Oracle releases first Java Development Kit and JavaFX SDK for Mac OS X

post #1 of 25
Thread Starter 
One and a half years after Apple announced the depreciation of its edition of Java for the Mac platform, Oracle has announced the availability of its own Java Development Kit and JavaFX Software Development Kit for Mac users.

Back in October of 2010, Apple announced Java updates for OS X Leopard and Snow Leopard, but also noted that it would not continue to maintain its own runtime for Java.

Apple subsequently dropped Java from default installation in OS X Lion (below top), shifting its own development work on Java to the OpenJDK community. The company also changed how Java is installed on the Mac in order to facilitate the distribution of a third party Java runtime, which can be selected from OS X's Java Preferences (below bottom).

Mac OS X Lion Java

Mac OS X Lion Java

Mac OS X Lion Java


At the same time, Apple has made it clear that it doesn't see Java as contributing to consumer desktop Mac software, putting it alongside its own deprecated PowerPC Rosetta translator as being among the "deprecated or optionally installed technologies" that software can't make any use of if it is to be listed in the Mac App Store.

Oracle takes over Java for Mac

Oracle has worked with the OpenJDK community over the last year to complete the release of its own Java platform, ultimately releasing "Java Platform, Standard Edition 7 Update 4" (Java SE 7 Update 4) and JavaFX 2.1.

Oracle noted that the "OpenJDK Community continues to host the development of Java SE 7 on Mac OS X and JDK 8, the prototype reference implementation of Java SE 8. Oracle has also started the OpenJFX project as part of its plan to open source the JavaFX platform."

Apple's own version of Java only supported the earlier Java SE 6 specification. It also failed to incorporate the latest bug fixes and security changes Oracle had been releasing. This enabled malware writers to target the optional install of Java for Mac with attacks that targeted known exploits in the older software.

While Apple has since patched its own Java runtime, Oracle's newer release of its own Java runtime and tools will give developers an option they haven't had before. JavaFX 2.1 is now available for both Windows and Macs, with a developer preview available for Linux.

Hasan Rizvi, senior vice president of Oracle Fusion Middleware and Java Products, said in a press release, ?Oracle has aggressive plans for Java over the next few years and we are continuing to drive technical advancements across the platform. At JavaOne in 2011, we outlined our long-term roadmap for Java SE and JavaFX and we are working closely with the Java community to meet our development milestones.

"With the upcoming Mac OS X port, we look forward to delivering simultaneous releases of the JRE across all major operating systems later this year, so all Java users will be able to take advantage of the latest features and security fixes.?
post #2 of 25

Hmmm... what does this mean for the Google rip-off for the Android OS?
 

"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
post #3 of 25

The correct word is deprecation not depreciation.

post #4 of 25

 

Quote:
Originally Posted by timswearingen View Post

The correct word is deprecation not depreciation.

 


I thought the correct word was decaffeination.

"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
post #5 of 25

Works like a charm -- so far. The Oracle documentation for configuring Java for OS X and Eclipse Indigo is on the money. Nice to see perfection -- as far as I've gotten.

 

One note of some interest, at least to me. Apple's Java versions are placed in /System/Library subdirectories. Oracle's Java is placed in /Library subdirectories, as one would expect.

post #6 of 25
One of the great "bad" decisions was Googles choice to trash their relationship with Apple for in the end little profit, massive legal IP headaches, and causing Apple to attack Google core ad buiness. Oracle was lot more savy and will win the benefits. Samsung has also launched itself on a similar and unnecessary collision course.
post #7 of 25

Good.  Now OS X is finally a first class citizen in the Java world.  I can expect JDK 8 at the same time and Windows, Linux and Solaris users and don't have to deal with Apple dragging its feet, as it did when it shipped Leopard with only JDK 5 (6 was out).

 

This is excellent news all around.
 

post #8 of 25
I installed the JDK now how can I remove the Apple provided JRE? I don't want to just uncheck it but remove it completely.

iPod nano 5th Gen 8GB Orange, iPad 3rd Gen WiFi 32GB White
MacBook Pro 15" Core i7 2.66GHz 8GB RAM 120GB Intel 320M
Mac mini Core 2 Duo 2.4GHz 8GB RAM, iPhone 5 32GB Black

Reply

iPod nano 5th Gen 8GB Orange, iPad 3rd Gen WiFi 32GB White
MacBook Pro 15" Core i7 2.66GHz 8GB RAM 120GB Intel 320M
Mac mini Core 2 Duo 2.4GHz 8GB RAM, iPhone 5 32GB Black

Reply
post #9 of 25

 

Quote:
Originally Posted by JavaCowboy View Post

Good.  Now OS X is finally a first class citizen in the Java world.  I can expect JDK 8 at the same time and Windows, Linux and Solaris users and don't have to deal with Apple dragging its feet, as it did when it shipped Leopard with only JDK 5 (6 was out).

 

This is excellent news all around.
 

 

The Apple team just chose to wait until the main Java team worked out all of their bugs, *then* do their development. Otherwise, they would have to deal with all of the "oh, darn, we have to fix the base level code" throes of agony.

post #10 of 25

What then is the best time to switch to the Oracle distribution.

 

What is the best path to proceed? Keep previous versions around or remove them as /Library versions by Oracle are installed?

 

Why doesn't the article provide any links?

post #11 of 25

 

Quote:
Originally Posted by VanFruniken View Post

What then is the best time to switch to the Oracle distribution.

 

What is the best path to proceed? Keep previous versions around or remove them as /Library versions by Oracle are installed?

 

Why doesn't the article provide any links?

 

If you're a developer using Java, you don't want to remove older versions. It's short-sighted to develop applications that will only run on the latest incarnation of java so you must keep older versions around to test against. Your users and the servers you deploy to may are likely to (WILL) be running under any number of versions, as well and many versions of available java libraries (with their own Java version requirements), such as from Apache. You cannot ignore this.

post #12 of 25

 

Quote:
Originally Posted by waldobushman View Post

 

 

If you're a developer using Java, you don't want to remove older versions. It's short-sighted to develop applications that will only run on the latest incarnation of java so you must keep older versions around to test against. Your users and the servers you deploy to may are likely to (WILL) be running under any number of versions, as well and many versions of available java libraries (with their own Java version requirements), such as from Apache. You cannot ignore this.

 

Meh, this is why we have very crufty java code left around.  

 

If it's before Java 1.6 update 10 they can live without my app or download the version with the bundled JRE.  Actually Update 25 or something.

 

I'm not going to code against Java 1.4 because some folks wont update Java.  I'm not supporting 1.6 after 1.8 is released.  Strings in switches...going to use that

 

 

post #13 of 25
Quote:
Originally Posted by lukevaxhacker View Post

 

Quote:
Originally Posted by JavaCowboy View Post

Good.  Now OS X is finally a first class citizen in the Java world.  I can expect JDK 8 at the same time and Windows, Linux and Solaris users and don't have to deal with Apple dragging its feet, as it did when it shipped Leopard with only JDK 5 (6 was out).

 

This is excellent news all around.
 

 

The Apple team just chose to wait until the main Java team worked out all of their bugs, *then* do their development. Otherwise, they would have to deal with all of the "oh, darn, we have to fix the base level code" throes of agony.


It would have been better if Apple never was the only source of Java on OS X in the first place.
post #14 of 25

 

Quote:
Originally Posted by JavaCowboy View Post


It would have been better if Apple never was the only source of Java on OS X in the first place.

 

Apple raised the bar in terms of Java look and feel.  It's pretty much the only platform where the native LAF didn't look like ass.

post #15 of 25
Quote:
Originally Posted by nht View Post

 

Quote:
Originally Posted by JavaCowboy View Post


It would have been better if Apple never was the only source of Java on OS X in the first place.

 

Apple raised the bar in terms of Java look and feel.  It's pretty much the only platform where the native LAF didn't look like ass.


First of all, I'd rather have a look n feel that looks like ass than be months late on releases and security fixes.

Secondly, Nimbus does not look like ass.
post #16 of 25

 

Quote:
Originally Posted by nht View Post

 

 

Meh, this is why we have very crufty java code left around.  

 

If it's before Java 1.6 update 10 they can live without my app or download the version with the bundled JRE.  Actually Update 25 or something.

 

I'm not going to code against Java 1.4 because some folks wont update Java.  I'm not supporting 1.6 after 1.8 is released.  Strings in switches...going to use that

 

 

 

Lucky if you have that control and can afford to dis your customers.

 

If you support and maintain enterprise wide software at a vast enterprise with tens of thousands of users and tens of thousands computers, with IT support in the departments and subdepartments from expert to non-existent, and multiple applications from outside vendors whose applications require specific versions of java, and users who do not run at a security level that gives them the authority to install software, and have machines that are reimaged from servers upon boot-up, then you WILL support Java versions 1.4, 1.5, 1.6, 1.7. Congrats if you don't have to deal with these variations.

post #17 of 25

 

Quote:
Originally Posted by waldobushman View Post

 

 

Lucky if you have that control and can afford to dis your customers.

 

If you support and maintain enterprise wide software at a vast enterprise with tens of thousands of users and tens of thousands computers, with IT support in the departments and subdepartments from expert to non-existent, and multiple applications from outside vendors whose applications require specific versions of java, and users who do not run at a security level that gives them the authority to install software, and have machines that are reimaged from servers upon boot-up, then you WILL support Java versions 1.4, 1.5, 1.6, 1.7. Congrats if you don't have to deal with these variations.

 

The thing that kills me is your whole post is the poster child logic for why IT departments said they were standardizing -- so that they could tame the version-itis and keep up to date with current security issues.  Now you are saying these standardization and auto-deployment issues are why IT departments won't keep up to date. I have a hard time with that logic.

 

Fear isn't a good reason to stay in the past, and one of the prime motivators for the IT department to properly manage the upgrade cycle is when the CEO and CFO get wind of software sunsets due to obsolete IT infrastructure. The CIO gets a lot of pressure to actually manage the situation rather than let the staff manage the C-Level.

 

So yeah, devs can use pressure on the client to upgrade, especially when it can be shown that not upgrading infrastructure puts the company at risk that you as the dev will not be responsible for having your software being part of the problem.

.
Reply
.
Reply
post #18 of 25

 

Quote:
Originally Posted by JavaCowboy View Post


First of all, I'd rather have a look n feel that looks like ass than be months late on releases and security fixes.
Secondly, Nimbus does not look like ass.

 

First, it didn't seem that bad until the big time gap until 1.6.  Maybe it was and I just don't recall.   OSX is primarily a desktop OS so lacking 1.6 update 10 was annoying.

 

 

Second, Nimbus didn't exist until 1.6 update 10.  And in comparison to OSX native LAF it does look like ass.  A vast improvement over metal but still nothing to write home about as a desktop app developer.  Arguably Substance is better and I believe no contest between the Seaglass LAF and Nimbus.

 

But if you're a desktop Java app developer you're kinda screwed at this point.  Most of the good UI folks now work for either Google or Apple and not Oracle.

 


Edited by nht - 4/29/12 at 9:02pm
post #19 of 25

 

Quote:
Originally Posted by waldobushman View Post

 

 

Lucky if you have that control and can afford to dis your customers.

 

If you support and maintain enterprise wide software at a vast enterprise with tens of thousands of users and tens of thousands computers, with IT support in the departments and subdepartments from expert to non-existent, and multiple applications from outside vendors whose applications require specific versions of java, and users who do not run at a security level that gives them the authority to install software, and have machines that are reimaged from servers upon boot-up, then you WILL support Java versions 1.4, 1.5, 1.6, 1.7. Congrats if you don't have to deal with these variations.

 

Bullshit.

 

First J2SE 1.5 is EOL'd.  1.4 more so.

 

Second if you're deploying to a vast enterprise with tens of thousands of users and tens of thousands of computers you aren't likely deploying to bare J2EE but to WebSphere or JBoss or similar.

 

For you to NEED to support J2SE 1.4/J2EE 1.4 you're deploying to a site still running Websphere 6.0 (or JBoss/etc equivalent) that was first released in 2004 (nearly a decade ago) and EOL'd nearly TWO years ago in Sept 2010.

 

For you to NEED to support J2SE 1.5/J2EE 1.4 you're deploying to a site still running Websphere 6.1 that was first released in 2006 and which will be EOL'd this year in September.

 

For reference, the current version is 8.5 supporting J2EE 6 and J2SE 7.  

 

Most folks still stuck on older versions should either already be on WebSphere 7 or madly moving to 8.0 before the end of the FY.  Any site with thousands of servers are complete idiots for not moving to 7 as soon as they could for the vastly improved admin tools over 6.1.  Probably by around the late-2010 time frame, certainly by the time 8.0 rolled out in 2011.

 

Third if you're deploying a desktop app in an environment where users have no admin privs you damn well better bundle a JRE with your application or you WILL have breakage (except for OSX).  You can install to the users home directory or desktop with no problems.  Which you would know if you were a desktop java developer who HAS deployed to lots of different desktops.  

 

If you are deploying to OSX you have a very good idea which JRE is running on your target machines based on the OSX version dominating your user base.  Most users are fortunately now on Leopard or Snow Leopard so targeting 1.6 is very safe today.

 

Fourth if you're deploying a desktop app where they reimage the drive every boot-up then your app AND your desired JRE will be on the server image wont it? So this point is stupid.  And nobody who is locking the machine down like this is going to tolerate the massive amounts of security problems not addressed in J2SE 1.4 or 1.5...which if you recall, has been EOL'd for the past 4 years. 

 

FINALLY to use the scenario where you're supporting tens of thousands of users on tens of thousands of computers is so much an edge case to support your assertion that every java developer had better support Java 1.4, which has been EOL'd since 2006 (or 2008 if you had a specific support contract) completely mental.  Damn few java devs, even those who do enterprise server development, don't support "tens of thousands" of users on "tens of thousands of computers".  

 

Those that DO largely work for IBM, Oracle and Red Hat and don't need your advice.  They've quite sanely EOL'd those 1.4 products two years ago.

 

Perhaps the DoD but that's a completely different can of worms but I'm pretty damn sure that those guys are not running Websphere 6.0 or a JBoss needing 1.4.  Not in an enterprise scenario.

 

Any enterprise still running an older application server chock full of Java security holes is going to get pwned.  It's not if, just when.

 

If you are stuck supporting J2SE 1.4 then it sucks to be you.  You need a new job.

 

Your advice was for OSX Java developers to support J2SE 1.4 is especially asinine.  It's been disabled since Leopard 10.5.6.  And J2SE 5 is not installed on Snow Leopard.

post #20 of 25

 

Quote:
Originally Posted by VanFruniken View Post

What then is the best time to switch to the Oracle distribution.

 

What is the best path to proceed? Keep previous versions around or remove them as /Library versions by Oracle are installed?

 

Why doesn't the article provide any links?

 

I wouldn't delete 6 until Mountain Lion is the dominant OSX version.  Most folks will be running Apple's J2SE 6 version until that point.  When you see Snow Leopard drop to 10% if your installed base you can safely delete 1.6.  By then you can guess most Lion users are on Oracle's 1.7.

 

Still, I would expect to see Apple transitioning people to Oracle's OSX compatible version of J2SE 7 as painlessly and as quickly as possible.  You might be able to do it sooner.

post #21 of 25

 

Quote:
Originally Posted by Hiro View Post

...

 

Fear isn't a good reason to stay in the past, ...

 

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.

 

And BTW, it is not just enterprise applications. Many double-clickable MacOS X applications are Java-based. These include the Microsoft Live Messenger client, [b]Mercury Messenger[/b], and every torrent client that I know.

post #22 of 25

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.

post #23 of 25

 

Quote:
Originally Posted by Mr. Me View Post

 

 

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.

 

And BTW, it is not just enterprise applications. Many double-clickable MacOS X applications are Java-based. These include the Microsoft Live Messenger client, [b]Mercury Messenger[/b], and every torrent client that I know.

 

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.

 

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.

.
Reply
.
Reply
post #24 of 25

 

Quote:
Originally Posted by bloodycelt View Post

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.

post #25 of 25

 

Quote:
Originally Posted by Mr. Me View Post

 

 

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.

 

And BTW, it is not just enterprise applications. Many double-clickable MacOS X applications are Java-based. These include the Microsoft Live Messenger client, [b]Mercury Messenger[/b], and every torrent client that I know.

 

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.

 

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.

 

Advocating supporting J2SE 1.4 is advocating that OSX developers must support Tiger or they will be sorry they didn't. 

New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac OS X
AppleInsider › Forums › Software › Mac OS X › Oracle releases first Java Development Kit and JavaFX SDK for Mac OS X