Airlan San Juan's Blog

Airlan San Juan has been programming in Java since 1996, when he first tried out some applets and learned to love the Duke. He has not wavered in his simple but deep love for this language and platform since that time. He does mostly server-side JEE programming, but has recently made the jump to pervasive Java development in his work for RimLife Technologies. He has a Masters Degree in Plant Molecular Biology and wields an MBA when things get really rough. He also likes aroid plants, leafcutter ants, tropical climes, and his wife - not necessarily in that order.

Are Java desktop developers giving Java a bad name?

Unfortunately, I'm not kidding. When dealing with antagonistic parties, most recently in the Blu-ray arena, I noticed that their examples of bad Java applications almost always revolves around bad experiences with either Java desktop applications or applets.

We all know why applets got such bad reputations, but there really is no good excuse for Swing and the like to continue to give a sour aftertaste to users. I myself use Netbeans regularly, and although it has improved by quite a lot, there are still times when the thing slows to a horrid crawl when I use anything smaller than a 1 GB, 1.8 GHz box.

I deal with Java ME on almost a daily basis, and although the target of these applications are devices several times less powerful than desktops, I have yet to find a user who has complained as vociferously about them. Is this because user expectations for these smaller devices are less than their expectations for the performance of desktop applications, or is it because developers targeting more powerful machines have become unconcerned about code optimization, something that is foremost in the minds of smalljava developers?

BD-Java's Liar's Dice in Pirates of the Caribbean: Dead Man's Chest

There are only very few mass produced consumer products that can lay claim to being true works of art, and Disney's two new entries to the Blu-ray arena, Pirates of the Caribbean: The Curse of the Black Pearl, and Pirates of the Caribbean: Dead Man's Chest, may represent the best that high-definition discs today can offer, and as such can be said to have crossed the line into true art.

The care and love that went into the production of these discs are lovingly apparent in the beautifully rendered cover art and outer cardboard sleeve. It may be mere marketing fluff, but the inclusion of cardboard sleeves, and the use of artwork on the disc itself (which Sony in particular seems to have eschewed for its blu-ray offerings), give some weight and majesty to the actual product, kindling in the user a sense of heightened anticipation.

Each title is composed of two discs. A BD-50 disc that contains the movie itself and a BD-25 disc that contains all the extras. That's 75 GB of pure entertainment folks! :-)

For the full review, click here.

Microsoft looks beyond the PC and sees Deja Vu

I was watching Triumph of the Nerds earlier today because of my renewed interest in computer history after me and my wife visited the Museum of Computing History in California after JavaOne 2007.

One of the more interesting segments dwelt on the paranoia of Bill Gates, and about how he could never get it out of his head that the next "Microsoft" might arise at any time and eclipse the real Microsoft, just like his company had broken the dominant sway of IBM over the computing landscape at that time. IBM could have broken and consumed Microsoft easily at the beginning, but had focused on the wrong thing at the time, the hardware, while letting the operating system and software systems out of the bottle, so to speak.

Recently, it has become more and more evident that Microsoft is slowly but inevitably losing its dominant grip on the IT world, with Paul Graham even proclaiming that Microsoft is dead. If this is so, then perhaps Microsoft is not losing power because of Open Source, nor because of hyped products like the stripped down PC called the "Network Computer" in the TV documentary, but by history exacting its own revenge. After all, didn't Stephen King say that Ka is a wheel?

Just as IBM's undoing was the fact that its roots were in the hardware-oriented mainframes that it dominated, Microsoft's roots are tied inextricably to the PC, and this forces the company to see everything around it as extensions of the PC. Microsoft may see and try to anticipate the rise of small devices, but it always sees them in the end as simple peripherals of its own cash cows.

But perhaps ka is telling us that the new paradigm is that the network is in your hands? Perhaps the future is not office workers tied to their desks like industrial revolution automatons, but mobile individuals linking to and interacting with ad hoc networks of autonomous smaller devices?

