All the small things

The release of the iPhone SDK has been some weeks ago and I actually had time to think about the whole hype thing. Of course, one of my big disappointments was that Java is most likely not going to make it on the iPhone. I actually understand the concerns regarding the UI, but actually I could live quite happily with a headless version. Ok, I have to admit, this wouldn’t be a standard conform JVM, but when I look at current environments, I really have to ask myself, why such a version doesn’t already exist? I mean a headless JVM version, only designed to work on servers for instance. Maybe just as a profile, nothing distinct, but optimized for 24/7 server scenarios. I convinced that in such an environment OSGi could play an important role even on iPhones. Just forget for a moment that the current license of the SDK doesn’t allow background processes as well as “other languages” than Objectiv C and focus on the opportunities. OSGi offers a great componentization approach, which the new “Universal OSGi” RFP is trying to port to other platforms. Especially the expressiveness of the meta data provided by a bundle is very interesting for other languages as well. Of course, the question is to what extend is this possible, does it make sense to define a subset of functionalities, which everyone can met or does this make the whole idea worthless? Questions, at least for me, not easy to answer yet, but I am very interested in the outcome of the work of the expert group.

Now, despite the existence of Java or even OSGi on an iPhone, what are these new, cool and so desired applications, we can’t wait to see on our hand held devices? I gave it some thought and here is the list of “killer apps” I would love to see on the iPhone sooner or later.

• Google Maps with GPS: No need to explain that much, this is THE application I am waiting for on the iPhone. No more expensive navigation software extensions for different countries will be needed anymore. You always have it at hand! (Ideally with offline capabilities to enable the use even withouth internet access.)
• Instant Messaging: Something like fring is due for a long time. You never need to be offline, no need for expensive “Text Messages”, just write your Messages, without length limitations and even with pictures and other gimics. Not to forget features like Voice over IP via Skype for instance.
• Environment controller: Let’s call it the ubiquitous remote. You can not only control all your HIFI and TV equipment with it (ok, we need blue tooth here, but maybe in 3-5 years…), but also open your garage door, the car, dim the light in the room (the one where you are, based on location information) or your favorite computer game with the gyroscope in the iPhone. Why having tens of different applications, if one can do everything for you?
• Black box: Ok, this can be a good and a bad thing, I have to admit, but looking at it from a purely exploratory possitiv perspective, an iPhone can be used as a sort of a black box in case of accidents. Later, officials can be enabled to reconstruct the precise movements of the iPhone. A little bit like a flight recorder in airplanes. One can record where, with which speed, which movements the fon was moved.
• Emergency tool: Not only a phone, which calls 911, 110 or what ever the emergency number of the country you are in is, but also a live safer for others – with applications helping people to apply first aid step by step, with pictures and animated videos to show how it is done properly. An application capable of automatically submitting emergency data to the doctor nearby in an ad-hoc network as soon as the doctor authorizes himself.
• Interactive Games: Games are nothing new – no big deal about it. Something, which is new, are the kind of games introduced by the Nintendo WII. Equipment like a gyroscope or a position tracking system are new and animate people to actually play together. The iPhone can push this even further. With a mobile device, you can play anywhere with everyone, thus making playing a social experience. Just imagine a game you can play on your way to work, with someone in your train. Based on an adhoc-network, you probably don’t even now the one, but still can play against that individual. Even better are big sport events. Here thousands of people can be enabled to play against each other in some sort of a parallel game. A very interesting field, I have to admit. So many things are involved or have to thought about here: how to handle ad-hoc networks, how to negotiate the right score between two parties and avoid cheating, how to handle online/ offline behavior, how to secure the communication and manage trust in spontaneous networks,… Maybe I have to elaborate on this one in a later post, this topic just fascinates me, although I actually don’t play games.
• My Personal Buddy: An application, I am imagining for years now. An “intelligent” agent helping me to organize my life, by proposing appointments according to my daily behavior, my favorites and so on. I think Peter Kriens once wrote something more detailed about some of the functionalities I would expect.

As you probably noticed, I am convinced of the success of the new iPhone and I already have some ideas, what might come in the future. However, the iPhone is surely not the answer to all questions and still has several drawbacks, but it is certainly a move in the right direction. Let’s seen what’s coming up next.

Stay tuned,
Mirko

When first diving into OSGi, you probably don’t notice fragments at all. After a while, once you become familiar with the concept and the main parts of the spec, you start looking into ways to accomplish things, which were fairly simple done in plain Java, but might be really painful in OSGi. By then the latest, you’ll find them in the spec and they are really tempting in so many ways. Before I elaborate on that, let me just summarize the main features of fragments in order to give everyone a chance to follow.

Fragments, like bundles are just simple jar files with additional manifest headers; actually they are almost the same as the bundle manifest headers. At first glance, bundles and fragments look alike. Both are jars by definition and specify additional manifest headers. The huge difference is that a Fragment is like virus. It needs to be attached to a host in order to function. During the attaching process of a fragment to a exactly specified host, the manifest files were logically merged if not conflicting and the dependencies are being resolved, if possible (if not possible, the fragment will just not be resolved and attached). After that, the resources in the fragments are loadable with the host ClassLoader, thus the Fragment does NEVER have its own ClassLoader (but its own ProtectionDomain if not an extension fragment, but we are not going there). Actually, there are quiet a few more things worth mentioning, but to understand what I am training to explain here, it should be fine. If something beyond that is needed, I am going to explain it as we go.

