Yet the typical Java license fee is in the range of US$ six figures (per year). Does this license model support the kind of widespread adoption which Sun claims to want?

"Wait a minute - isn't Squawk open source?" you ask. Yes, but 'open' is not necessarily 'free'. Squawk is free for non-commercial use, while for-profit use requires the typical ME license fee mentioned above.

Industry-wide, interest in 'smart dust' is becoming so widespread that other vendors (such as Texas Instruments, which now owns Chipcon, the vendor of the radio chips used in SPOTs) are launching low cost, open standards wireless sensors initiatives, based on the new generation of 2.4 GHz radios.

The recent Embedded Systems Conference hosted a TI eZ430-RF2500 seminar packed with 500 (my guesstimate) people who all walked away with an MSP430-based (the same chip family used in Sentilla motes) wireless sensor kit. The eZ430 kit (which is 2.4 GHz but not 802.15.4-based) is $49 including 2 nodes (one with a battery) and an Eclipse C-language toolkit. Or get the 802.15.4 (with free Z-stack Zigbee) version for $99. These prices are a long way from $10 (the oft-quoted price of a truly 'pervasive' dust mote), but not unreasonable. There are no hidden tools or license costs - TI just wants you to buy their chips. TI is not alone - you can find similar offerings from Cypress, Atmel and others.

None of the TI solutions support Java (but the Sentilla option does - and look for some news from them at JavaOne). Sentilla mote prices are TBD and early dev kits are a few thousand dollars). The (more advanced) SunSPOT kits are now $750 to the general buyer, $300 or perhaps free to educational users.

Yes, these are different devices -- SPOT is a much more capable platform in terms of processing capability and included sensors. So comparing the Sentilla or eZ430 to SPOT is not entirely fair. But if the goal is smart dust, these are the best offerings which each vendor has chosen to create. Someone else could create a lower cost SPOT and sell it... oops, well, they would have to consider the licensing issues first.

Industry analysts predict that indeed smart dust will become pervasive. But will it be Java dust or C/other dust? Consider the above links, dev kit prices, and licenses and then you decide where things are heading. If Sun wants developers to have the choice of pervasive Java smart dust, something needs to change, and it needs to change soon.

Don’t Look Back by ZDNet's Andrew Keen -- How to innovate? That was both the spoken and unspoken question on everyone's minds at the Wall Street Journal's memorable D Conference this week in Carlsbad. How can we radically improve the experience and value of interacting with one's digital device? What is the next chapter in the evolution of information and entertainment technology?

The part of this that really sticks out for me is the issue of looking ahead instead of behind. Exactly what that means isn't fully explained in Keen's blog. The possibility which rings true for me is the concept of disruptive innovation vs evolutionary innovation. I just finished an Anne Perry historical novel and one example of disruptive technology is the advent of rifled-barrel, cartridge-loaded firearms which displaced smooth-bore muzzle-loaders around the time of the US Civil War, with devastating results.

Speaking of looking forward, Ann Perry seems to have succeeded in spades. She has gone from a murder conviction (this was news to me until researching this blog) at the age of 16 to a new name, career, and commercial success. That's a turnaround!

This year, my company - Systronix - is releasing several new products which attempt to look forward into areas such as robotics and wireless sensors. These are not a logical progression from existing products, so perhaps we can consider them disruptive...

Please share your thoughts on how you try to look forward.

And what does this mean for Java and related technology? Will Java be eventually displaced by something disruptive, or will we see the programming language evolution of the last 20-30 years continue for the next decade or two? Personally I believe that programming is far too slow and complex and we all would benefit greatly from a radically new answer to the question of "how to we make programmable devices do what we wish?" but I have no idea what such a quantum leap might be, or even if it is possible.

And in my case, how do community leads find the time to keep things fresh? How does anyone?

So it should be an interesting weekend, and JavaOne hasn't even started yet...

