Bruce Boyes's Blog

Linux vs Windows? Maybe a lesson here for Java vs Whatever

This blog entry by Marc Wagner was (at least for me) a slap to the forehead. We're all tired of the "Windows vs Linux" non-comparison and that's not my point in blogging his blog. Rather it's these three paragraphs, and the lesson they hold for Embedded Java:

Virtually anyone with a high school diploma and few hundred dollars can get certified in Windows server technology in a matter of weeks or months — while most people entrusted to administer an enterprise level UNIX/Linux server have a college degree and/or years of UNIX/Linux experience.

For the small business, where scalability is not an issue but human resource are, the inefficiencies don't matter because the overriding factor is the up-front cost of the system and the cost of hiring someone with the minimal experience necessary to take care of the system.

Doh! This immediately made me think of how tired I get at trade shows answering the question "why should I use Java over C/C++" for the 500th time that day. I think Java is the best news since C came along 30 years ago -- you can read my opinions elsewhere. I just expect it to be obvious to everyone else, like it is to me. But the reality is that about 10% of the people I meet at a non-Java event "get it" about why Java is "better". The other 90% don't. And of those 90%, 20% tell me they want to keep hand-coding in assembler -- at which point I stop trying to persuade them, wish them luck, offer them a data sheet, and ask them to keep us in mind if they ever want to increase their productivity by 500% or so.

So if Java is so great why is there relatively little uptake in the embedded space? Java, for many people, especially beginners, is just too hard to use. Just installing and configuring all the tools, classpaths, environment settings, etc takes a while and can have you pulling out your hair. There is no equivalent to a "pop in a single CD and go", at least in my experience. It's the same reason stated by Marc: Microsoft has leveraged the low cost of commodity hardware to produce cost-competitive software which is complex in design but easy to use. The result is inefficient (and sometimes bug-laden) software running on over-powered hardware. Throw in affordable training and certification programs and Microsoft has a winning combination.

I don't want to end on a "downer" note, so where is the silver lining if any? I don't know if embedded Java will ever hit the "big time", (or if Linux will, either). But I'm increasingly persuaded that as developers, anything we can do to make Java easier to install and use will be a winner. We don't need more techno-features -- Java is already light years ahead of C/C++. We need an image improvement, and we need to be more accessible and easier to use.

The other recipe for success might be this: don't waste your time going head to head with stable, legacy apps. There's little to be gained by re-writing things which already work well, in Java, just so that, well... they're written in Java. Rather, find places where the status quo is not working well, and a modern, object oriented language like Java could bring things out of the Dark Ages into modernity. Then come up with an easy-to-use application of Java which will be the 'knight on a white horse' to those users.

Comments

• Who's wanting to use c/c++ on windows? .NET is the preferred choice unless it's a very tight hardware integration.

  Posted by: smartinumcp on November 09, 2005 at 05:51 AM

• Bruce, your posts are always thought provoking. Java is apparently doing fine on corporate servers and cellphones but not on desktop, non-cellphone consumer devices and industrial devices. The desktop problems that you mention probably come from the still amazing difficulty in installing the JVM (for a non-developer). I agree with you that the problems for non-phone devices probably come from both an image problem and a relative lack of Microsoft-quality dev tools, and I would add the low number of JVMs and hardware (e.g., Java chips, complete systems) for this market. I would also add the low number of peripheral *drivers* in the free Java APIs and the recent arrivals of some very important drivers, e.g., USB (i.e., the fact that some took 9 or 10 years to arrive is part of the problem). Many of us also need Java-based hardware systems with advanced analog-to-digital and digital-to-analog functions. I, for one, am still waiting for such a system. In summary, for the non-phone device market, Java desperately needs APIs and hardware to connect the programs with the physical world. If we had that, I think that the existing great tools such as Netbeans and Eclipse would readily be adapted to this market. Let's hear it from the community.

  Posted by: sm1 on November 09, 2005 at 06:24 AM

• C/C++ is the preferred language in the embedded space. Actually, on non-PC embedded platforms, it's still C and assembly code.

  Regarding APIs and hardware to connect to the world around us, a number of people are working on that, including my company. Expect to see some interesting products from several vendors in 2006.

  Posted by: bboyes on November 09, 2005 at 07:33 AM

