Now blogging at diego's weblog. See you over there!

novell's strategy

It's been a couple of weeks since Novell's announcement that it was acquiring Ximian. Since then, it has posted its results for the most recent quarter, including a net loss and a number of layoffs. Some of the comments to my previous entry were interesting in that they mentioned Novell's "Linux moves" and I must admit that I was sort of blindsided by this. But as this interview with Novell's vice-chairman Chris Stone makes clear, the Linux play is something that Novell has been working on for quite a while.

Putting two and two together now, it seems that Novell wants to mount a strong challenge to a) generic Linux, by leveraging their NetWare brand and technologies, including Ximian's Red Carpet software and b) complement that with a competitive move against Microsoft at a higher level (UI, messaging) through Ximian products. In the interview it becomes clear that there is a nice interaction between what Ximian and what Novell has, with no overlap. Even the mono project (to create an open-source implementation of a .Net-alike environment) fits: Novel understands development tools, toolkits and environments quite well, since Netware and its Netware Loadable Modules (NLMs) where once an important development platform for networked services.

I have to say: it actually seems to make sense. And all of it, without hype or pretense. Amazing.

Categories: technology
Posted by diego on August 24, 2003 at 3:59 PM

openoffice for OS X... in 2006

Speaking of, er, alternatives. Got this on the #mobitopia channel yesterday: OpenOffice for Mac OS X delayed until 2006.

Plus the new version of OO by 2005? What?!? The Linux kernel itself has had delays, but this is too much.

Ridiculous.

And then we make fun of Microsoft for running over 2 or 3-year deadlines...

Maybe it's time for a renewed Corel to come up with some real competition for MS Office?

Categories: technology
Posted by diego on August 24, 2003 at 2:35 PM

now downloading...

...all 1.4 GB of Red Hat 9. The plan is to attempt a full, clean install of it on my Thinkpad laptop. No Windows partition whatsoever. No FAT or NTFS. Between IDEA, OpenOffice, Firebird, and clevercactus, I should have all I need. We'll see how it goes.

Categories: technology
Posted by diego on August 24, 2003 at 2:02 PM

what went wrong with columbia

An in-depth article from the Washington Post on the causes of the Columbia disaster back in January. Lots of lessons in it, in particular concerning communication between groups. And, isn't it amazing that the Shuttle lasted as long as it did? The Shuttle is clearly a great piece of engineering, its many problems notwhistanding.

Categories: science
Posted by diego on August 24, 2003 at 1:13 PM

diego's excellent symbian adventure, part two

Mobitopia

in which diego discovers that J2ME is a lot less, and a lot more, than previously thought

[Part one, notes].

I concluded in part one that native development in Symbian is a difficult proposition at the moment if your main concern is, like mine, minimizing development time by targeting as many devices as possible with a single code base. Creating 80-85% portable "native" Symbian apps is possible, but complex, and difficult for new developers. Because of this, for many applications, J2ME will be the way to go.

micro-Java, not micro-J2SE

