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

Posted:
in macOS edited January 2014
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.?
«1

Comments

  • Reply 1 of 24


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

     

  • Reply 2 of 24


    The correct word is deprecation not depreciation.

  • Reply 3 of 24


     


    Quote:

    Originally Posted by timswearingen View Post


    The correct word is deprecation not depreciation.



     




    I thought the correct word was decaffeination.

  • Reply 4 of 24


    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.

  • Reply 5 of 24
    gprovidagprovida Posts: 252member
    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.
  • Reply 6 of 24


    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.

     

  • Reply 7 of 24
    aizmovaizmov Posts: 989member
    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.
  • Reply 8 of 24


     


    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.

  • Reply 9 of 24


    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?

  • Reply 10 of 24


     


    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.

  • Reply 11 of 24
    nhtnht Posts: 4,522member


     


    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


     


     

  • Reply 12 of 24
    <p>  </p><div class="quote-container"> <span>Quote:</span> <div class="quote-block"> Originally Posted by <strong>JavaCowboy</strong> <a href="/t/149675/oracle-releases-first-java-development-kit-and-javafx-sdk-for-mac-os-x#post_2102262"><img alt="View Post" class="inlineimg" src="/img/forum/go_quote.gif" /></a><br /> <br /> <p> 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).</p> <p>  </p> <p> This is excellent news all around.<br />  </p> </div></div><p>  </p><p> 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.</p>

    It would have been better if Apple never was the only source of Java on OS X in the first place.
  • Reply 13 of 24
    nhtnht Posts: 4,522member


     


    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.

  • Reply 14 of 24
    nht wrote: »
    <p>  </p><div class="quote-container"> <span>Quote:</span> <div class="quote-block"> Originally Posted by <strong>JavaCowboy</strong> <a href="/t/149675/oracle-releases-first-java-development-kit-and-javafx-sdk-for-mac-os-x#post_2102572"><img alt="View Post" class="inlineimg" src="/img/forum/go_quote.gif" /></a><br /> <br /> <br /> It would have been better if Apple never was the only source of Java on OS X in the first place.</div></div><p>  </p><p> 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.</p>

    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.
  • Reply 15 of 24


     


    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.

  • Reply 16 of 24
    hirohiro Posts: 2,663member


     


    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 17 of 24
    nhtnht Posts: 4,522member


     


    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.


     

  • Reply 18 of 24
    nhtnht Posts: 4,522member


     


    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.

  • Reply 19 of 24
    nhtnht Posts: 4,522member


     


    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.

  • Reply 20 of 24
    mr. memr. me Posts: 3,221member
    <p>
     </p>
    <div class="quote-container">
    <span>Quote:</span>
    <div class="quote-block">
    Originally Posted by <strong>Hiro</strong> <a href="/t/149675/oracle-releases-first-java-development-kit-and-javafx-sdk-for-mac-os-x#post_2102801"><img alt="View Post" class="inlineimg" src="/img/forum/go_quote.gif" /></a><br />
    <br />
    <p>
    ...</p>
    <p>
     </p>
    <p>
    Fear isn't a good reason to stay in the past, ...</p>
    </div>
    </div>
    <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>
Sign In or Register to comment.