• I am not an embebed developer, but every time I visit at web sites dedicated to this and talk to people who work on this area, it looks like Linux has become the prefered platform, and this makes sense for the hardware developer (no royalties, support for many processor architectures, easy to customize for low memory needs, etc).

  What bothers me is that I cannot get "certified" Java for Linux except on Intel processors. On F/OSS Java mailing lists like Kaffe and GCJ there's allways people looking for a Java they can use under, say, Linux and ARM. I may be biased as an Free Software Advocate (Free as in free speech, not in free beer) but it looks to me that Java focus on J2EE and imaturity of open source JVMs is the biggest obstacle to wider adoption of Java for the embebed space.

  I don't think Java needs custom hardware (like a Java CPU) but JSRs for hardware integration and control would be nice. If you need to use C (JNI) you'd be better using Perl like PABX vendors like to do.

  Posted by: flozano on November 09, 2005 at 09:48 AM

• 
  Speaking from a desktop developer point of view, one of the advantages of writing Windows based applications is because they simply run faster on Windows and provide easier installs. The GUI is tighter and an "average" user will have little trouble adapting to it. You can also dive into Windows context menus etc etc. Since the majority of the world's users (not developers) are using Windows, it makes sense to cater to them in the best way possible.

  
  Although products like SWT are making this gap smaller, Java still suffers from an image of being a little heavy and a little slow (somewhat deservedly). Of course Java is better (unless you're doing some pretty specific Windows stuff), but if you're trying to sell Java to a Windows based company with the primary pitch of "it also works on Linux", you'll never succeed simply because the status quo is simply too comfortable for them.

  
  Java has to out-do Windows on the Windows platform for it to gain mass acceptance amongst Microsoft users. Matching Windows behavior is not enough. Consider this: If you're satisfied with your phone company and someobody offers you the exact same deal with the added bonus of "You could also use this phone in Barcelona if you ever go there", would you take it?
  

  Posted by: zarar on November 09, 2005 at 12:57 PM

• In case of Kaffe and similar solutions, while they are being used quite a bit by some people, afaict from the mailing list traffic in various places, you won't hear much about those devices being advertised as Java-enabled or something like that, since these runtimes are not Java(TM) ;)

  For embedded folks, a few nice places to check out are jamvm, which packs a 1.5-ish state-of-the-art interpreter engine in ~100k, and cacao which packs a fast jitter onto various platforms, including ppc and mips.

  cheers,
  dalibor topic

  Posted by: robilad on November 09, 2005 at 02:38 PM

• People using them seem to be re-using libraries/code/skills associated with the Java programming language, rather than having a need for a standardized platform, so those are usually stripped down solutions. IBM offers something called a "custom edition" of J9, which goes in the similar direction.

  cheers,
  dalibor topic

  Posted by: robilad on November 09, 2005 at 03:18 PM

• It is possible that the deficit in the embedded market may about to change, at least in the consumer electronics market. As you know, Java (JavaTV) has been chosen as a mandatory part of the Blu-ray DVD specification. All Blu-ray DVD players (including the Playstation 3) will be required to support Java, and discs can use Java for their interactive/programmed elements, such as menus etc.

  Assuming the success of Blu-ray, this could establish an important beach head which might be used to push Java into other consumer devices.

  Java failed on the desktop for three reasons: (a) double clicking .jar files frequently doesn't work - stolen file associations, missing or ancient JRE's and the confusion factor of Microsoft's lurking 'ye-olde-JRE1.1' implementation all conspire against Java; (b) Java's WORA bubble has traditionally made it difficult to integrate into the desktop like native apps - thankfully some of these issues are starting to be addressed in Mustang. (c) Microsoft's luke-warm attitude to Java (which for a technology like the JRE that seeks to be ubiquitous) didn't do it any favours.

  There's some truth in the accusation that desktop Java programmers have expended a lot of effort re-writing current 'native code' applications, in a bid to prove 'anything you can do, I can do too'. Our time may be better spent on the desktop exploiting WORA to create a new generation of 'network dynamic' applications (perhaps taking grid computing as our inspiration?) in a bid to prove 'look at what we can do, can you do this too?'.

  Posted by: javakiddy on November 10, 2005 at 02:49 AM

This work is licensed under a Creative Commons License.