Skip to main content

No Future In Java

Posted by javakiddy on November 26, 2008 at 3:39 PM PST

A C++ programmer walks into a Usenet newsgroup, "I don't see the point of Java!" he announces.

"It allows your code to work on many different platforms...", replies a local Java programmer.

The C++ programmer is unconvinced, "I can already do that with C++", he blusters.

"...without re-compiling your code for each platform", adds the Java programmer with a smile.

"What?!", shouts the C++ guy, "Why would I EVER need to do anything like THAT?!?"

Okay, so as jokes go it's pretty lame, but conversations not unlike the above were ten a penny back when Java first appeared in the mid 1990s. A lot of programmers just didn't get it — but then, why would they? They had a lot invested in their current tools, and C++ (Fortran, BASIC, whatever) was serving their needs just fine. The newfangled World Wide Web may have been a fun distraction, but it wasn't likely to change the programming landscape, was it..?

Roll forward almost a decade and a half, and it's blindingly obvious why the internet needed something more than C++. The software world evolves, but usually in slow baby-step increments. Very occasionally, however, the industry throws up an idea which tempts us with the promise of a giant leap forward, and a clutch of new and unusual tools emerge to explore the possibilities. Not all giant leaps deliver — let's not forget Java started life aimed at a smart device explosion which failed to materialise (until years later.) A quick name change and a fresh lick of paint later, and Java became the internet focused technology we know and love.

Some say we're rapidly approaching another seismic shift in the software world, at least from a desktop perspective. Whether you agree with the idea or not, Cloud Computing and Rich Internet Applications have many excited (guilty!) In anticipation of this brave new world we have the accompanying slew of strange new tools: Silverlight, AIR, and our very own JavaFX, which debuts in only a few days. They promise to change forever the way we think about user facing software, yet already seasoned Java programmers (eg. some respondents to Fabrizio Giudici's blog a couple of week back) are asking "What?! Why would I ever need to do something like that?!?"

As I see it, there are two questions here: Firstly, will Cloud/RIA computing become a significant force on the desktop? Secondly, assuming it does, how can the Java community grab a share of this market?

The first one is easy to answer, a quick Gallic shrug and an apathetic "dunno" will suffice. It's the same answer we can confidently give for man made global warming, or whether any of us will have jobs this time next year. Short of James Gosling becoming the eleventh Doctor Who, we can never say with confidence how things will turn out for JFX until some time after the market has already decided. Tipping points are never appreciated when they happen, it usually takes a hefty dose of hindsight to uncover why things ended up the way they did. All we can do is guess at a reasonable worst case scenario, and equip ourselves accordingly.

Let's put the first question to one side by assuming RIA's are the future — what should the Java community do about them?

Giant leaps are often benefit from new languages, do RIAs need one too? The temptation is to defend our current tools against any criticism, to pretend not to notice their blind spots, or to claim their deficiencies don't matter. Recall how our comical C++ coder was quick to equate the cross-platform ability of C++'s source code with the platform neutrality of Java's binaries, and was totally blinded to the benefits of Write Once Run Anywhere in a network-centric world.

Surely the most pragmatic answer is, "we don't know"? It seems reasonable to assume RIAs may benefit from some sort of DSL, although Swing and WebStart may also suffice. It all depends upon whether the informality associated with browser-based user interfaces is a passing fad, or a permanent change in end user tastes. But one thing we can say with certainty: no industry can progress unless someone takes a punt. The only reason we're talking now about "all the screens of your life" (to paraphrase the JavaFX motto) is because Sun took a gamble with Java. (Just how far would we have got with C++ and Perl...?)

There are indeed some similarities between the early days of Java and JavaFX: JFX, like Java, will be launched in the face of a well established (and entrenched) opposition, and doesn't truly innovate so much as integrate and focus established but less visible ideas into a tool suited for solving a particular type of problem. But there's also some pretty stark differences too: in 1995 Java could ride on the guaranteed street cred of bringing eye candy colour to otherwise grey HTML pages, yet in 2008 JavaFX doesn't have the market to itself, and rippling lake applets no longer wow today's fickle users.

JavaFX's big trump card is it's interoperability with Java. Rather than the client/server chasm inevitable with rival technologies — Java on the server, ActionScript on the client, for example — the developer can decide how far across the span of the application Java should reach. It's possible to develop a thin JavaFX Script veneer over heavyweight Java libraries, or (the other extreme) to restrict Java to only a server side role and let JFX rule the desktop — the option is left open. This causes familiar chasm-straddling technologies (SOAP/JSON/REST/etc,etc,etc) to be demoted to implementation choice instead of mandatory requirement.

Only time will tell what the future has in store for JavaFX. If it turns out RIAs don't deserve a whole new platform, and Java will suffice, then we haven't lost much in hedging our bets. If the opposite is true, however, then at least JavaFX still gives us a fighting chance...

Related Topics >>

Comments

