Java Browser Edition: New name, wrong direction

Java Browser Edition: New name, wrong direction

Summary: If initial experiments are any indication, the team working on the Java Browser Edition (now called the Java Kernel) will be straying quite a bit from what users really need. What they need is a Java competitor to Flash. Break the mold, discard conventional thinking, and embrace the idea of Java everywhere with editions customized for the needs of users on each platform.


Ethan Nicholas was recently hired by Sun to work on his dream of a Java Browser Edition. Except they're calling it the Java Kernel now, and if initial experiments are any indication, the team will be straying quite a bit from the needs of the typical browser user. Ethan writes:

The first thing I have to do is establish that this project is feasible. So I figured I would start out by creating a simple, stripped-down JRE installer that contained only the functionality necessary to run System.out.println("Hello world!"), to get an estimate of the size reduction we could expect... 

I wrote a simple program which would iterate through all of the files in the JRE. It would remove a file and then attempt to run the Hello World program using this stripped-down JRE. If the test succeeded, the file was evidently unnecessary. If the test failed, the file was deemed necessary and restored.

In this way Ethan was able to get a minimal JRE that was 2.6MB in size.What we need is a competitor to Flash You might be thinking that sounds great, because it would compress down even further with a good compression algorithm like pack200. But as one reader pointed out, that's still pretty large. A FORTH interpreter for example can be had for 8K or less. I remember writing one with my roomate (hi Mike!) long ago in Z80 assembler, so I think that's a conservative estimate. Ethan responded:

I actually grew up programming Forth, so I definitely hear you. However, I don't agree that the size of the VM represents a severe architectural problem. Even an extremely stripped-down Java VM is going to contain an optimizing compiler, a sophisticated generational garbage collector, a dataflow analyzer for verifying classes, cryptography functions for verifying signatures, and on and on.

Therein lies the problem with their current approach. What we need is a competitor to Flash. This means:

  • It needs to be the same size as Flash or less (200K-1M max).
  • It should install just as quickly and easily as Flash.
  • It should update itself like Flash.
  • It should support streaming like Flash (including streaming video and audio).
  • It should be bundled with browsers (yes, even MS IE) like Flash.

In short, it needs to almost *be* Flash, except with the Java language (or some subset thereof) instead of ActionScript/SWF.

The team's grander ideas about using the JSR 277 module system, downloading functionality on demand, and full Java SE compliance sound good on paper, but does it really help solve simple user problems? No. Well, you might say, why does a user care if this thing running in their browser is written in ActionScript vs. being written in Java? They don't, but they will benefit from the increased productivity that comes from developers being able to use a common language and development environment for all platforms, containers, and targets. Increased productivity translates into decreased time to market, improved quality, and more innovative applications.

Forget about jar files and conventional class loaders. Verify ahead of time. Simplify everything. Heck, it doesn't even need a JIT. It doesn't need to be Java SE compliant or run old applets. It can be something completely new.

Some wonderfully popular applications have been written with J2ME, and GWT has shown that subsets are beautiful too. Let's have a JSR not for a Java Kernel, but for a real Java Browser Edition. Let's have "browselets" instead of applets and midlets. Consider a subset of SWT (maybe eSWT?) for the UI so it will fit seamlessly with native browser widgets. Break the mold, discard conventional thinking, and embrace the idea of Java everywhere with editions customized for the needs of users on each platform.

