Sunday, December 23, 2007

Java closures one more time

There is a heating debate on proposed language extensions, but the most debated is closures of course. Most people agree that the idea is great, but they cannot agree on the proposed implementations. I think the question is more conceptional. Java is not designed to be a functional language, so I doubt that these constructs can seamlessly be integrated into the language. So first we should discuss the benefits of this extension and if the benefits are much bigger than the drawbacks (increased complexity, more possibilities for code obfuscation and subtle mistakes) then we can talk about the implementation details. And if there are more drawbacks, we should throw the idea away and use a functional programming language (like Scala) for the appropriate tasks.
Personally, I do not think that Java has to follow the same path as C++. Using multiple languages on the same platform (JVM) is much more painless today as it has been in the past. Just think about the multi-language IDEs like Eclipse or NetBeans.

Saturday, December 22, 2007

Equinox with Spring-DM

I've just tried to deploy an Equinox framework with Spring-DM first time. I thought it will be much more difficult (Spring-DM is only RC1), but in reality it is very easy. First I set up a basic Equinox. Then I copied the JARs belonging to the Spring-DM into the plugins/ directory and created a config.ini that contains the following:

eclipse.ignoreApp=true
eclipse.consoleLog=true
osgi.clean=true
osgi.console=
osgi.bundles=org.eclipse.equinox.common@2:start,\
org.eclipse.equinox.registry_3.4.0.v20071203.jar@3:start,\
org.eclipse.osgi.services_3.1.200.v20071203.jar@3:start,\
org.eclipse.equinox.log_1.1.0.v20071203.jar@3:start,\
org.eclipse.osgi.util_3.1.200.v20071203.jar@3:start,\
jcl104-over-slf4j-1.4.3.jar@start,\
slf4j-simple-1.4.3.jar@start,\
slf4j-api-1.4.3.jar@start,\
aopalliance.osgi-1.0-SNAPSHOT.jar@start,\
cglib-nodep.osgi-2.1.3-SNAPSHOT.jar@start,\
spring-aop-2.5.jar:start,\
spring-beans-2.5.jar:start,\
spring-context-2.5.jar:start,\
spring-core-2.5.jar:start,\
spring-osgi-io-1.0-rc1.jar:start,\
spring-osgi-core-1.0-rc1.jar:start,\
spring-osgi-extender-1.0-rc1.jar:start

and voilĂ !

Saturday, December 15, 2007

JavaPolis - CBD

Component-Based Software Development is going to mainstream, finally. This is my conclusion based on my experiences from JavaPolis. I've seen good presentations from Bob Lee (author of Guice) and Peter Kriens who talked about OSGi. Moreover, Spring, EJB3 and component-based web development were mentioned in many presentations.

JavaPolis - closures

In the second conference day, Josh Bloch talked about closures. He provided an overview about the BGGA specification then he talked about his opinion. He basically thinks the same as me. Closures are nice (I really love declarative constructs!), if they are integrated seamlessly to the language, but the changes proposed by this spec are too intrusive. The most important concept behind the Java language is readability and closures will have a negative impact on it if they will be implemented this way.
He also talked about his proposal. It is more lightweight compared to BGGA, but far from seamless as it breaks the existing rules of the language (e.g. allows writing code blocks without enclosing methods - OK, I know, it is only a syntactic sugar).

Monday, December 3, 2007

Use the right level of abstraction

We are humans (most of us, I think), so we have our limits. To deal with them, we created a world of abstractions. Abstractions are so important we cannot live without them. We use them in our daily routine, they help us communicate things effectively or to do a wide variety of things.
However, humans make mistakes. Every time. Not using abstractions to solve or to communicate complex things is one of them, but a more severe mistake is to mix concepts from different levels of abstraction.
In my work, I am often facing this kind of problems. People describe a conceptual architecture and use technology-specific terms like web services, JavaEE, AJAX, for example. It is not only disturbing, it takes precious time and effort to clarify our concepts unless they lead to wrong architectural and business decisions.
Abstractions are our friends. Use them appropriately.

Monday, November 26, 2007

More on Android and OSGi

As I wrote in one of my previous posts, Android is not a Java platform. However, it is "Java-like" enough to manage to get OSGi on it. I am happy to see this kind of experimentation, because I seriously think that OSGi has a potential to bring the concept of component orientation into the mobile area.

Monday, November 12, 2007

Google Android - is it the way to go?