java vs c++ hum very interesting ... what is the question, high/low level language? multiplatofrm ? no, the question is: am i a computer scientist or a coder? do i have to known several languages or only one? am i flexible and versatile or not? javafx is great because you simply do the same or better with less lines, simplier, and, in my opinion, it's more accessible than java (don't speak about c++). that's have done java against c++ in the past. an finaly, the performance debate is off since multicore architecture, wich naturaly give an advantage to well designed software implementation like the jvm! ok... i go back to my RIA project coded in ASM ....

I played rubik's cube on a gnome desktop, thought there are small bugs, it might be fixable. I didn't try to fix it, but in general the interface is fine.

There's a compelling advantage of Java over C++; the answer to the C++ "why would I want to do that?" question is simple: to avoid porting. If the C++ developer has ever had to port (not just recompile) a real-world app, then he will "get it". As for JFX, the answer's not so compelling. If the answer is "to make RIA's easier to build than with Swing", I don't think a Swing programmer will find it all that much easier. To a Flex/AJAX/whatever developer, it must be easier than whatever they're currently using. If JFX were going to explode in popularity, it would have done so already, as Java did when it was in beta.

@mikeazzi: I'm not following you. I'm not trying to rewrite Word, Excel, or Outlook in Swing. I just said that my users want the same "rich" functionality that you get with those apps. We've already delivered those features using Swing vie Webstart as I described. I'm not unwilling to explore new technologies, but I'm not going to recommend something that doesn't offer any value over our current technologies. In the real world, I can't just go to management and say that I want to switch technologies because it's "like cool and stuff". Yet again I ask.... How can JavaFX make MY life better and more productive?

@evickroy: It's rather ironic that you're using Excel, Word, and Outlook to drive your argument. Well guess what, Excel, Word, and Outlook were not written in Swing either, and that same argument you're using against JavaFX, is constantly being used against Swing and such by these office apps developers. Don't you see the pattern?

@mikeazzi: You are correct. The world didn't stop once our app were released. We continue to have to maintain them and build new features that our users request as their business processes change. That's why we chose a simpler approach that only required a developer to know Java. No bulky frameworks to fight with, no 2 or 3 different scripting languages to learn or config files to hack, etc. To be quite frank with you, I don't care what apps you or anyone else is writing because I'm only getting paid to write mine. I'm not asked to keep up with Google or Myspace because our users want real applications with Excel, Word, and Outlook functionality. Again.... you ask the same question I originally asked... "how does JavaFX make my job better, and more productive?" That really is the question. The answer that I heard was that it won't.

@evickroy: I think the real question that you should be asking yourself is this: If were to write my app from scratch, will JavaFX make my development experience more productive, more empowering, and more pleasant? Because quite frankly the world didn't stop at whatever nice apps you have written, as I'm sure there will many more like yours, and better that are yet to be written. So again the question is, how does JavaFX make these people's jobs better, and more productive. If it does then we have a winner.

@javakiddy Yes, well, no one will be complaining that Java can't run on an Atari ST. But plenty of Developers and users are going to be pissed to find out the JavaFX doesn't run on Linux. Flash player 9 and 10 were released on Linux, Mac, and Windows simultaneously -- and they're not the ones claiming to be the "write once, run anywhere" solution. I'm sure that JavaFX will be available for Linux "soon", but it doesn't excuse the fact that it's not there to begin with. The launch of JavaFX should have been postponed until they could support Linux along with Mac and Windows.

@javakiddy: Thanks. That's the same conclusion I keep coming up with everytime I try and evaluate JavaFX. We're already building Rich Intranet Applications just using Swing. From my experiences, Java is far from dead on the Desktop in the Enterprise. It may not have much commercial presence, however. I'm not trying to knock the effort spent on JavaFX, but for the silent Java Desktop developers out there, having the existing Swing bugs fixed and some modern ease of use APIs to simplify building RIAs on top of Swing would have been a lot more beneficial.

@evickroy: There isn't any real benefit, aside from perhaps a nicer declarative language for crafting your UI. Of course, if every desktop application was like yours there wouldn't be any need for JavaFX. ;)

I'm a Java developer working for a large company. We build departmental apps for internal users. We use Swing delivered via Webstart communicating with servlets on the back-end to broker data to and from the database. It's a very simple 100% Java solution using only a few very mature open source libraries. There's no session state on the server, so our administrators love us. We have no need for streaming video content. No reason to express our "artistic creativity" here. I'm having difficulties seeing how JavaFX can benefit us in any way. Can anyone shed any light on how JavaFX might bring some value to our development team?

@arekstr: you might take a look at the following links for Swing uses: - Swing Sightings : http://java.sun.com/products/jfc/tsc/sightings/ - Excelsior JET Gallery : http://www.excelsior-usa.com/jetgallery.html That's not so bad if we take into account Swing is only usable since 1.4 (or even 1.5 for performane reasons).

@arekstr: "Just other day one developer in our company said they are going to compile one of our application (C++ Qt) to netbook with some exotic (not Intel compatible) processor. I don't think our Java swing application will ever run on it.," Well Java doesn't run on the Atari ST either, but I'm not sure what that proves, or disproves. :) It's interesting, the reaction of some (not all!) Java programmers against JavaFX (Script) is very reminiscent of the reaction some C++ programmers had against Java back in 1996. In both cases I suspect it wasn't a case of the complainants misunderstanding the platform, so much as being blinded to the problems the platform was trying to address.