As more and more "dumb" devices increase in computing capabilities, the dominant companies in those industries are leading the charge to change the way people interact with the "world's blood", the internet, and Java ME is by far the most widely-used application development platform in this arena. For example, cable companies are using Java ME to provide a development framework for millions of their set-top boxes, and are providing features to these small devices that heretofore were the exclusive province of PCs, such as picture viewing and games.

Ka, as the saying goes, is also changeable like the wind. There are some exciting times ahead indeed.

Fast-loading "Consumer JRE" == CDC?

The current Java.net poll asks people what was the most important announcement from the JavaOne 2007 general sessions, and the runaway winner of the poll seems to be the hints that Sun intends to introduce a Fast-loading "Consumer JRE". Now, wouldn't it be funny if this is based on Java ME's CDC?

As Sun's Hinkmond Wong notes, Java ME's CDC is:

If this were the case, then this putative resurgence in Java desktop development will be driven by Java's continuing explosive success in the small java arena.

The highlights of the Java TV sessions

Before I lay me down to sleep, here are some of the top items I thought were discussed in the Java Entertainment sessions (Blu-ray's BD-J and OCAP/cable Java):

• OCAP development (developing Xlet apps for cable) is just as interesting as Blu-ray BD-J development, albeit perhaps less "glamorous", but probably more lucrative in the short-term.
  
  
• If you can develop BD-J apps, then it is but a short step to OCAP development. That is, you can leverage your skill in either field to encompass the other as well.
  
  
• Because of their experience with constrained environments, Java ME developers can more easily jump to "Entertainment Java".
  
  
• The studios (and Sun) are pushing strongly to make the BD-J specs publicly available to developers. The BDA is, in the words of one attendee, "stupid".
  
  
• The cable industry is starting to roll out Java-enabled set-top boxes (OCAP and OnRamp) in massive numbers this year.
  
  
• Everyone agrees JavaTV did not pan out the way they thought it would years ago, but because of the convergence of several factors, they believe that this time "it's the real deal, Bill".
  
  
• There have been 200 Blu-ray titles so far, but only 6 or so have been authored using BD-J. Sun and the studios would like to reverse this ratio.
  
  
• Development of BD-J authored discs take longer to do, but the studios believe the benefits outweigh the costs, and that more sophisticated tools coming will significantly improve the process.
  
  
• There is a definite lack of easily accessible tools and documentation on both BD-J and OCAP application development.
  
  
• JavaFX mobile is the solution to world hunger and wars. Ok, maybe not, but I am becoming more convinced it will be very beneficial to the easier development of more powerful and artistically elegant SmallJava apps.
  
  
• Cable wants You. Blu-ray wants You. Don't ever believe serious Java is only for serverside or desktop applications.
  
  
• Bill Foote is a pretty funny guy. Bill Sheppard looks like that actor in "While You were Sleeping" with Sandra Bullock. Congrats to the Sun Team (and to the guest speakers) for a GREAT TV track!

I'm Mobile and Blu at JavaOne

Contrary to what server-side jockeys would have you perceive, or what Swing and SWT proponents would like to believe, the action at JavaOne is most furious in those fields that value the small and simple.

I'll be flying in on Wednesday and will be attending the TV Track, which features sessions and talks on Blu-ray (BD-Java) and Java on Cable, but for those with an itch to switch to the SmallSide, this JavaOne has some really outstanding sessions available.

The JavaCard platform continues to converge with the mobile end of things, and I particularly am bitter that I could not attend the session called Free Mobile-to-Mobile Money Transmission Revolutionizes Trade Between the Poorest in Africa, which I think is pretty interesting and socially relevant to boot. Wish I could meet the guy responsible for this!

The introduction of Sun SPOT wireless sensor networks this year is probably one of the more notable news to come out of the Java ME world, and I've written about them in earlier blog posts. I'm just hoping they don't announce these as the Device of Show, cuz' we all know that ain't a good thing ;-)

As always, there are way too many mobile Java ME options available at JavaOne, but I think one of the most important events for CLDC/MIDP this year is the coming of MSA devices (such as the Sony Z750), and so a quick look at sessions tackling this umbrella architecture that will hopefully help de-fragment the next-generation Java ME mobile devices might be invaluable for pervasive Java developers.

There's even a smidgen of hope coming to that poor brother of CLDC/MIDP. Hinkmond Wong managed to get F3 (Form Follows Function) running on a CDC device, and the long-awaited JSR 249 might finally kickstart some life into this somewhat neglected area of Java ME. No specific session on this, but perhaps these more general sessions, mostly on the related JSR 248, will shed some light into this potential success story for mobile CDC.

Finally, take some time to drop by the Mobile and Embedded Community social gathering at the Thirsty Bear on Wednesday night. I'll most probably drop in if my flight cooperates.

Also, for those people interested in Blu-ray Disc Java (BD-J), I'll be blogging like crazy throughout the day on Thursday.

Darn, I am SO excited about my first JavaOne ;-)