Yesterday Google has released an early access version of the Android SDK. For the first look, it is nice. It is Java-compatible (at least on source level) and it has a component model. Its API looks well-thought.
However, there is a big problem with it: compatibility. Android's Dalvik VM is not a Java VM. Its byte code is not Java byte code. It uses different packaging conventions, and so on. Therefore, if Android will be successful, mobile application developers have to deal with at least two totally different platforms.
I agree that CDC/CLDC and MIDP have several weaknesses and MIDP does not have a component model. But these problems can be addressed in a standard way (see JSR232 or JSR271 for example). Even the weak UI can be improved using existing solutions like eSWT.
So the question is open: do developers really need Android?

Thursday, November 8, 2007

MIDP3 - is it worth waiting for it?

In 2005 I was very interested about the MIDP3 proposal, but now, two years later it seems a little bit outworn. The expert group is not an active one, they published the early draft review only in September, this year. If this progress will not speed up, I hardly believe that the first MIDP3-capable phones will hit the market before 2009. And there are other promising technologies like OSGi and Google's Android. OSGi has already reached the mobile market, thanks to Nokia, and the Android SDK will be available in a few days. I don't think Android is based on OSGi, but it is developed by smart people, so I hope its architecture will be straightforward.

Saturday, October 27, 2007

Component management in CLDC

There are several widely-known frameworks (like Spring or OSGi) that make component management easier. In a CLDC environment, however, they cannot be used, because (for security reasons) class loading is restricted to the system classes and the classes contained in the MIDlet Suite. This means that components outside the installed application cannot be loaded in a standard way, so the JAR file must contain every component we want to use in the application.
But how could we extend or modify our application after its deployment? A possible solution can be to assemble the MIDlet JAR automatically on server side from the requested set of components and to transfer the resulted JAR to the phone. Of course this requires the user to stop the running application and re-start it after the upgrade, but in most of the cases this is an acceptable compromise.

Sunday, October 14, 2007

OSGi on low-end mobiles?

There is only one thing that prevents the wide adoption of OSGi (JSR232 - Mobile Operational Management) in the J2ME world: according to the CLDC specification, it is not possible to dynamically load classes that are not part of the system and the MIDlet JAR. (Of course reflection would be useful, too, but we can live without it.)
If we give up portability, however, there are several ways to work around this issue. The first and probably the most easiest is when you can access the class loader via OEM-specific APIs, but these APIs (even if they exist) are often public and well-documented. On Symbian phones there is another way (I've never tried, but I think it could work): you can write a native Symbian application which listens to a local socket and handles the serialized class sent by the MIDlet. Of course you need to have access to local sockets from your MIDlet, but most of the MIDP 2.0-capable phones implement this feature. This is somewhat similar to what ProSyst's management agent does in his product (mBedded Server CLCD Edition).

Java closures update

Here is a presentation from Neal Gafter. It is recommended for anyone interested in closures for Java.

Saturday, October 13, 2007

OSGi in mobiles?

I came home from Eclipse Summit 2007 yesterday. Unfortunately I didn't have time to attend the symposia, but anyway, the conference itself has been a great pleasure.
I've been particularly interested in three topics: Equinox (and OSGi in general), MDSD and of course, anything else that relates to J2ME. I've seen great presentations (and not so great, but interesting ones), but my absolute favourite talks had been given by Uriel Liu of IBM about eRCP and Gorkem Ercan of Nokia who talked about eSWT.
I have been telling for years that MIDP 1.x and 2.x are missing the most important thing: a well-defined component model. Yes, I know, that MIDP 3.0 is underway, but can the industry (and of course, the application developers) wait for years for the first MIDP 3.0-ready phones?
I think OSGi can be a very nice solution for this problem, and finally it seems that at least Nokia thinks the same. I just hardly wait for eRCP for series60.

Tuesday, September 4, 2007

Podcasts about software engineering

If you are looking for SE-related podcasts, you should really take a look at the Software Engineering Radio website.

Closures and Java

I've had some free time (first time for months), so I looked around the things I use daily. I found an interesting blog entry from Neal Gafter: Closures for Java. He wrote about the way closures will be (or might be) implemented in JDK7. I like the idea, but it is a double-edged sword. Nice, because the programmer can write very compact and expressive code (I always liked the expressivity of some declarative languages like OCL), but on the other hand it makes the code obfuscation very easy. Anyway, I hope this new feature will not affect the readability of codes written in Java negatively.
I personally interested to see constructs like this:

List foo = bar.select(some.boolean.expression.with.elements.of.bar);