Slashdot Mirror
Java's Greatest Missed Opportunity?
jg21 writes "It looks like Bruce Eckel has hit the nail on the head again. No sooner did he finish stirring debate by writing about the 'departure of the Java hyper-enthusiasts,' previously discussed here on Slashdot, than he now rubs salt in the wound by highlighting in AJAXWorld Magazine how and why Java missed its golden opportunity to become the language undergirding Rich Internet Applications. He comments: 'We must ask why Java applets haven't become ubiquitous on the internet as the client-side standard for RIAs....This is an especially poignant question because Gosling and team justified rushing Java out the door (thus casting in stone many poorly-considered decisions) so that it could enable the internet revolution. That's why the AWT and Applets were thrown in at the last second, reportedly taking a month from conception to completion.'"
TFA is too pop-uppy for mere mortals to read, so I'm just going to guess. Is the reason that Javascript-based stuff taking over the role Java was supposed to fill ten years ago that Microsoft no longer ships a Java engine but it does ship a Javascript interpreter?
Java technology and library development may have been steered towards web-oriented selling points, but the language itself isn't inherently oriented towards helping web developers and the like. Specialist scripting languages can always be developed to make specialist tasks faster - and Java (the language)is far too purely object oriented to be as specialist-efficient as some of the less object-oriented languages, without really stretching things.
In fact, my favorite uses of Java (the language) aren't web-apps at all, they're applications like Azureus, and Eclipse. That's perhaps what Java (the language) is really best at so far from my perspective - cross-platform development of portable frameworks. It's because of that, that Java (the language) has a stronger future than Java (the technology), as a strongly object-oriented language developed to be portable.
Ryan Fenton
There was a huge window for windows applications that Sun had missed. By the late nineties MFC was growing very tiresome to most and for most MS platform devs there was definitely an eagerness for something better. The company I was working with at the time did some work with Swing, including developing one of our major apps in it. The problems are infamous to this day: memory leaks, resource hog, ui issues, bugs, and more. It was a pattern I heard a lot from many others trying to use Swing. At this time though .NET was still years away. The desire for better programming environments was there and had Swing (and AWT) been delivered in better form it could have been a much different world today.
The problem with Java was not an implementation or technology one. All first generation implementations are flakey (think Mosaic). The problem was that Sun controled it too much, so it was pre-destined to never become ubiquitous. If they GPL'd it from the get go, it would have been a shoe-in, game over, touchdown, and go home. Now they have, but by now it's probably a day late and a dollar short.
Java's virtual machine, for the first several revisions, sucked ass and ran extremely slowly, cutting the general user experience on a Pentium I 100Mhz machine down to that of Windows 2.0 on a 80286 runing at 14 Mhz. If it wasn't for that, I would have probably been a lot more serious persuing Java as a "language I should learn".
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Look at the cell phone market. Java is everywhere, your blackberry, nokia, and even many windows mobile devices run midlets (Java applets for phones). It is a huge market, much bigger than the internet. More people have cell phones than have computers.
---- aut viam inveniam aut faciam
What killed Java as a standard for rich apps are a number of reasons.
.NET met success in a a lot of places because programmers don't have to change the language they are used to, and it wasn't as big a step to move from VC++ to Managed VC++ code.
1. Apps/applets have to be coded for multiple JVMs. Is the applet running on Sun's, and what features does it support, is it on MS's, or is it on IBM's? Other solutions like Flash have one and only one executable, so programmers don't have to guess what is running their code.
2. Java is slow and ponderous. I can tell when a website uses Java when my web browsers (multiple) freeze for a number of seconds while it loads the JVM.
3. Java's language and bytecode are pretty much married to each other.
That's basically a fancy way of saying they're dead while simultaneously arguing the opposite. People still write software for the Colecovision, but you don't see anyone talking about the "missed opportunity" to compete with the Playstation, do you?
Poor UIs have been a hallmark of Java Applications. While much of the blame does lie heavily on inexperienced programmers doing GUI work, there's also the matter of Microsoft's interference with the platform. One of the reasons for Java's early popularity in applications was because Microsoft provided an excellent AWT implementation that integrated with their platform. Which was exactly how Sun wanted it. The most experienced company with a platform (i.e. the vendor) would handle the specific implementation of the JVM. The Sun JVM was just a reference implementation, and was not intended for deployment.
Then Microsoft went about their usual backstabbing and Sun didn't have a good feel for how to replace their expertise. The rest is history.
Well, that and the fact that they were trying to write it as an Applet. I mean, you don't just take a full up office suite and cram it into a tiny portion of a Web Browser window! That's not exactly a recipe for a good interface. The Corel concept was good on paper, but the implementation was outright horrid. Unfortuantely, it was probably caused by the misconception that Java == Applets. Something that we programmers still struggle with today.
Or maybe it had something to do with the fact that OpenOffice was based on StarOffice? You know, the Office Suite that was developed back in 1986? However, there are a number of modern OOo components that are written in Java. Database Access in particular is a lot better if you can rely on Java's APIs.
Um... what? JMF is ignored because it's unnecessary. Java has Sound and MIDI APIs integrated into its core. MP3 support can be found in APIs like JavaLayer. Video has always been a problem, and not just Java. While there have always been solutions for standardized formats, the majority of video encoding/decoding takes advantage of proprietary codecs. Something that is not easy (or legal) to replicate. Linux makes use of a number of legal loopholes to bring us software like MPlayer and VLC. But these were never viable solutions for a straight-laced company like Sun. And the idea of better OS integration was something of an antithesis to Java technology. So Java focused on its strengths, not its weaknesses.
Javascript + Nintendo DSi = DSiCade
Java has a strange history. It was supposed to be a lightweight semi-interpreted language for use in web browsers. It ended up being the replacement for COBOL as a business application language, something nobody expected.
What seems to have gone wrong in applet land is that, early on, Sun produced a huge collection of mediocre libraries. This, coupled with a linkage system that brought in the whole library if you needed any part of it, bloated applets to excessive size. Remember, at the time, most users were on dialup. So that just couldn't work.
Also, as an aesthetic issue, Java's early fonts and visible objects were ugly. That was enough to turn off web designers.
On the server, none of this mattered. A memory-safe language with decent execution speed was a huge win. When a Java servlet fails, you get a reasonable error message, not corrupted memory. That was enough to make it a success on servers.
Java bloat continues to be a problem. There seems to be an excess of "packaging" associated with the language. Not clear why.
The problem was, the programmers they hired were not good designers or architects. I was forced to sit on the sidelines and watch as my predictions of poor requirements, poor design, and poor process turned into schedule nightmares, budget balloons, and gargantuan maintenance efforts proved to be true.
Afterwards, those administrators blamed the programmers, of course, but they also blamed Java itself. It was incorrect and unfair, but true nonetheless.
Looking back, the tech bubble attracted a lot of novice programmers who got hired at inordinate salaries to produce a level of quality they could not meet. As the bubble ended, many of these poor performers left but unfortunately some remain. My greatest fear is taking over for someone who "knows" Java because chances are they know how to write Java but they don't know how Java works.
I am doing my part. I am teaching Java at a local community college where I make a point of teaching my students how Java works. I also explain basic but good coding practices and design practices. I hope it makes a difference in the long run. Arguing with the administrators sure didn't.
@HbFyo0$k8 tH!$
If I see something neat and cool done in HTML, JS, and CSS, I can very easily rip it and change it and stick something like it on my web page. Back in the old days of the web nearly all design was done like this.
You can't do this (easily) with a Java Applet (unless the author makes the java source available) or a Flash application. If you want to figure out how something was done you have to dig into programming and work it out for yourself from the ground up. The openness and readability of HTML, JS and CSS make it really easy to get in above the ground floor level. Sure, you can still design horrendous web sites, but you can also design great web sites.
HTML spread because it was easy to write and didn't require learning or using some hypertext authoring application. Perhaps Java applets failed because people took a look at the Hello World applet and thought, "WTF?".
I still think *real* web-based applications, like a full-featured office suite, should be possible.
I think there are a lot of things wrong with Java, one being the existence of something called JavaScript. Many people don't differentiate the two, even those who are programmers. It's kind of like VB.Net having a bad reputation because of the existence of VBScript, VBA, and even VB6, when VB.Net is just a capable in most respects as C#.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
It's probably too late, though. Even if it works now.
Consider VRML. Remember VRML, 3D worlds on the desktop.? Too slow, too much bandwidth, lousy framerates back in 1997. Load up an old VRML browser today. With modern GPUs, it looks great and works smoothly. Nobody cares.
Java is very good at what it does but far too often it's shoehorned into things it's not good at doing. If Eckel thinks flash makes a better UI I'm inclined to at least take a look at it. Though personally I tend to despise flash web pages -- seems like most of the ones on the Internet are designed to just annoy me.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Agreed. However, the problem is not one of Java, but rather poor error trapping by the programmer. He should have handled the situation where OpenGL couldn't be initialized rather than assuming that the context will always exist. The same problem exists in many C/C++ programs.
"Mom" doesn't debug an app. "Mom" would troubleshoot to the best of her abilities. (Which, I'm afraid would not be very considerable.) Mr. Eckel asked how you would debug such an app. I answered.
Javascript + Nintendo DSi = DSiCade
I thank Mr. Eckels for his contributions to programming literature. I've read Thinking in Java, Thinking in C, Thinking in C++, and Thinking in Python. Overall they're very informative about the particular ins and outs of the language they cover--- as well as insightful and informative about other programming concepts. The recent 'revelations' he's pointing out about Java, however, have been well known by the Java community for years. It wasn't an opportunity missed, but an opportunity seized, and taken away. Nobody would argue that the programming model for applets is inferior in any way to what we're left with concerning AJAX, or even Flash (And Flex2 which he is now promoting). Nor are they larger, or bulkier by any extent. In fact, GWT which he's citing as a 'temporary' patch allowing AJAX to expand and become more widely used and less complicated, is simply an attempt to paste the Java programming language on top of already existing Javascript interpreters. Making a considerably large, or complicated, Javascript application was nearly impossible without the advent of AJAX, to prevent such scripts from having to be reloaded with each page refresh. Flash is not as ubiquitous, or cross-browser compliant as Adobe, or Mr. Eckels, would like people to believe. Beyond simple tasks such as playing movies, or presenting simple media, it will fail on the majority of browsers. Only two of the Flex2 examples were completely usable on my Ubuntu Linux machine, running Flash Player 9.
What we're seeing instead is what technologies could fly underneath Microsoft's radar, and become 'more' prevalent and compatible on various
browsers than Java, gaining momentum, and use. The reasons Applets failed are widely known, and obvious--- the weren't Microsoft Approved, and Java
wasn't open source. When Java first started gaining momentum, applets were widely used, due to the vast majority of Desktop users using Microsoft Windows, and Internet Explorer. As sun continued updating Java, Microsoft embraced the JVM, and included it in their browsers. They then started adding ActiveX extensions to Java, and promoting hybridization (although Microsoft Windows specific hybridization with ActiveX) through their Visual J++ development platform. Technically, they tried to gain control of Java, by completely tying it down to their platform through hybridization, and the fact that the majority of the developer market would be using their Visual J++ product[http://en.wikipedia.org/wiki/Visual_J%2B%2 B] (See litigation), unwittingly making applets that would work only with the Windows platform. Sun, then took Microsoft to court, pointing out that they were in violation of the virtual machine licensing agreement. The result was, a large period of time of political conflict between Sun, and Microsoft--- and a freeze in development and adoption of advances in the Java language in Internet Explorer as Java itself advanced leaps and bounds as a language. By the time the political turmoil settled, another technology, Macromedia Flash, had managed to squeak by unnoticed by Microsoft, and unadulterated (and considerably more controlled and proprietary than Java). On the Linux side of the spectrum, the explanation is much simpler, in the fact that Java was just open, but just closed enough, to rub open-source developers the wrong way. There has been considerable reluctance to buy into the Sun controlled Java community process, by the open source community, and to include Java components into open source platforms. Flash, on the other hand, provided absolutely no developer tools for Linux (Until now with the Flex compiler), and only a single proprietary plugin. In reality, it has been much more closed, controlled, and unavailable as a technology useful for open source development--- but has been less likely to embed into and pollute open-source code.
And now, that Java is open sourced--- applets have gained a fairly bad reputation, due to users perceptions of the lack of pro
Agreed. However, Shockwave had a variety of advanced technologies developed after Flash that were unavailable to Flash until recently. (Some never made it there.) Features like Hardware 3D and Classic Console Emulators seem like they should have kept Shockwave on the map. Unfortuantely, they didn't. So Macromedia/Adobe have been smart by running with what works.
Sun did a similar thing to Java with the J2ME spec. J2ME is the cutdown version of Java that far surpassed its big brother in end-user popularity. The only difference is that J2ME had to change platforms to do it.
Javascript + Nintendo DSi = DSiCade
I have read on Slasdot for close to 4 years about why Java is dead-dad-dead, and for years before that- why java is bad-bad-bad. I have heard why the Java Applet is gone with the wind, I have heard why Perl,LAMP,ROR, AJAX, FLEX, FLASH, .NET and etc etc 'are replacing/will replace JAVA for all mainstream [fill in technical application]'. I have heard people go on and on with buzz-word filled diatribes about the failure of JAVA.
.NET) using any of those above solutions. A few shops here and there, sure, but not much. More often than not, when I run accross an enterprise app written in one of those other solutions (again with the notable exeptions of AJAX and .NET) I find something intolerably slow or tremendously buggy. Certainly, PHP and Ruby have definately improved over the years- maturing and adding better OOP tools. Certainly, many of the aforementioned solutions are *well conceived, solid tools*. However, so is JAVA. JAVA works.
Yet I still note that JAVA developers of all flavor are perhaps the most in-demand (and highest paid) professionals in the Software development community. I still note a healthy and growing JAVA community. When I use 'stumble' to crash about the web, I see wonderfully designed JAVA Applets everywhere, fulfilling all sorts of purposes. I see IT shop after IT shop settling on JAVA as the tool of choice to solve problem after problem. Successfully.
Meanwhile, I have yet to see a proliferation of Web applications (with the notable exception of AJAX and
I have developed in JAVA for nearly a decade, and before that I used C++ and before theat C, LISP and others. I hear about the Horrible GUIS that you are stuck with in JAVA, all the while I write GUIS that are animated, colorful, easy to use in JAVA. I hear about the superiority of other Serverside 'frameworks', try them out, and find that JAVA Enterprise offers more features, more security, more scalability and etc. I hear about the technological 'legacy'-ness of JAVA while I delightlfully learn about and study all the new technologies and features JAVA adds to itself.
Now, to do JAVA well, you really have to Grok OOP and software architecture (and thats not just knowing the standard design patterns and how to use EJB or hybernate!). But I would argue to do any good distributed scalable app, you *need* to know these things as well. Its a sad fact in the software world that most programmers are godawful hacks. Having frameworks that make it easier for godawful hacks to create Enterprise-style apps is not necessarily a good thing.
So when I hear the slashdot commnity screaming the death of JAVA, I am reminded of listening to the recent interview with Cheney about the rosy situation in Iraq, filled with 'tremendous successes', and I wonder the same thing: 'when have you guys ever been right on this topic'. The Java discussion here is too polluted with FUD from the open-source fans (of which I am one, don't get me wrong). You folks were wrong a year ago, two years abo, 5 years ago... Why should I, a professional java developer doing good work in JAVA and publishing useful products, listen to any of you?
So, let the flames begin
Java applets can look exactly how you want them. If you want them to look as disfunctional as most deployed Flash and design your own widgets then you can.
Psst, Buddy! Applets != Java. Applets are dead. Java is not. Clear?
I say this as a Java developer of 11 years. (1996, baby!) Yet I am perfectly happy logging in and telling the world that Applets are dead. In fact, I can't wait for them to become a distant memory. They have done so much to tarnish the reputation of Java that it's not even funny. Java has found much better uses in a variety of other industries. It's time to let DHTML and AJAX mature into the role of rich web content.
Javascript + Nintendo DSi = DSiCade
HP gives a bad example of how to use applets properly.
I'm reminded of an HP print server (180wtfe) whose administrative web interface was packed full of applets. My response to the interface, "Why Java applets?" Applets were used for a very short navigation menu and even for info screens that had nothing other than text in them. It's almost as if they used applets just to fulfill the product's buzz quota.
In short, it would have been much more usable had they stuck with straight HTML.
Why should M$ alter the java language for "technical reasons?" This would seriously adversley affect developers, despite its "techincal superiority". Remeber that WORM (write once run everywhere) is a core concept in java, hence, proprietary changes break its concept. Microsoft should have worked with sun, not the other way around. Also, why should M$ remove java vm's from their OS and browser? This breaks far more things than it fixes, and is also very anticompetitive in a childish way. Sun embraced their platform by implementing a VM for windows, whey should M$ bar java from windows? Straight chickenshit.
Much of what Mr. Eckel says is true but I find it grating when he blames everything on the technology. For example:
"JavaScript has been around since, effectively, the beginning of the Web, but the browser wars made JavaScript inconsistent and thus painful to use."
Okay, let's forget for a minute that JavaScript isn't Java. That aside, the inconsistency of JavaScript during the time that Microsoft was illegally killing Netscape through the use of its monopoly was by Microsoft's design. It was using the now famous "Embrace, Extend, Extinguish" strategy. This was not the fault of the technology and there is nothing anyone can do to prevent Microsoft from playing dirty. Well not unless the Justice Department remembers where it left its balls.
And Bruce gives us this little bit of pseudo wisdom:
"If you use Firefox, how many sites do you visit that are at least partially unreadable because they've been created only for Internet Explorer (IE)? It seems to me that things are getting worse; I'm seeing more, not less sites that don't work right with Firefox...to the point that I'm seriously considering going back to IE.
Again, the incompatibilities are by Microsoft's design. A strategy to unfairly and illegally maintain its monopoly market share by (you guessed it) embracing and extending "open standards." Good one Bruce, switch back to IE and let Microsoft's dirty tactics work. It looks like the Justice Department isn't the only one who has lost its balls.
The race isn't always to the swift... but that's the way to bet!
everyone's got one, and I am or can be an asshole at times :), so I'll chip in.
:), because 1) no garbage collection (memory leaks get by even the best/most disciplined of software engineers/programmers), 2) the god damn syntax of C++ and its overloaded object model was _overkill_ for most newbie programmers. There was just one too many ways to blow your head off by C++'s powerful object model (think..pointers, references, new/delete, virtual destructors, 'smart pointer', exception handling was immature, copy constructors, assignment operators, operator overloading, reckless use of STL with pointers versus static objects, etc etc etc), and 3) 95% of software out there isn't system software (OS's, drivers, embedded) but application software. Hell, even for embedded nowadays one can use J2ME, and it works admirably well. This means if and when Java or a language like Java with enough similarity with C/C++ came by and removed all the pain points of its predecessors, it was bound to succeed.
Java _stormed_, not just merely took over, but literally stormed the programming world much, as I understand it even though it's a bit before my time, like COBOL did. When I started my first job, 1996 as a fresh grad, C++ reigned supreme still for _application_ software.
Slowly but surely, with the mass commercialization of the internet, the Java tornado came over the C++ camp, and blew it away (or I should say converted it, en masse).
Java hit & solved some extremely important painpoints with C++. No one ever accused C++ of being inferior as a language, as a matter of fact, the STL has yet to be repeated in Java (and no, generics aren't same as STL - STL yields more power), however, its demise was inevitable, again IMHO (the asshole talks now
Java succeeded. It did not miss any opportunities. You can elaborate on the benefits of more dynamic languages today, like Ruby, Lisp, whatever, but as it stands, de facto, Java is the standard today for most web applications (and it is making huge inroads into embedded even realtime applications too).
'A lie if repeated often enough, becomes the truth.' - Goebbels
Note that Active-X failed as badly as Java Applets, which makes one think that perhaps this was not the issue in Java acceptance.
The reason that both Java Applets and Active-X applets failed where AJAX has taken off is that JavaScript and XmlHttpRequest are available as part of and are deeply integrated with every modern browser.
The cake is a pie
A large issue with javascript is it's hard to find any good information on the subject (or at least I haven't seen any). Searching for how to properly do OO in javascript you get 3 or 4 different approaches. It takes a lot of experience to figure out whether you're supposed to use .prototype. or this.function = function() or whatever. Then a whole lot more experience to figure out what leaks and what doesn't (and how to fix it).
A single comprehensive library would help a lot. (w3schools is good, but doesn't have enough macro information).