Skip to main content

The Deprecation

Posted by joshy on November 3, 2010 at 5:01 PM PDT

The Deprecation

If you're reading this blog then there's a good chance you've heard Apple has deprecated their implementation of Java on the Mac. Contrary to the resulting outrage over the last few days, I don't find change to be a shocking surprise.

Ultimately Apple puts in the technology that will let them sell more computers. As a consumer company they support technology that runs consumer apps. The desktop Java community simply hasn't created the thousands of consumer apps that exist on the Mac or the iPhone. these are almost entirely Cocoa or straight C+ OpenGL apps.

We are to blame

I challenge you to come up with even a list of 100 consumer apps written in Java. Without significant desktop Java apps Apple simply has no incentive to continue funding their Java port. The truth is, desktop Java has been dying for years, and Apple has finally accepted it. And I say this as someone who's worked on desktop Java for nearly my entire professional career. Desktop Java is dying, and it is our fault.

There are a variety of reasons for Java's failure on the desktop; reasons ranging from Sun to IBM to Swing to Deployment bugs and many other causes. I won't rehash them here because the end result is the same: no significant consumer desktop Java apps after nearly 15 years. Apple simply made a pragmatic decision to no longer support a technology that costs them more than it brings in. No Steve Jobs conspiracy theories required.

Apple's Goals

Apple's message to developers is very simple: use web technologies or use Obj-C/Cocoa. That's how it is on the iPhone, iPad, and now on the Mac. While they will probably never bar you from installing your own JRE, by default the Mac is set up to run Cocoa and the web really really well, with nothing else needed. That's Apple's decision for their computers and all of our ranting won't change that. Honestly I'm surprised it didn't happen sooner.

Desktop Java has to earn it's place on the desktop. It's always been the case that a JRE may not be on a PC. Now there is the potential that this may be the case on Mac OS X (perhaps as soon as next summer). If we want this fixed, then we need to do it ourselves, as a community.

Where do we go from here?

If desktop Java is going to be relevant then we have to start making great desktop apps. We shouldn't look to Oracle, IBM, or Apple to make this happen. They've been supporting us for years with little direct revenue to show for it (the toolbar deal was the only thing that ever brought in money for desktop development). If we want desktop Java to be around for another 15 years, then it's up to the community to make it happen. Nut up or shut up!

My personal contribution to fixing desktop Java is by creating an new UI toolkit and graphics stack which drops the Swing/AWT legacy. This new toolkit, called Amino, has a modern fluent API, CSS style-able components, and is fully redistributable with a liberal license (BSD). When I first designed Amino I assumed we might one day be without a default JRE on Mac, so I built it to work with multiple backends. It should be possible to replace AWT with standard OpenGL or SDL without too much work. In theory it should be possible to run an Amino app on SoyLatte without too much work.

Making desktop Java relevant again is very possible but it's up to us, the desktop Java loving community, to make this happen. I'm looking for some volunteers to help me make direct OpenGL & SDL work on SoyLatte without X11. With that done it will be possible to bundle apps with a JRE. Never again will we have to depend on anyone else's software installation to make our apps work. They are our apps, so it's up to us to make them work. Without a community developing such technology, then desktop Java is truly dead.

Related Topics >>

Comments

And what about all the

And what about existing desktop applications?
Proposing a new API is interesting but what about all the Java desktop applications that already exist?
We're so close of a full JRE under Mac OS X with OpenJDK / Soylatte. The only remaining task is to port AWT and JavaSound, and this can be achieved by the community.
If software editors want it to happen now, they just have to support the JKoala project I launch ten days ago.

I don't disagree with

I don't disagree with anything Josh has posted here. In my 8 years working on Java at Apple I think we hit a high-water-mark of about 20 standalone, double-clickable applications that we regularly tested against for compatibility. The reality was that most Java applications were developer tools, Java IDEs, specialized/vertical market tools, or graphically intensive but not very useful Java applets. Encyclopedia Britannica, MoneyDance, and SPSS were probably the only Java-based applications that you could go into a store and buy. Now, granted, far more code is delivered via download these days, but even when that wasn't the case, there just weren't all that many consumer-oriented Java applications.