Java midlet shepherds to my PS3 and aroids

Letting your Java app monitor your HOT playstation 3 and even your beloved plants is easy to do when you have alert midlets to shepherd the way. By passing the information to a hosted Java EE webapp, anyone can remotely monitor the PS3 and plants from anywhere using a browser.

Click here to view some dynamically updated graphs showing the changes in temperature and light captured by my Java midlets.

The set-up I created is fairly simple, as you can see from the images. I have a base-station SPOT connected to my desktop in the computer room, and I placed two different SunSPOT wireless sensors some distance away from this. One is about 2 m away, nestled snugly close to my Playstation 3, while the other I placed about 15 m away, held aloft beside of of my aroid plants by three barbacue sticks.

I placed two different Sun SPOTs running my midlets in two different places to monitor light and temperature. One is held aloft besides an aroid plant, the other sits right next to my idle Playstation 3. Click on thumbnails above to view detailed images.

The two midlets deployed into each Sun SPOT basically measure the light and temperature of their surroundings every 5 minutes, then relay the information to the desktop base-station, where it is then sent to a Java EE web app running on a remote host server. You can view the sample code for these midlets in the previous notes.

A SPOT socket proxy relays the midlet messages to a hosted java server web application.

I can remotely monitor this dynamically-generated information by querying the Java EE webapp, which displays it as graphs generated by an integrated JFreeChart. If you are interested in viewing these graphs, click here.

Some bugs in the system though in that the Sun SPOT devices or the socket proxy on the desktop after awhile starts sending data erratically to the Java server application, or even stops sending altogether, so I guess this is a work in progress :-)

Let your Java app "feel the rain" on its skin

Your journey begins with the task of gently introducing your Java applications to the realities of the physical world, an area that normally exists beyond the confines of the limited and rather myopic worldview of the typical Java midlet.

In this paradigm that is exemplified by the new Sun SPOTs, a midlet without a way to "feel the rain" on its skin, is like a gourmet diner who is finally allowed access to a connoiseur's nirvana, only to find out that he has a cold and cannot taste any of the offerings placed before him.

As one singer put it in more elegant fashion:

Feel the rain on your skin
No one else can feel it for you
Only you can let it in
No one else, no one else
Can speak the words on your lips
Drench yourself in words unspoken
Live your life with arms wide open
Today is where your book begins
The rest is still unwritten

- Natasha Bedingfield

You will help write this book, and your Java applications will finally be able to "feel" things that they could not have done otherwise.

As a first step, we'll allow our new midlet to sense temperature and light.

The first thing you need to do is to create a Midlet skeleton from the demo applications that are included in the Sun SPOT kit. It is ok to start from scratch if you want, but why struggle when someone else has already made the path for you easier? I used the BuiltInSensorsDemo demo application and closely studied the source of the BuiltInSensorsDemo class. A quick look at the short source code will immediately assuage any fears by mobile developers that the Midlets here are vastly different than those in mobile devices.

For example, the same life cycle templates are in there:

    protected void startApp() throws MIDletStateChangeException { 
        try {
            run();
        } catch (IOException ex) { //A problem in reading the sensors. 
            ex.printStackTrace();
        }
    }


    protected void pauseApp() { 
    }


    protected void destroyApp(boolean arg0) throws MIDletStateChangeException { 
    }