jwenting on November 26, 2008 at 10:21 PM wrote: > JFX doesn't even get adopted by existing Java users That's maybe also because of the fact that everybody of those Java users would be the "early adopters". > Expect to see a return to serverside everything sometime next year I also do think that the RIA are somewhat a hype. RIAs are not the magic pill to solve all problem. First new problems introduced with RIAs can be seen by the fact that those clients increase instability of the browser even affecting all other applications/sites I am browsing. I do really not have any interest as a user in complete browser lockups because a specific site generating an infinite loop at my client. I think, many people overrate the RIA design. I think with RIA design people want to combine advantages and erase disadvantages of web and thick clients (see also http://it-tactics.blogspot.com/2008/11/web-vs-thick-client.html). They want an all-in-one device suitable for every purpose - the magic pill that solves everything. But this will create new problems, security issues and so on and it is not sure that the advantages of those two designs can be really combined. psynixis on November 27, 2008 at 01:08 AM wrote: > Java never had any success on the desktop The capabilities for desktop application development was a major reason for me to choose Java. I do think people having that impression which also might be true is because of some additional startup time of a java application in general when launched the first time (which BTW can be experienced more on Windows than on linux for instance). This often results in the user experience of applications like Thunderbird or Firefox being faster and better integrated into the os. As far as I can see from tests is that a Java GUI has even same speed in reaction inside the application (when already started). If Sun would create a shortcut at Java runtime installation in the startup folder on Windows user experience would be better (as runtime is then loaded at startup as it happens for all the libraries Microsoft products might need). Slightly off topic: For myself I do have to confess that I do also find - from the user view - that e.g. C-Programs give a better feeling of being integrated into the OS (which really is the case). Regarding the platform independency C(++) is no option for me as I do not have all the infrastracture to compile (and test) a program on all platforms. So I would have to find partners doing that for me. But the decision for Java instead of C(++) for me was on the experience of C(++) code in general being easier affected of bugs (logically). I trade in a little more practical advantages for the loss of speed and OS integration. But I can understand people choosing the other approach.

All these comments along the lines of "Java never had any success on the desktop" or "Java's niche is on the server" really make me laugh. They need to be added to the "Java is slow" myths that so many people people think think they "know".

"Write Once Run Anywhere" you still believe in this? Just other day one developer in our company said they are going to compile one of our application (C++ Qt) to netbook with some exotic (not Intel compatible) processor. I don't think our Java swing application will ever run on it., Also I think, I have more problem with swing on Apple when they with Qt. Web "applications"... there are some fancy text (html) page generators made in Java, but much more are made in PHP. If you look at CMS systems none of big ones is made in Java. Applications centric to Internet experience: Firefox, Skype, P2P client, chat, etc. are all C++ applications. Tools which are used for collaboration over network like Git, CVS, SVN made in C++. There are some made in other languages in this category, but none in Java. Databases, being most important part in so called web "Java" applications, mostly C++. After being Java developer for 10 years I'm a bit disappointed. Java is always 2 or 3 most popular option. It will be just the same for RIA and JavaFX, I'm afraid.

> All these comments along the lines of "Java never had any success on the desktop" or "Java's niche is on the server" really make me laugh. They need to be added to the "Java is slow" myths that so many people people think think they "know". No Java is not slow in this day and age after it has been JIT'ed, but it still somewhat of a memory hog and somehow I don't see how adding another layer on top (JFX) is going to improve that. Organizations are warming up to network computing once gain, you should see the face of our system admins when they see their Citrix users run Java/Swing applications!

Java became successful in the server space - it never really took off in the desktop space, something Sun are painfully aware of and, in part, the reason for JavaFX. For JavaFX to be successful in the desktop space, it has to be demonstrably better in almost all ways to Flex and not just APIs and speed, but deployment, ubiquity, and pay rates for developers.

There's a major difference here: Java found rapid adoption across the board. JFX doesn't even get adopted by existing Java users...

RIAs are a fad that's going to fade. Essentially they're a return to the old client/server paradigm, which never lasts very long because systems admins don't want the burden of keeping hundreds of workstations updated anymore and don't want the (potential) loss of control and security by allowing those workstations to update themselves.

Expect to see a return to serverside everything sometime next year, maybe combined with slightly flashier user interfaces than the websites of say 2005 used to have. Those might use applets (but more likely Flash than Java applets) for the frontend, but I doubt that's going to really take off (especially given the potential security risk of having them communicate directly with servers).

Where Java itself was a product created in the light of a clearly (at least in hindsigh, many at the time probably failed to see it) emerging market, JFX is a solution looking for a problem that was solved 20 years ago and became irrelevant 10 years ago.

I think the difference is that Java found its niche -- on the server.

Btw: if any JFXiA readers are interested, follow the link for a screen shot of the JavaFX maze thingie I've been developing as one of the examples: http://weblogs.java.net/blog/javakiddy/archive/Nov2008/ch8_h.jpg