One thing we are missing here is that if your standard of success or failure is personal productivity, games, or iOS type apps, then yes, Java on the desktop has failed. By that definition, python or Ruby + Cocoa on the Mac is a failure too, but I don't see waves of commentary about how horribly Apple has treated its python and Ruby developers. There are far more Java desktop apps being deployed in companies to run their business than there are apps trying to be the next iLife suite, and there's nothing wrong with that.

Personally, I had a feeling this day was coming when OpenJDK was first announced. If you can get the code for free, why should you continue to pay Sun/Oracle for the privilege of doing the work for them and not get a lot in return for your efforts? While I can't give exact dollar amounts, I strongly suspect that the number of developers that bought a MacBook Pro for the purpose of developing Java in the past 3 years does not make up for the money Apple gives to Sun/Oracle to be a licensee, let alone pay for the salary and benefits of a team of 10 developers, QA, and product engineers. Even if iOS never came along and gave Apple something to truly base their phenomenal growth upon, I think this would have happened anyway.

Having said all of that, here's one thing to keep in mind when people say Apple doesn't care about Java anymore. If Apple truly hated Java they would have completely deleted the JVM and would not allow the possibility of third-party JVMs to be installed, which is one of the main features added in the most recent Java update. Instead, because Apple is a Java licensee, we should expect to see security-based updates to Java 5 on 10.5 for at least another year and Java 6 on 10.6 until Mac OS X 10.8 is released, which will likely happen in two years, based on Apple's current OS release cycles. That gives the Java community approximately two years to get Java 7 built and potentially write a new, open AWT. The SWT Cocoa port demonstrates that it is possible to write a UI toolkit in Java without the use of private interfaces, but it also took 5 engineers that really knew SWT at the implementation level to get it to happen. Josh is a smart guy but there's more to an AWT than what is drawn in a window.

I have to disagree with final

I have to disagree with final part of your post actually. Most of my developer life is devoted to SWT/JFace apps based on Eclipse RCP platform. To the moment it is mature/stable and broadly used by mutliple application vendors in the world.
Eclipse Market place RCP applications catalog consists from 99 RCP applications currently (http://marketplace.eclipse.org/taxonomy/term/33) and I may easily add a lot of apps that are not listed there.

Unfortunately most of this apps are did not known far beside their primary auditory.

So actually the problem is not in the amount of apps, but in general problems facing desktop application development (development focus is far from rich client actually, so most of new desktop apps are highly specialized and did not become widely known).

So I beleive that overall problem is not in bad Java/SWT/Swing development expirience and not from lack of consumer development in java, but in the fact that desktop development is stalled.

According to go from there: my personal opinion is that creation of new toolkits is a fun but useless. Overally problem is not in complexity of GUI development and even not in stlying of controls or cool openGL effects(all this is doable with existing frameworks). But in the lack of great really popular consumer apps. So I would prefer to invest time in popularizing java by building new generation of java apps for consumers.

Regards,
Pavel

Hi Josh,Java can't be dead

Hi Josh,

Java can't be dead on the desktop because it never really took off on the desktop. We can list the reasons why but that isn't important. No body bought Mac's to do desktop development on them. However, we do use a few desktop clients (IDE) and we do write a lot of server code with them.

So here is the rub, Apple might have spent a wee bit of money porting Java to Mac OSX but they gained a lot more than that by attracting developers to the platform. It is these same developers that have created a boat load of iOS apps that Apple is now benefiting from. If Java is important to these developer, they will drift away. Certainly there are a lot of corporate accounts that will now be canceled.

I've been waiting for Apple to return to their ways that almost sunk the company and now they've gone and done it. To top it all off, they've just told me they don't care about what I'm doing so now they don't deserve any more of my money.

Since you're basically

Since you're basically rebuilding the GUI components, I wonder if this might be an opportunity to separate the GUI elements themselves from the way in which they're rendered? Imagine for moment that you could write an app in Amino and deploy it to a server. The server would render the UI, much in the way that GWT is rendered. If you deploy it to a desktop, the desktop context renders it using Amino's desktop widgets. The idea is to make the UI context aware and let the context figure out how to render the UI and deal with actions.

I considered going down this

I considered going down this route, but I decided to make Amino desktop only. There are more than enough web toolkits out there already. For a server/client proxy like you are describing I recommend using GWT. It's quite good.

The Deprecation

I have to disagree with this.

I cite without comment all the long list of applications which appeared on a monthly basis in SwingSightings.

+1 for your problem analysis;

+1 for your problem analysis; no sure though about the solution. As much as I know and admire your work in Java desktop, do you consider this kind of plan realistic (Amino)? Creating a full-blown UI/RIA toolkit is a massive effort, something that will take long years even if you attract many contributors. As soon as you have a decent feature set, next challenges are top performance, high-quality ports for several platforms, tooling (plugins for IDEs and illustration packages), non-PC platforms (mobile / TV / whatever), etc. We just don't have this kind of time; one of the big criticisms to JavaFX was that it's "too late" (because iOS, Flash or something else "already won the batte"), so why should we bet in another project that's still in early-pre-alpha phase? Instead of those already somewhat mature, like JavaFX, Apache Pivot, or even Eclipse's SWT/RCP/RAP.

I considered JavaFX's

I considered JavaFX's successes and failures when I designed Amino.  Creating a new toolkit isn't very difficult if you make the following choices:

  • desktop only, no tablets or smartphones
  • don't try to create all components at first (no rich text or treetables)
  • throw away Look and Feels
  • adopt existing designs for skinning (CSS) and layout (CSS 3 flex box model)
  • build on existing graphics backends
  • reuse existing libraries whenever possible

Amino's philosophy is not to reinvent the wheel, but simply re-implement it. Everything done in Amino so far has been one programmer working for just a few months.

 

"Everything done in Amino so

"Everything done in Amino so far has been one programmer working for just a few months."
Well, it shows. Lots of things just don't work properly and IMO it's pretty ugly anyway. It's pretty easy to throw together a tech demo in a couple of weeks when you already have the graphics library already completely done.
Creating a toolkit might be easy, finishing it wont be.

OS X ships with Perl, PHP and

OS X ships with Perl, PHP and Ruby as well, and I doubt you can name a desktop application written in them. I agree, Java has tanked on the Desktop, but on the back-end it's still the most in-demand skill set, and those back-end devs have to use something as a Desktop - Windows (ugh), Linux (haven't the time anymore) or OS X, with a great UI on the front and BSD/Java on the back.