The one big difference of course if that this Midlet uses some quite unusual libraries.

import com.sun.spot.sensorboard.EDemoBoard;
import com.sun.spot.sensorboard.io.IScalarInput;
import com.sun.spot.sensorboard.io.ITemperatureInput;
import com.sun.spot.sensorboard.peripheral.ITriColorLED;
import com.sun.spot.sensorboard.peripheral.ISwitch;
import com.sun.spot.sensorboard.peripheral.ILightSensor; 
import com.sun.spot.sensorboard.peripheral.LEDColor;
import com.sun.spot.util.Utils;
import java.io.IOException;

import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;

The easiest way to get started is to simply copy that demo application folder, modify the contents and rename the folder, then open the lot using Netbeans. In this case, I simply copied the entire BuiltInSensorsDemo folder and renamed the new folder to "PickyMidlet". I then changed several things in the folder to reflect the new name and make sure it compiles and deploys correctly. In the project.xml file in the nbproject folder, rename the BuiltInSensorsDemo to PickyMidlet. I also changed the name in the build.xml file to reflect the change in nomenclature. FInally, in the resources/META-INF/manifest.mf file, change the name of the midlet to reflect the new name.

Now, open Netbeans 5.0 and go on over to where you have your "PickyMidlet" folder. Open the project and Netbeans will show the new project in the left hand pane.

Now, safely rename the original midlet to the new PickyMidlet name via Netbeans' refactoring. You can obviously leave the same name, but just for the sake of differentiation it would probably be a good idea to change the name.

Set PickyMidlet as the main project and then clean and build the project. You should be able to compile the project with no problems as this is based completely as of this point to the old demo Midlet.

The original midlet cleverly uses various LED lights to convey changes in movement, temperature, and light intensity to outside observers. However, I could do without the blinking lights and so I modified the original code to make it simpler for demonstration purposes. I also personalized the Midlet by having it respond to variations in temperature as a person might. As you can see from the code sample below, getting values from the sensor boards are easy and simple to do.

You can click here to continue reading the guide to this simple procedure.

Postcards from the edge of Javaland

I could hear the crickets chirping, or at least the hum of the air conditioner fans as they strove to cool the bodies of several hundred enthusiastic and jumpy Java developers crammed into an auditorium of Google.com's New York City office. They were all here to listen to Rod Johnson talk about the Spring Framework, and I had just asked whether anyone knew about BD-Java after the host had graciously allowed audience members to ask general questions.

Granted that I was in a roomful of server-side jockeys who may not know, or care, that Java exists beyond the confines of a Tomcat or Weblogic server, but the profound silence that greeted my query was surprising anyways to a Pervasive Java enthusiast like myself, who lives and breathes CLDC and CDC and all the other acronyms that have cropped up in MicroJavaland.

So, why the recent excitement on my part? Well, quite a lot of new developments have occurred since Sun and some big CE companies had touted BD-Java as the next big thing during the last couple of JavaOne conferences.

For one thing, more and more Blu-ray titles have been released and authored using BD-Java. The relatively primitive and amateurish BD-J game in Speed in late 2006 has given way to the polished and engaging interactive features in Disney's Chicken Little and Digital Leisure's Dragon's Lair this year. Going forward, BD-J will show up in some interesting titles coming in late Spring, including Disney's Pirates of The Caribbean: The Curse of the Black Pearl, where it will power an interactive in-movie feature that presents facts on-screen about the legends and lore of pirates, as well as in Pirates of the Caribbean: Dead Man's Chest, which features Liar's Dice, a single-player game shot in live-action HD video.

The picture quality in Dragon's Lair (Blu-ray) is strikingly brilliant and often stunning. © Digital Leisure Inc.