J2ME is truly a "micro" version of Java, rather than a reduced J2SE (Here's a good take on the topic from Russ). When J2ME was first launched there was another "contender" called Personal Java (based on JDK 1.1.8) which we'll ignore since it's currently being phased out by Sun. To get some context, let's look again at the varieties of Java:

  • J2ME: a Java-based platform for small/memory limited devices.
  • J2SE: the Standard Java platform for desktop/mobile computing and above.
  • J2EE: Enterprise-oriented additions to J2SE, mostly in the forms of new libraries and APIs that plug into enterprise runtime environments.

J2ME targets areas that, unlike the (slightly) more uniform target of J2SE/J2EE, require support of widly different devices and capabilities, in terms of I/O, processing power, memory, and everything in between. As a consequence, J2ME is actually a set of specifications. Each specification targets a configuration, which then can be further defined by using it with different profiles.

And herein begins the acronym-fest. There are, currently, two main types of configurations. The CLDC and the CDC (not a bad name, in our virus-ridden times). The CLDC ("Connected Limited Device Configuration") is a low-end configuration target: cellphones, low-end PDAs, etc. CDC (Connected Device Configuration) on the other hand targets everything between the high-end of CLDC and the low end of devices that begin to support J2SE. (CDC + the Foundation Profile, the Personal Basis Profile and the Personal Profile define the equivalent of Personal Java but with more flexibility, which is why Personal Java has been discontinued, btw).

Now, both the CLDC and CDC reference VMs differ from the J2SE VM, and from each other. I'll be most interested in the CLDC VM (The KVM, or Kylobyte Virtual Machine), since it's the one used in most Symbian phones. The KVM is limited compared to a J2SE VM, not just in features (e.g., no advanced JIT techniques) but also in capabilities (e.g., floating point arithmetic is not required by the CLDC spec).

Talking about VMs is all well and good, but in the end what makes Java a platform is its libraries as much as it is its VM. So what about libraries in J2ME? Well, that's where the profiles come in.

profiles

Profiles add packages and classes to configurations, and each configuration has one or more associated profiles. And for CLDC, the most popular profile is one called the Mobile Information Device Profile or MIDP.

The MIDP adds basic networking, UI elements and minimal storage capabilities to the CLDC, and it is normally used for wireless devices (phones, PDAs, etc). Recently Sun announced the release of a new an improved MIDP, MIDP 2.0. But most Symbian phones implement CLDC with MIDP 1.0, and only one so far (the Nokia 6600) supports MIDP 2.0 (that I know of). SonyEricsson's P800 supports Personal Java, but that's a dead end since it has been discontinued.

In general, profiles try to use subsets of classes from J2SE. Whenever a class from J2SE is used, only methods already existing in the J2SE version can appear in the J2ME version (i.e., no new methods can be added). That's why the classes/packages some of what we already know from J2SE (say, java.lang.*), or are completely different (the storage classes in MIDP 1.0).

MIDP allows various optional packages such as the Mobile Media API and Wireless Messaging API which are included on some phones such as the Nokia 3650 and newer APIs such as the Bluetooth API on the 6600, as well as APIs in development such as 3D Graphics API for future models.

enough with the theory

After a while it's quite clear that the best way to do multi-device deployment with J2ME is to use MIDP 1.0. Using this profile, you can create Midlets, similar to Applets. Like applets, midlets are limited in their access to the local device, something that is even more visible because of the limitations of the MIDP 1.0 API (PDF, 171 KB).

Now for getting together a J2ME development environment for Symbian requires. To start with, I'll need Sun's J2ME WTK (Wireless Toolkit) either version 1.0.4 (for MIDP 1.0) or version 2.0 (for targeting MIDP 2.0). So I get WTK 1.0.4. Plus, let's say that I'd like to test with a Nokia simulator. I need to get the Nokia Developer's Suite for J2ME, plus an emulator such as the Series 60 Emulator/SDK (which for this phone includes cool things like the Bluetooth Java APIs--but careful! Since other MIDP 1.0 phones might not support that API yet).

The final element in all of this is the IDE integration. The steps necessary to go from cource to binary, and then to deploy it into the phone emulator (or into the phone) are Definitely Not Fun. So getting an IDE that will do them automatically is essential to keeping my sanity. The first option I looked at was CodeWarrior, but CW came integrated with WTK 1.0.3 (instead of 1.0.4) and didn't allow upgrading it. JBuilder 9 for Mobile Dev didn't have a trial download. Eclipse... well. Eclipse was an option :). But I thought that maybe IDEA, which I use for other Java development, had some Plug-In... and sure enough, there it was. Excellent. A bit of fiddling, and finally I was able to see my simple Hello World! application running in one of the default "phone covers".

Note: a big Thanks to Russ, who guided me in my search for tools and toolkits. Without his help, it would all have taken a lot longer than it did.

Now, this is all a lot more complicated than it needs to be, and Sun isn't necessarily helping matters. Hopefully the situation will improve in the near future, to make it easier for new developers to approach J2ME on Symbian platforms (and others, too).

native v. java

What is probably one of the most ridiculous limitations of MIDP 1.0 is its inability to access the device's store (e.g., contacts, calendar entries, notes, etc). This hugely limits the kinds of useful applications that can be written in Java (which in many cases will want to interact with phone data and services). And there's still no standard to access the bluetooth functionality (although it's coming, too).

At a minimum, creating a prototype with J2ME should be easy enough (once the development environment is set up) so that then certain Symbian devices can be specifically targeted with native development. J2ME apps can be targeted to devices beyond symbian, such as Palm. However, they have some serious limitations. If an application needs to access low-level functions or device data, native development is a must. Otherwise, J2ME might be a good alternative to simplify portability.

Categories: soft.dev
Posted by diego on August 24, 2003 at 9:12 AM

Copyright © Diego Doval 2002-2011.