What galls me is that the OS X JVM is a mature product. For many (including our company) it's our primary development platform. We've made an investment around it, and that's going to be wasted; not because the technology is outmoded, but because of a political decision. As someone who makes purchasing recommendations, that's the kind of thing I remember.

I think your assessment is

I think your assessment is correct, but I'm not sure about the conclusions.

I've been making a living out of Java (some on desktop, some in middle and server spaces), am very much a Mac user, and really think Java on the desktop is dead and not really worth reviving. There are better toolkits/platforms/languages out there for building things that matter to real people.

I'd like to see java remain on the Mac though, even if it's an olde worlde X11 implementation like on Linux/Solaris etc.

Thin UI layers (Flex? Silverlight? HTML5, Cocoa?) and a Java engine behind it is still a good proposition.

Josh, how does Amino compare

Josh, how does Amino compare to SWT?

Yes I'm sure it'll be more modern and perhaps easier to use, but with the requirement to support multiple back-ends you are reinventing a lot of what SWT already does well. So why not build on top of SWT?

Also, because of SWT, Eclipse already runs on SoyLatte without X11. Screenshots on my blog: http://njbartlett.name/2010/10/24/eclipse-soylatte-no-x11.html

Amino has a completely

Amino has a completely different philosophy than SWT. Amino uses purely virtual components, like Swing, but mixed with a scenegraph like JavaFX.  It does not have any native components.  However, if SWT has a hardware accelerated drawing canvas component that would be a good backend for Amino.

There is

There is org.eclipse.swt.opengl.GLCanvas, which exists on all platforms and uses NSOpenGLContext in the Cocoa port. I don't know enough about Amino to know if that would be enough for it to work.

I think that you are right;

I think that you are right; Java has to deserve its place on the desktop. During my days as a desktop developer I did a couple of Swing UIs, but it was hard to do some cutting edge stuff. However in general it did work well. But it was hard to convince my managers to let me do the Java solution.

Let us hope that desktop Java gets a lite bit of comeback. I for one would really love it.