Now, that we know, what a Fragment is, what is it actually for where is the problem. Well, the purpose as described in the spec is pretty straight forward and logic. For customization of your bundle depending on the environment, often only very little, yet delicate changes are sometimes necessary. This can be a simple localization issue of your translations or the packaging of system dependant libraries like “dll”, “.so” or “.dmg” you are invoking in your bundle code. Depending on system properties like “os.name” or “lang” you can let the container decide, which bundles/fragments suit your environment – so far so good.

Now, where might be the problem with that? To motivate this, one has to keep in mind that one of the strengths of OSGi is its encapsulation model. Based on this declarative, strong and rigid component definition, OSGi became a very robust deployment format/ environment. A bundle or component is very expressive about its requirements and features, which makes it easy to handle them. Now, with Fragments attached to a host, the behavior of the host might change, without any changes of the version information within the bundle. The former strong formalism is now softened. Especially if you look into Software Product Lines, where you have thousands of bundles in many different versions, dynamically wired together, you can’t test every combination effectively; you have to be sure, that you can rely on a certain behavior, enforced by the component contract, which is in this case no longer possible.

The question is how a fragment potentially manages to violate the component contract. Concerning this question, there has been a discussion on the OSGi-Dev list this week. Just imagine you have a bundle X with three packages a, b and c. Fragment F defines one Import-Package: b. Another Bundle Z provides the package b as an export and has c internally available (see figure).

We further assume that bundle X defines in package a only a BundleActivater loading a class from package b. Now we have everything set, to begin our small example. Starting the bundle X (with the attached fragment F) will result in loading the BundleActivator. The activator then will try to load the class from package b. Depending on the OSGi class loading strategy, the class loader first looks into the import statements of the host, if there are no entries (like in our case), the fragment is queried for import statements. This time we’re successful and the ClassLoader is trying to obtain the class from another bundle. Here we have our problem. The behavior of X can be altered by providing another implementation of package b as an export of bundle Z in the container (it has to be a different bundle – import your exports in the fragment won’t work in that case). The problem here is not, that the package is replaced with an alternate implementation; this is pretty common in OSGi with the best practice of importing your exports. The crux here is that there is no statement of imports and the actual developer of the bundle might not have intended to replace the package at all.

Of course this behavior has advantages as well. Consider you have a OSGi-efied bundle, which unfortunately isn’t converted perfectly, so you still have some Class.forName() calls in one minor package. The license however doesn’t allow you to touch the bundle at all, but now with the help of a fragment, you can inject your own code as described above. Not sure, if one really needs that, but you can.

Something else you can do with fragments is to emulate a global class space. I was actually working in on a project, where we had a pretty monolithic software in terms of the core DTOs. Although “Extensions” were easy exchangeable and loadable with different class loaders, the core data transfer objects were not, unless you serialize them, which of course was out of discussion. Now imagine, you have one core bundle, where every extension contributes its DTOs in form of a fragment, you end up with a global class space for all your DTOs. Nice on first glace, it becomes nasty soon, when you think about the implications. First of all, versioning is now only very limited available. Second, every new deployed fragment lets your whole application refresh, because everything depends on this core bundle and every fragment is attached to it – at least for me, no desirable solution.

The finish this (actually pretty long) post today, I can think of one last case, where it can help. Imagine, you have multiple versions of a package available and your bundle requires a distinct version, because of strange constraints, but can’t make these imports explicit, but dynamic with DynamicImport-Package, normally you don’t have a chance to provide a distinct version. With a fragment, you are able to inject a distinct version before the DynamicImport-Package definition is used in the class loading strategy.

However, I tried to show different ways of using fragments, besides the usual ones of providing translations or system dependant libraries. Everyone can of course do what ever he or she wants, but in my opinion, all these alternative usages are extremely dangerous and I can’t think of any sane reason to use them in real projects. Just because you can do something doesn’t mean it is go to do so. I gave it quiet a thought and I actually came to the conclusion, that the class loading behavior should be changed in a way that, no matter what happens, the bundle class path lookup should be performed entirely, before any attached fragment is asked. This would be a valid solution to prevent violations of the bundle contract in my opinion, but well… these are just my 2 cents. Take it or leave it

–
Mirko

After revealing details of the new SDK for the iPhone last Thursday, Sun decided to develop a JVM for the iPhone after Apple showed no intention to do so. Well, for some of you, this is not much of a deal. Java is available on many mobile phones, why care about one more or less? From my point of view, this makes a huge difference. OSGi, actually developed to improve the mobile sector and fight the short comings of J2ME, never really succeeded due to the lack of computing resources like memory or CPU power on former cell phones. With the iPhone, things might change.

(more…)