The Playstation 3 has also started shipping worldwide, and it has, as promised, tilted the balance strongly away from a competing format called HD-DVD towards the Blu-ray high-definition disc format. HD-DVD is backed by Toshiba, Universal, and Microsoft, and is authored using a Javascript/XML framework called HDi. The Playstation 3, and Blu-ray players from Samsung, Panasonic, Pioneer, Phillips, Sony, and others, are capable of running BD-J apps (called Xlets from the Personal Basis Profile) instead. Although hardware sales of players for HD-DVD and the much more expensive Blu-ray players were neck and neck throughout the latter part of 2006 (48% Blu-ray versus 52% HD-DVD), there were reports that HD-DVD titles were outselling Blu-ray titles by significant margins, due mainly to the fact that it had a three-month lead, and early adopters of the HD discs were leaning more towards the former format. However, this lead by the HD-DVD camp has quickly evaporated in 2007, and BD titles currently outsell HD-DVD titles every week by commanding ratios of at least 2:1, and sometimes by up to 5:1. Casino Royale (Blu-ray) also became the first HD disc to break the Top 10 ranking of DVDs in Amazon.com (it peaked at #6) and the first HD disc to ship 100,000 copies (and sell roughly 50% of that its first week), which helped the 9-month old Blu-ray format beat standard DVD in this important milestone (it took the DVD version of Air Force One 11 months to reach the same level).

BD-J has also joined the ranks of MIDP apps ("Midlets") and perhaps Applets as one of the few technology buzzwords that have started to become common terms for the everyday consumer. I am a member of various Audio-Visual discussion forums, and regular threads discussing the merits and problems afflicting BD-J have been cropping up like wild toadstools lately. I must admit that it gladdens my JavaHeart to see regular joes pontificating like hardened coders on BD-J and other Java ME subjects. They may not know exactly what BD-J is, but by golly it better not stand in the way of them watching their favorite movies in glorious high-definition.

This is not to say that there are no problems with the current situation, because there are quite a few. From a developer's perspective, the major problem is that it is not at all easy to dive into the world of BD-J coding because of several factors. First, although BD-Java is based on MHP/GEM/Havi/JavaTV APIs that are freely available for inspection around the web, and are even the main subjects of several books, including Interactive TV Standards: A Guide to MHP, OCAP, and JavaTV by Morris and Smith-Chaigneau, and HAVi Example By Example: Java Programming for Home Entertainment Devices by Gibbs et al, the Blu-ray specific API information must be leased from the BDA (Blu-ray Disc Association). In addition, the current slew of authoring tools for BD-J retails at prices in the higher five figures, princely sums that are quite beyond the reach of individual developers. For a more detailed look at problems facing first-time developers to BD-J, David Foster of Digital Leisure Inc., the producers of Dragon's Lair (Blu-ray), has given an interesting account of his personal experiences with the intricacies of this new CDC technology.

There are also problems cropping up on the consumer side of things, mainly because of the seemingly glacial pace that hardware manufacturers have taken in implementing the various advanced BD profiles (BD-Video 1.1 and BD-Live) into their players. Because such key features as network connection, PIP (Picture-in-Picture), and local (persistent) storage were not made mandatory from the very beginning, the result is that many current Blu-ray players may lack the capability to use more advanced BD-J features in the future. This is an extremely hot topic among A/V enthusiasts right now because there are rumors that some studios have delayed the release of Blu-ray versions of their titles because they are waiting for these features to become mandatory.

Notwithstanding these problems though, the future of BD-J looks bright, and there are several major efforts to keep it in the spotlight. This year's JavaOne conference will feature a special track of sessions and events targeting developers interested in gaining an understanding of digital television software technologies and markets, and a Java SIG group focusing on TV and blu-ray Java called Blu-Dahlia was started by Bill Foote and Bill Sheppard of Sun Microsystems.

June 2007

Search this blog:

Categories

Archives

June 2007
May 2007
April 2007
June 2006

Recent Entries

Are Java desktop developers giving Java a bad name?

BD-Java's Liar's Dice in Pirates of the Caribbean: Dead Man's Chest

Microsoft looks beyond the PC and sees Deja Vu

This work is licensed under a Creative Commons License.