This Infoworld article is one of many announcing the open-sourcing of Java, including the Micro Edition, under the GPL license. Oddly (I don't understand it, but maybe someone else does) IBM whined about this, insisting Java should have been made part of the Apache Foundation.

Why can't IBM and Sun kiss and make up? If Sun and Microsoft can, you'd think IBM could. Oh, yeah the sparring IDEs... c'mon guys. Eclipse is a great product, one I think Sun should support instead of continuing to push NetBeans. There are more productive things Sun could do rather than paddling upstream in the IDE war.

So, open-source ME - what does this mean for embedded systems and robotics? Possibly wider acceptance and streamlined porting to other hardware platforms. If the commercial licensing of Java has also been simplified, and cost reduced, we could hope for much more standardized and widely available Java VMs or native implementations across ARM, MIPs, PowerPC, AVR, etc.

Then, maybe, we embedded folks could start to really claw our way out of the stone age into the new millenium. As it is, here at Systronix, we support four different embedded Java systems (aJile JStamp/JStik, Dallas TINI/TStik, Imsys SNAP, and SunSPOT Squawk). Plus, ARM7 C and assy code, Philips 900 series (8051), Dallas 8051/C400 family, Silicon Labs 8051, and Atmel AVR.

This is insane. At least the Java systems can all share a single IDE and build environment. Runtime libraries are just different enough to drive us a bit crazy. The other micros are all night and day different, especially regarding peripheral support. They way they each do CAN, I2C and SPI is all completely different and non-portable. So we spend way too much time struggling with mundane details instead of applications.

Which brings me back to Stallman's remarks about the Java Trap. What about the C and assembly code trap? It's all a big trap, or more accurately, a Tar Pit. The sooner we can unstick ourselves, the sooner we can get Real Work done. And Java still gives us the best hope of doing that. Open-sourcing Java, while a step in the right direction, is just a step. There's a lot more that needs to be done to make developers more productive.

Siemens has a Java-enabled cell phone with serial and digital outputs, intended for OEMS to design into their own devices. It looks like a typical development board with easy access to system signals for quick protoyping. If the price is right I want one. This sort of product turns a GSM cell phone into a pluggable network-enabling functional block for hardware which can't attach to ethernet.

GE Healthcare showed some spiffy looking graphics screens of x-ray and CT data, all programmed in Java. It's nice to see that Java's graphics APIs are considered mature and rich enough for a major corporation to design a whole line of mission-critical products around them.

JSR-209 - Advanced Mobile Development - promises to make mobile devices look a lot more like standard J2SE apps with a subset of Java 2D and Swing. This includes "real" threads, I/O, and network stack. Let's face it, the resources in cell phones have come a long way since the J2ME and MIDP specs were conceived, so the hardware capability has been in the phones for a year or two. Phone color screens can now be as good as the best PDAs - in fact, in devices like the Treo, they are one and the same.

JSR1 - Real Time Java - is getting a major enhancement with 2.0, which adds things like realtime garbage collection (based on work at Lund University in Sweden). Threads which need to, can pre-empt the GC, while including provision to be sure those threads don't run out of available heap while doing so. Greg Bollella has been the real-time evangelist at Sun for the last several years. It's good to see Sun recognize the importance of real-time, industrial applications. If Java is to be truly pervasive, it can't just settle for the "80% solution" - it also needs to address the more arcane areas of the market. In reality, real-time systems are almost always connected to non- real-time systems, and you'd like to be able to use the same language and APIs across your entire multi-tier application.

The slot car contest (using real-time Java) was won by a group of German high school students.

Perrone Robotics' "Tommy" Darpa Challenge Vehicle was a big draw, the subject of a Tuesday Technical Session, and won a 2006 Duke award. The vehicle uses real time Java, running on low-cost, off-the-shelf hardware, including two JStamp controllers. Paul's basic approach is "simplicity" and it works very well. They spent $60,000 on the whole project, and went from start to finish in about 10 months. This is a fraction of the time and resources spent by other teams. Tommy 2 is gearing up for the 2007 Urban Challenge. Paul is definitely a "the cup is half full" kind of guy. Sun is now officially one of the sponsors of Perrone Robotics, so Java should be a major contender in the Urban Challenge.

So much for what many view as a robotic success story: the Aibo US$2000 electronic pets. I don't own one, so it's not clear how this dog "keeps diary with pictures and is able to read e-mail or blog content", but it's a bit surprising that a company with Sony's technical and marketing expertise (rootkits aside) could not make a go of entertainment robots.

It's always dangerous to draw general conclusions from a specific incident, so I won't. Other successes remain: the useful Roomba floor sweeper and the Wowee remote control toys, each of which have sold over 1 million.

Anyone with some specific insights into why Sony is giving up for now?

The inventor, Jason Winckler can be seen here with his frog Edna. This may be the same Jason Winclker who plays soccer for Tamarac Middle School.

It's an interesting idea, but can spinning a weight around really be more efficient than driving round wheels? The inventors suggest using other forces instead of gravity; perhaps in special applications (where such a force normal to the plane of motion is available) might be very effective. All I can think of right now is the "screen door in a submarine" - where the flow of water perpendicular to the screen would provide a huge force which is easily tapped. So there you have it - the basic concept for a novel submarine screen door cleaner robot. If you make a million from this idea, please send me a check.

Similar ideas have been around for a while: driving a square-wheel vehicle over a road composed of inverted catenaries, as seen here.

Steering such a vehicle is a bit complicated, since it easily interferes with the synchronization of the wheels.

And what easier way to experiment with your own version of this than with Legos(tm)!
http://news.lugnet.com/technic/?n=14950
http://news.lugnet.com/technic/?n=14970

It will come as no surprise that there are many ideas about what should be specified, and how. At the end of the presentations, it was proposed that we consider four different task force areas:
Middleware - with some sharing concerns about size and footprint
Component Profiles - including I/O point tagging
Service Profiles
Data Structures
(Don't ask me exactly what these mean since no is really sure.)

This feels like good progress to me, though there is nothing concrete quite yet. There is good interest among active participants, which means that there might actually be people to work on the standards committees. Based on this hopeful sign, OMG approved advancing the Robotis Domain Specific Interest Group to a Domain Task Force.

The next meeting is in Feb 2006 in Tampa, and there is still time to submit an RFI response, up until 3 weeks before the Tampa meeting. The java.net robotics community is planning to submit an RFI, based on the I/O point tagging idea, and maybe others. If you have some ideas, you are welcome to join this effort.

Is there an opportunity here or not? Java in combination with open source software has been very successful in scheduling and patient management in Brazil, and in fact, there was a fantastic BOF on this topic at JavaOne in SanFrancisco this past summer. One of the presenters, and the lead developer, Fabiane Bizinella Nardon received a Duke award for this project. There's some interesting discussion about the technology in this ServerSide thread. Brazil is planning to add medical records to this system in the future.

So, if there is a need, quantifiable benefits, the technology is available, and has been successfully deployed, what's holding back adoption of such applications? There was quite a bit of discussion of this following the BOF. It's an interesting question...

The machine can be folded in different ways to serve as a computer, electronic book or media player. "We designed the device to perform many roles," said Negroponte, who also heads the One Laptop Per Child nonprofit group. "Learning should be seamless."

No details yet on the display, but the laptop will run Linux, and use all open-source software. The idea is to put one into the hands of millions of schoolchildren, especially those in developing countries.

Governments must buy 1x10e6 units to participate in the program, which has sponsors including Google.

Let's hope Sun gets involved (are they already?) and provides a Java runtime -- what a great platform to showcase the benefits of Java.

Here's more, including some sketches of the machine, and the MIT website for the project, including these renderings.

The one-year contract calls for Aerosat Airborne Internet to conduct Airborne Internet flight demonstrations on FAA test aircraft at the William J. Hughes Technical Center. Data will be exchanged between the air and ground at 45 megabits per second, then passed from aircraft to aircraft, exhibiting a full range of communications that previously have required the use of satellites. The system is expected to transfer data at 45 megabits per second.

It's not clear to me who's doing what. There's the Aerosat company, and the Airborne Internet Consortium. Neither of these entities has anything fresh on their web pages. Then there's this reference at NASA:

Transformational Cost Reduction for Airborne Internet
Proceedings of the Fourth Integrated Communications, Navigation, and Surveillance (ICNS) Conference and Workshop;
August 2004; 17 pp.; In English; See also 20040139058; No Copyright; Avail: CASI; A03, Hardcopy; Available from CASI
on CD-ROM only as part of the entire parent document
This viewgraph presentation reviews the impact that use of an Airborne Internet will have on the aviation industry.
Passenger usage of airborne internet is explored as a possible revenue source for the airlines. AeroSat Corporation, a New
Hampshire based company, has commenced work on a project to demonstrate a novel low-cost, broadband, non-satellite
communications methodology for aircraft.

With nodes moving at 500 mph, with local routers on board, this could give new richness to the idea of a "store and forward" design.

According to the Boeing 787 web site, the Dream Liner will boast constant internet connectivity. We can only hope that it will be included in the price of the ticket and usable during takeoff and landing.

And if you are wondering what device to take to enjoy that connectivity, how about something like the Nokia 770 Internet Tablet?

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.

Without any protection, the passports might be "skimmed" – read at a distance by strangers as people walked through any public place. The weakness could allow a government to track someone, or allow a criminal to steal the names, digital photos and passport numbers of people on the street... Some critics even worried that the chip could act as a trigger to detonate a bomb when someone with an American passport walked by.

OK, so the State Department is trying to work around that little drawback, but you have to wonder why they can't afford a decent systems engineer to think these things through, first.

Meanwhile, the Electronic Frontier Foundation is leading the charge in filing comments on this half-baked idea. "RFID in passports is a terrible idea, period. But on top of that, the State Department is acting without the appropriate authority and without conducting any form of credible cost-benefit analysis," said EFF Senior Attorney Lee Tien. "It's asking Americans to sacrifice their safety and privacy 'up front' for a dangerous experiment that it hasn't even bothered to justify."

Perhaps the State Dept is following the lead of the state of California which is also getting hammered for proposing RFID in various ID cards (such as driver licenses).