Topic: Software Development

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Java rethink

    Here's an idea for Ethan Nicholas and his co-geniuses at Sun -- drop Java altogether. Just clean it off the universal hard drive, throw up your hands and tell everyone how sorry you are. The sigh of relief that rebounds around the world will melt the poles. There are many alternatives to that sad failure of a language, the least of which gleam in comparison.
    • You are a little bitter.

      Java is something great an as all other languages it has it's pros and cons.

      A Java Browser Edition sounds like a valuable idea and if it will be done appropriately it will be something useful.

      From what I have read I think they are trying to include to many things in it and that could lead to it's failure as. We are not in a need for a new applet writing style technology but for something versatile and small. You can not get the jre small enough? Write asm.
    • such as...???

      "There are many alternatives to that sad failure of a language, the least of which gleam in comparison."

      Such as??? You seem to be very angry about this, but don't provide any arguments to support your attitude.

      From what I've seen, Java is popular, easy to write, and growing fast. I've not yet met anyone (besides you writing this post) that has bad things to say about it, so I don't even see your "sigh of relief that rebounds around the world" as being very accurate. In fact, the State government facilites here have already switched to the Java standard and are currently reprogramming many of their web applications. It won't be going away any time soon as far as I can tell.

      Once again, prove it! You certainly won't convince me that it is that bad by simply bashing it without any evident reason.
      • not bitter just tired

        Okay, not everyone's as down on Java as I am. I lead programming teams writing industrial apps for a living. Our stuff can't fail. I've stayed far from Java for years because of stability issues with the various iterations of its compilers. Two years ago in Toronto I ended up with a bifurcated team -- definitely not my choice. Eight were on the Java side, six on the Smalltalk side. The latter was doing the hard work -- database, rules, operations, and so on. They finished in barely 2 months; after 4.5 months the Java side (headed by a PhD in computer science from Taiwan, no less) was so mired in bug-fixes and trying to understand why things weren't working that we closed them down. The financial house we were writing this for was extremely unhappy. I finally got them to bring in a Ruby team of just 3, who did the front-end in a few weeks. (Today I'd choose Ruby on Rails, a framework in another universe from Java's.)

        My current project is being architected in an even more fundamental language, a complex spinoff of Lisp, chosen because of the sensitivity of the business. The program is very large and it cannot fail. Lisp is complex to write in, but masters in the language turn out tighter code quicker than any other language writers. (Check it out -- it's MANY times faster to write in than Java for people who know what they're doing, and you can produce guaranteed results, inconceivable with Java.)

        This has gone on too long. I just truly cannot understand how Java has gotten this far, and I know for a fact that in the world of large-scale industrial applications it's gotten nowhere at all.

        • So...

          You've had bad experiences that were solved by using different people (who happened to prefer or were expert in different languages/platforms).

          It also seems from what you say and how you say it that you have have not much experience of Java personally.

          I'm possibly stretching it here, but I would guess you are far more comfortable with managing systems development where you know a fair bit about the tools.

          Is that enough hinting for you?
          • never took off

            Java never really took off -- at least that much is true.
          • Really?

            In what sense hasn't it "taken off"? Have you looked at the There are 14,000 odd java jobs being offered compared to 6,000 odd c++ jobs.
        • That's not sufficient evidence

          Common on. You have to be a better scientist than that. There are way to many dynamics to make that kind of judgement. The PhD is meaningless in this context. And experienced team in one language with domain knowledge that have worked together will outperform a less experienced team. Also, you have to be careful of what you consider "the hard work". It may be more technical but in my experience the technical stuff is not where the risks are. it is where you interface with users (GUI) and things get subjective.
          I seriously doubt it was the language but the people who were using the language.

          BTW, in my field if something goes wrong, people can die not lose money. And we use Java, C, C++, Assembler, VB.Net. C#, Delphi, etc. It isn't the language, it is the quality processes, culture and people.
      • Lots of innovation now in Java

        Java has seen a resurgence of visible activity in the last 12 months or so with great projects like GWT (Java/Ajax hybrid), Eclipse, NetBeans, Spring, JRuby, Mustang (Java 6), and more. Of course there's always been a steadily increasing amount of *in*visible activity as Java and Java-inspired languages like C# are quietly running things in the back office of most Fortune 500 companies.
        Ed Burnette
      • What's wrong with Java? I'll tell you...

        First, <i>everything</i> about it slow. Compared to C++, it runs slowly; compared to C, it's just about standing still. It's builds slowly, regardless of whether you use javac, gcj, or ecj. It's slow to write. The lack of multiple inheritance--compensated for a little bit by the "interface" kluge--<i>really</i> limits the ability to create complex objects. The appallingly baroque directory structure necessitated by the use of packages in large apps, and the childish one-subroutine- (class) -per-source-file restriction makes it very hard to get your brain around the app. Lack of preprocessor macros (and typedefs) make Java harder to read and write than C; lack of comditional compilation is awkward.

        <p>Two, the lack of explicit pointers makes code very inefficent and/or very cumbersome, at least compared to C code. Data pointers are valuable enough; function pointers are worth their weight in platinum.

        <p>Three, "easy to write" is very much a matter of opinion--and in my opinion, C, augmented by cpp macros, is vastly easier to write than Java. To a great extent, Java is easier to write only for inexperienced programmers--and projects that try to take advantage of that <i>lose</i> the advantage of having experienced programmers.

        <p>Four, all of the above may, perhaps, make Java okay for small web-apps; it's completely the wrong thing for complex apps like Eclipse. Further, to get any decent performance from Java, you have to compile it to a natively executable binary rather than to byte code. Considering that one of the objectives of Java was supposed to be the ability to distribute platform- and OS-independent executables without having to distribute source code, having to distribute source to get performace is going to be a bit of a downer for proprietary s/w houses.

        <p>Five, the JVM you have to drag around with your app is a good-sized virtual boat anchor.

        <p>The world really doesn't need Java.
        Henrik Moller
        • Hmmm...

          1) Well, slow would depend on what it's supposed to do. I'd put it to you that Java scales a lot better than C and that there's very little difference as applications scale up. Also, it seems (at least on the surface) that real time Java works well, as in in real time. So... your slow view is at best subjective.
          2) I guess you like doing your own garbage collection and are prepared to spend the time and effort to do it rather than trusting Java to do it for you.
          3) On this point, I tend to think you see Java as a only a bit more than a Visual Basic kind of tool. Oddly enough Java skills for large scale developments don't seem to be going out of favour.
          4) Again, I don't think you understand Java very much with you coming up with these sort of put downs as it being "only suitable for limited application spaces, and not portable."
          5) I'd offer the opinion that anything other than a kind of small applicaton will have its own baggage. Not maybe a JVM, but perhaps a bunch of dll's similar that you have little control over. At least with a JVM you know what you are getting and can trust it more than the shifting sand of libraries that go bump in the night (because you or someone else accidentally change them).

          If is to be believed, and similar site overseas, it would seem that Java, and Java coders, are indeed needed.
        • I beg to disagree

          Slow? I've seen real examples of well written Java code beating the pants off C code, sometimes 3 orders of magnitude, because the language and libraries facilitate better algorithms, in my experience.

          Pointers? You've got to be kidding. I've literally spent weeks debugging wild pointer problems that would simply not exist in C#, Java, Ruby, or other pointer-less languages. And don't even get me started on C multithreading (shudder).

          Easy to write? We're going to have to agree to disagree on that one. I've been programming in C for >20 years and have written C compilers and debuggers so I consider myself an expert in C. IMHO macros and #includes are a huge wart on the language that make it harder to read (unless *you* wrote the macros, and recently). I'm easily many times more productive programming in Java even though I have less than half the experience with it.

          And I'm sorry, your conclusions are completely backwards. Complex apps need higher level languages. From your comments about compiling and distributing source, it sounds like you're basing your opinions on Java on third hand information, not direct experience.

          C was created >20 years ago to save people from having to write assembly language and it did a great job of that. Better tools are now available to save people from having to write C. You should give them a try.
          Ed Burnette
          • I fully agree

            2 megabytes is defintely not large on any desktop OS today. They are used for real useful things, and notably the very advanced run-time compiler that adapts the compiled code dynamically to the system on which it runs, for much better performance than a fixed precompilation that is not tuned for each system and cannot adapt to the target system as it must preserve its compatibility. Making the equivalent in C apps would require writing, compiling and delivering many versions of the same app to be compatible with as many systems as waht Java can support. So all the tuning is performed in the small part of the JVM.
            Look at what Windows or OSX or Linuc loads in memory just to boot, and you'll easily see that the JVM has a very small memory and resource footprint, compared to the equivalent C-compiled and underoptimized code you would need to download, install andfinally run.
            Of course you could get the equivalent performance by tuning your C apps and OS tools at least the same way the Java VM does. But it would require MUCH more time to develop, and the cost of writing and debugging the same code would be tremendous. For any complex systems and applications, Java really rocks, and has a much more general usage, without the many security issues that are plaguing billions of C source lines making a OS.
            In addition, the Java VM can easily be integrated into small hardware devices. Its boot time is very small compared to traditional OS boot time trying to implement the same services, and taking considerable footprint in memory (including the boot code that is not used after boot but that remains in memory even when it is no more used, something that Java handles much more gracefully, by just keeping what is necessary, discarding what is no longer necessary and that won't be accessed again after initializing the applications). If you have plenty of applications running, a single VM will run them much more securely and faster than a traditional OS with many distinct C-compiled libraries, whose only a small part is actually needed at any time (the rest taking valuable resources in memory or in pages swapped to disk). The reason of that is that applications are using much constant data but they are constantly updating some data structures in only small spreaded areas. It's extrmeely difficult to build C/C++ apps that can maximize the use of constant pools to avoid taking space in the virtual memory, even if this data will not be used. Java just loads classes that are really needed, and can discard it at any time when it is no longer used, avoiding most cases of swap; additionally the native code that the JVM compiles is extremely efficient, given the high level of symantic knowledge offered in its datatyping systems, and in the uniform model where all datapaths can be analyzed and tuned to take benefit of the most advanced compiler tricks (dynamic registry allocation, dynamic adaptation to performance spikes).
            If you have just seen Java 1.3 or lower, you have lost all the advances that were made since Java 1.4.1 in its native Hotspot compiler. Now with Java 5 (and Java 6 coming soon) the datatyping has been greatly enhanced to give even more knowledge to the JVM compiler.
            All these tricks are part of the JVM, and application developers don't need to concentrate much on these gorry details. The strong datatyping system allow them to make correct code with just a single development, and the program correctness is guaranteed to all the many platforms supported by Java. Yes C/C++ programmers have spent many years just tracking buffer overheads, memory leakages, and array bound checkings. Due to the complexity of the system debugged for so long time, C/C++ are reluctant to change the initial design, and unnecessary old code or data structures remains for long,just because they are feared of breaking something, due to new bugs that their compiler won't be able to detect and fix easily. In Java, the layered development really helps simplifying the design, or even changing it easily without such fears (especially when handling multithreaded applications which are really difficult to design, write and debug in C/C++, when this is natively supported in Java with ALL objects with a simple but efficient locking system; you get data correctness and atomic operations with much more ease, and you're just more productive to create new code).
            That productivity of Java explains why there are now so many projects using it, and the very wide range of applications where it is used (from enterprise server-side applications, to complete OS interfaces and fast graphics programming, including games, portable to many devices including very small and cheap smartphones or even in smartcards, something that would be impossible to do with C programming and that Windows Mobile attempts to imitate with little success, given the CPU power it requires, and the limited power autonomy).
            The Java platform is extremely stable (the most compon source of instability is the OS itself on which Java runs, and that requires some small C/C++ integration, but that accesses to various bugs in hardware drivers and OS services due to lack of correct synchronization of these services, or because they have their own buffer overheads). There was some bugs at the early stages of Java 1.4, but since 1.4.1, I have never seen a Java application or service failing or causing the OS to hang. On the opposite, we've all seen many bugs in complex C/C++ written appliations like browsers.
            A Java-written browser is certainly one of the good idea to develop now, and its design from scratch will be much easier with Java than with C/C++ code (in fact most of the services needed for a full-Java-based browser are already written in Java and certified)

            Java is so popular that it is most often chosen to implement test platforms for new protocols, and generally very few changes are needed when the protocol standard needs to be adapted during discussions,and the Java implementation is now among the first available ones, and requires very few change to optimize it. But as the Java development is extrely well layered, as soon as a part of the layered code is designed, it can be optimized and tested separately without breaking the compatibility with all the systems on which Java runs; and this work has gone very far now, due to the large number of high-performance libraries written in Java. What sun does in Java is to integrate the best ones that have braod use as part of the standard base, so that people are no longer concerned by solving their deployment. But Java could go further, by making now most applications deployable on-demand. If this is not performed for now, it's only because the communication networks are not realiable enough and people don't want to be blocked in the middle of their working session because some on-demand service is currently not available through the network (or because the ISP has just broken the connection or experiments some slow spikes of usage at random hours, or because a part of the Internet is currently unavailable by some distributed attack).

            But this is being solved, and live deployment on shared private appplication servers are there. We are and we will use more and more live services, as the network gains more power and is becoming more resistant and scalable than any single computer, and less costly to administrate.

            Just run the few free demos on the Java website, and given the small size of these apps, just consider how it's easy to install, setup and run just out of the box, and how fast they are on any system, even the smallest ones.

            Remmeber that the applications we want today are extremely complex. if we continue with C/C++ everywhere, we won't be able to get them at reasoannable price and we'll get them with much delays. Now consider the VM approach (Java or other languages on a JVM or comparable systems like C# on .Net): this is clearly what you want to get the software quality, speed of development, and ease of deployment without sacrificing the performance (like this is constantly done by all developers in C/C++ for any complex application, just because they want to keep their code maintainable).
        • You can't have done much Java

          1. There is no WAY that coding in C is going to go faster than JAVA unless you aren't very experienced in JAVA. So I agree with Ed there. Just dealing with strings alone would save many lines of equivalent code in C.
          2. Macros were a way to deal with a problem that no longer exists in modern languages. And they are bad solutions. Modern C++ programmers consider them "evil".
          3. Speed, because a run-time can dynamically optimize, it is possible to get quite good performance, equivalent to C. Where java tends to be slow is in the GUI stuff because of the restrictions of direct hardware access.
          4. "easier to write" I think statistics will blow away "your opinion"

          5. "multiple inheritance" If I heard an interview candidate list the lack of "multiple inheritance" (C++ style) as a major hindrance, I would not hire that person because it shows a lot of ignorance or pride or something. Very few C++ experts would share your views here. I have and will use MI but I don't see it as a major benefit and I tend to avoid it like the plague.
          • Multiple inheritance

            It was one of the reason the Borland OWL failed so miserably: it was nearly impossible to understand how your program was supposed to work, bugs were extremely difficult to reproduce or isolate, and it was impossible to debug it, even if the OWL design itself was really smart. Borland has learnt that (quite late), and is now evangelized to VM systems (Java and .Net). Same thing about IBM, and most fortune 500 companies and governmental organizations that no longer want to support the extreme cost of maintaining non-portable applications that must be rewritten every 5 to 10 years or adapted with complex gateways just because the previous systems are no longer supported. The Java system for now is the only OS that has survived all the major software design revolutions and still working in the largest set of devices and computer/network architectures. The ROI of Java development and deployment is the best long-term option that really eases the evolution of softwares and the constant adaptation to new demands.

            The only useful thing that was added partly from C++ and other object languages is the generics to solve compon problems (don't confuse them with the C++ templates with all their gorry implementation details), and Java 5 has demonstrated that these generics were clearly self-sufficient to really improve the productivity, without needing any gorry preprocessor like in C, or without the tricky operators and implicit conversions of C++(gorry details inherited from C). The generics in Java were really made for increasing the productivity of programmers and increase the code quality and correctness without sacrificing to the maintainability. With its support of Generics, Java really don't need multiple inheritance even in the most complex cases.

            Some were qaying that Java would not survive the 64-bit revolution, but this is completely false: 64-bit OSes are still not working as expected to support 64-bit applications, but a minimal 64-bit OS is enough to support the already existing 64-bit ports of the Java VM, without having ti change any line in the Java applications. The largest collection of applications for 64-bit systems is already there and works marvelously and natively using 64-bit instructions with all the best tuning parameters of each processor family, simply because the Java VM is the true OS that hides those details. You don't have the same ease of deployment and reduction of software costs and licences with C/C++ written applications.
        • Have you tried HotSpot?

          "Compared to C++, it runs slowly; compared to C, it's just about standing still."

          Have you tried HostSpot?

          Also, sounds like you picked up a few nasty programming habits in C. Personally, I find it cubersome trying to figure out somebody's code when it's filled with macros. I'm constantly asking myself "and what does this macro do?" and usually they're filled with what looks like Greek. It's spaghetti coding all over again, because I've got to jump around trying to figure out what all of the macros do.

          "one-subroutine- (class) -per-source-file"

          If you think a class is equivalent to a subroutine, you've never been properly introduced to OOP . . .

          "Data pointers are valuable enough; function pointers are worth their weight in platinum."

          And this only confirms my suspicions. Even though Java pointers are not explicit, I've yet to find something they can't do yet.
          • Reply to my next post, not this one

            I accidently sent this message before I was finished with it :(.
        • Have you tried HotSpot?

          "Compared to C++, it runs slowly; compared to C, it's just about standing still."

          Have you tried HostSpot?

          Also, sounds like you picked up a few nasty programming habits in C. Personally, I find it cubersome trying to figure out somebody's code when it's filled with macros. I'm constantly asking myself "and what does this macro do?" and usually they're filled with what looks like Greek. It's spaghetti coding all over again, because I've got to jump around trying to figure out what all of the macros do.

          "one-subroutine- (class) -per-source-file"

          If you think a class is equivalent to a subroutine, you've never been properly introduced to OOP . . .

          "Data pointers are valuable enough; function pointers are worth their weight in platinum."

          And this only confirms my suspicions. Even though Java pointers are not explicit, I've yet to find something they can't do yet. They are every bit as functional as the data pointers, and functions (known as "methods" to those who write Java) can be wrapped in classes.

          "Five, the JVM you have to drag around with your app is a good-sized virtual boat anchor."

          Not nearly as much of an anchor as all of the Windows-specific libraries you have to deal with when creating applications for Windows.
  • I'm not sure about competition with Flash

    Java isn't really supposed to be a competitor to Flash.

    Sure, it *can* make nice, pretty animations, but the style of the programming language lends itself to creating applications, not animations.

    BUT - Java is also extremely flexible, and the latest JVMs from Sun Microsystems use hardware acceleration for graphics, so theoretically they *could* modify the class library to make it compete with Flash.

    In all honesty, though, I'm not seeing the usefulness of applets. I'd rather use Java for creating applications with. Unfortunately, it's now got some stiff competition with C#. It still has better cross-platform support, but IMHO if the language doesn't find a good way to make itself unique, it's probably in danger of getting replaced by C# and Flash.

    "It should install just as quickly and easily as Flash."

    In other words, the browser says "plugin needed" and Java gets installed automatically when the user clicks on the "broken plugin" icon. That's a tall order, but probably doable.

    "It should be bundled with browsers (yes, even MS IE) like Flash."

    That's between OEM manufacturers and Sun Microsystems. And I've found plenty of computers with IE but no Flash. Ususally, Flash gets installed later; it's usually not bundled. It's just that installing Flash is as easy as installing a plugin.

    "Heck, it doesn't even need a JIT."

    News flash: JIT is outdated. HotSpot took its place.

    And no, you do [i]not[/i] want to run Java on a pure interpreter. Trust me, it's [i]slow[/i]. You're going to want to keep the hybrid compilers/interpreters. One of the biggest complaints aimed at Java is that it was slow. If you go back to pure interpreters, that's going to re-surface and get ugly again. I'd rather not repeat that.
    • Java vs. Flash

      "Java isn't really supposed to be a competitor to Flash. Sure, it *can* make nice, pretty animations, but the style of the programming language lends itself to creating applications, not animations."

      Flash is being used as a common platform for applications, not just animations. Look at Adobe Flex and Apollo, and OpenLaszlo. If there were a good Java Browser edition, there would be no need for writing applications in Flash. People just use Flash for that because it's ubiquitous, small, and fast.
      Ed Burnette