blog::o->lok

Unit testing reloaded: Java Path Finder

2011-03-19T15:13:00.003+01:00

Unit tests are good. Sometimes we hate them because of the work overhead they require, but almost everyone agree on their usefulness. So the question is: what could we do to eliminate (or at least minimize) this overhead? The answer is quite simple: we should minimize the number of separate unit tests. It is not impossible, since most of the test cases are based on simple assertions, so they can be easily integrated with the source code. In order to do this we need a simple but powerful notation to express the constraints, since assertions scattered across the source statements obscure the code. Annotations are very helpful in this case. We can create annotations for classes and field variables as well as input parameters and return values of operations (we are talking about the design by contract idiom).
Defining annotations is easy, but it is very time consuming to write a processor for the processing of the statements written in these annotations. Fortunately, we do not have to implement anything, we can use the Java Path Finder. Its jpf-aprop module fully supports the design by contract idiom.
JPF is a real multi-purpose tool, and it has a moderate learning curve. Unfortunately, the online documentation is a bit outdated, but there are many publications and examples that can be downloaded from the site, so an average Java programmer can use the tool without difficulties.

More powerful type casts?

2010-12-24T22:17:00.011+01:00

Long time without a single post... Sorry, I've been very busy this year.
There is an interesting discussion about a new, Java-like language in the Apache Harmony developers' mailing list. Yesterday someone proposed a new language feature, a more powerful type cast that provides direct access to the overridden methods of parent classes. Lets see an example:

class Foo {
     void foo() {
    }
}

class Bar extends Foo {
     void foo() {
    }
}

As seen, we have two classes, Foo and Bar. Bar extends Foo and overrides the method foo() declared in its parent.

Bar bar = new Bar();
bar.foo();

If we instantiate Bar, and call foo(), the runtime will execute the method foo() declared in Bar. The proposed feature looks like a normal type cast

((Foo strong) bar).foo();

but forces the runtime to execute the method foo() declared in Foo instead of Bar.foo().
At first sight, this feature seems harmless, but at next, it is a potential disaster. If the runtime allows this, it may cause serious side-effects, if the overriding method contains code that changes the state of the instance. Moreover, the overridden method may not be designed to be called from the given context, so any developer could (even unintentionally) break the design rules of any API by a simple type cast.
On the other side, I do not see any advantages of the proposed feature.

Runtime exceptions: the good, the bad and the ugly #1

2009-12-17T16:44:00.000+01:00

Reading others' source code is useful, but sometimes very annoying. Programmers often code routinely and this may lead to subtle but evil mistakes. Handling null references is a good example. I often the following piece of code:

if ("foo".equals(bar)) {
doSometing();
}

This kind of expression can be useful in cases when bar is allowed to be null, and we don't want to write an explicit check for it. But it should not be used when bar should not be null, because it eliminates a NullPointerException and no one will know about the error until the first failure.

Programming Model for OSGi DS

2009-11-20T09:44:00.000+01:00

For most of the applications, the use of OSGi Declarative Services for wiring components is more effective than the traditional lookup-based methods. But if we think about the programming model, there are some questions that need to be answered.
First, we have to decide, how to describe our components. We can choose between the standard way (XML descriptors referenced by the Service-Component property of the OSGi manifest) and Java annotations (requires a 3rd party API).
XML descriptors are great things, we can declare the provided and required interfaces of our components as well as their configuration properties and factories for instantiating more than one component of the same type. Nice and intuitive, but it comes with certain cost: we have to duplicate information (component and interface declarations, bind methods). This may lead to programming mistakes causing runtime errors like uninitialized components, null references, etc.
We can prevent duplication by annotating our Java classes with all the information the classes do not contain. We can mark provided interfaces and bind/unbind methods. Additionally, we have to provide ways for storing component configuration. For this task, we can use something like the Preferences Service or the Configuration Admin Service.
Using annotations, we can minimize the number of program faults caused by missing or inconsistent component descriptions.
As long as we are allowed to use annotations, this solution could be better. But be aware, annotations are polluting the POJO model, because of the coupling between the annotation API and our component.

OSGi - Why do we need it?

2008-11-08T14:10:00.000+01:00

I heard this question many times. I usually reply quickly in a few sentences, but I agree that OSGi deserves a more detailed answer.
Let's start with the basics. The Java Language Specification does not mention higher-level abstractions, like components. It follows the OO concepts, in which the highest level of abstraction is the class. Why is it important? There is a difference between a class and a component. A component specifies its provided and required interfaces, while a class is not able to do it. Of course, a class can contain public members that implicitly form a provided interface together (and we can extract them into a Java interface to make things more clear), but it is not a formal specification of a provided interface. Specifying the required interface is more problematic, it can only be extracted from the class using static analysis. It is far from being a formal specification, too.
This 'minor' weakness of the language makes real component-based development impossible without building an additional abstraction level at the top of classes and interfaces. We can call it a component model.
At the very beginning, Sun specified one called JavaBeans, but it was too simplistic and it was intended for building graphical user interfaces, not complex systems.
As Java became a mainstream language, complex tasks required sophisticated component models. It was the time when EJB was born. At the same time, many projects (Spring, PicoContainer, etc.) tried to address the same need in a lightweight fashion, but they all have two common problems: handling versioning and dynamic loading at component-level.
As the internet-boom was over, EJB lost popularity because of its complexity and price (application servers were very expensive at this time), and lightweight frameworks became more popular. OSGi was created at this time to address the same need, but it treated components as first-class entities (they called them bundles). This resulted in a complete component model that made component-based development possible. Furthermore, OSGi defines standard services, like logging, package management, etc. that simplifies the job of developers not wanting to reinvent the wheel.
There are some important consequences of having a good component model. First, a well-written component is reusable. With the introduction of component versioning, runtime library conflicts (JAR hell) can be eliminated. Second, component instances can provide services and this, together with dynamic component loading and component-level dependency management makes service composition possible.
To wrap it up: OSGi is a natural extension of Java, because of the nice component model and its dynamic nature. We really needed it for years when we were forced to manually handle all of the problems solved by OSGi in each and every project.

GITEX impressions

2008-10-27T11:17:00.000+01:00

GITEX was finished last week. We were there as exhibitors to make our company's NFC-based products more popular. I think we were quite successful in it, but it's not what I want to say. I want to talk about a few interesting observations I made.
Perhaps the most important of these is related to the way we do presentations.
I had to get experienced that conventional demos are not very effective in exhibitions where we only have few seconds to raise interest. Forget about slides filled with textual information. Present an idea that can be visualized; a picture, a movie or a diagram, with only a few words. Remember the old saying "A picture is worth a thousand words."
My second thought is about documentation and brochures. Very few people want to read long descriptions, no matter how useful they are. Prepare a very short overview section in which you write about the most important things you want to express. In case you have more to say, the next section can contain more details. Then, at the end of the document, you may summarize the most important things once again in a separate section.

Architecture diagrams, once again

2008-04-15T11:33:00.000+02:00

A few months before, I wrote a blog entry about architecture diagrams. I mentioned that UML can be used for describing architectural concepts, but I didn't write too much about that. Perhaps it was a mistake, because you might think, that UML is a good choice for these kind of tasks. Bu it's not.
To describe an architecture, we need a way to describe entire systems, not just components and connections. UML has deployment diagram, of course, but it lacks well-defined semantic meaning behind diagram elements. It means, that a deployment diagram is not an unambiguous description of a system, since different people assign different meaning to the elements of a diagram.
There are some more formal approaches, like FMC (Fundamental Modeling Concepts). Its concepts are nice and well-founded, but only a few people use it, unfortunately.

Textual DSLs and diagrams

2008-03-29T12:07:00.000+01:00

While it seems fairly trivial to generate the graphical representation of a model built using a textual DSL, many people (including me, until now) do these two steps (modeling and diagramming) separately. Perhaps they don't know about tools that can greatly simplify this task like Graphwiz. It is really a very nice tool. Using a simple textual DSL provided by the tool for diagramming, wide range of graphs can be generated, even very complex ones. Lets see a concrete example:


digraph Components {
  Container [shape="box"];
  Component [shape="box"];
  Port [shape="box"];
  Service [shape="box"];
  RequiredService [shape="box"];
  ProvidedService [shape="box"];
  Interface [shape="box"];
  Container -> Component [label="manages", headlabel="*", arrowhead="open"];
  Component -> Port [label="has", headlabel="*", arrowhead="open"];
  Component -> ProvidedService [label="provides", headlabel="*", arrowhead="open"];
  Component -> RequiredService [label="requires", headlabel="*", arrowhead="open"];
  ProvidedService -> Service [arrowhead="empty"];
  RequiredService -> Service [arrowhead="empty"];
  Port -> RequiredService [label="points to", headlabel="*",    arrowhead="open"];
  Service -> Interface [label="defined by", arrowhead="open"];
}

and here is the generated diagram.
So my point is, that (with minor modifications on the templates used for code generation) nice diagrams can be generated; there is no need to use a separate diagramming tool for these kind of tasks.

Components and Java classes

2008-03-27T01:36:00.000+01:00

People often misuse words that have a well-defined meaning. This is the case with the word "component" which is often used as a synonym for a Java class. In reality, these artifacts are very different. Component is an architectural concept whereas the Java class is an implementation artifact that can be part of the programming model, but might not be used in the conceptual architecture. Moreover, the Java language has no notion of component, so components can poorly be represented using only the elements of the language, without annotations or external configuration (but remember, these are not part of the language, only extensions to it).
Let me explain that briefly. Components should express their inter-dependencies, so every component has to declare its provided interface and required interface (these are not Java interfaces, only architectural level concepts).
In Java, a class can declare its provided interfaces (these are the implemented interfaces), but can't declare its required interfaces explicitly, since there is no language element for it. Only implicit declaration is possible, but it may not be enough if we want to express component dependencies in the programming model.

JUM 6

2008-03-20T20:09:00.000+01:00

The 6th JUM meeting has been held yesterday. There were two presentation about appservers and Flex, and I gave a talk about Java component models. I talked briefly about the basics (component, component model, component framework, Dependency Injection, Dependency Lookup) and about some concrete component models and frameworks (SCA, Spring, OSGi, Guice, JSR277) and their interoperability (Spring-DM, Guice-OSGi, Guice-Spring). Here are the slides (only in Hungarian).

Dumb value objects

2008-03-12T00:36:00.000+01:00

What sometimes really bothers me is that many programmers overuse value objects. They do it despite the fact that this concept is over-simplified for many tasks. And they even implement the accessors as dumb wrappers around the values, leave the checking of values for the callers, which is mostly a silly thing.
My point is that we should talk more about this kind of design. My 10 cents:

Read about domain objects and try to understand the concept. It's easy.
If you need value objects, implement their accessors in a way to check the accessed values and throw exceptions (in Java, I prefer runtime exceptions such as IllegalArgumentException or IllegalStateException) if the pre-defined constraints are not satisfied.
Think about concepts at higher abstraction level than data (objects, components etc), before you implement things.

Podcast about software components

2008-03-07T01:45:00.000+01:00

The guys at Software Engineering Radio have recorded a very good podcast about software components and component-based architectures. It's worth to listen to.

Architecture, again

2008-03-01T12:19:00.000+01:00

Last time I blogged about architectural diagrams. Now, a very good article appeared on InfoQ from Markus Völter. In the article he is focusing on the creation of a language used to describe a conceptual architecture and provides an overview about DSLs.

Bad style - Architecture Diagrams

2008-01-30T15:36:00.000+01:00

Plain boxes linked with each other using lines; these kind of diagrams are fine to explain many things - until they are called "architecture". It is a wide-spread misconception, they are just plain diagrams, until they meet the requirements of an architecture diagram. But wait a minute. What are these requirements?
There are many definitions of software architecture. I don't want to go into the details of software architectures, many people did this before (read the POSA books or this, this and this). Instead, I'd like to discuss some of the most important properties of good architecture diagrams.
The first is an unambiguous language (in this case, graphical notations, but the architecture description can be textual as well) the architecture is expressed in. Completeness (remember: component, interface, connector, configuration) is also important. This language should be well-defined with respect to its syntax (the set of notations used) and semantics (the meaning of the notations and language constructs).
It can be very helpful if the graphical notations of the language are based on well-known graphical notations, such as the elements of UML component or class diagrams.
The diagrams must reflect the architectural decisions (which are based on requirements, of course) and they should be organized around architectural aspects and/or viewpoints. This is the most important thing.
The layout of diagrams should emphasize the architectural configuration. Position and connections of each element in every diagram should be in sync with the architecture. For example, a diagram should not show layers or partitions where they don't exist.
And that's enough for start. If a diagram is made with these things in mind, it is an architecture diagram.

OSGi and DynamicImport-Package

2008-01-24T10:28:00.000+01:00

Last week I refactored an old Spring-based application to be OSGi-based. First I created some bundles of it. It was a pleasure, I really like the Eclipse plug-in development tools, but it's not what I want to talk about.
One of the classes from the legacy app used dynamic class loading via Class.forName(). This class was a factory used to load other classes reside in many bundles. It is perfectly legal, but in order to load a class, the class loader of the bundle must be able to find it. This can be done nicely with "Import-Package: package.of.the.class.to.be.loaded". Of course, someone must export this package using Export-Package. But what happens when the factory class is referenced from the bundle exported that package? The answer is simple: circular dependency. You may say that it is a non-issue and can be solved easily using DynamicImport-Package, but lets think about that for a moment. What are the architectural consequences of such a decision?
Importing a package means you are about to create dependency to the bundle exporting that package. So even if your importing bundle works perfectly fine without the other (exporter) bundle, the exporter must also be deployed in order to satisfy the dependency.
Moreover, exporting means that you expose internals of the exporter bundle that are not part of the service's API provided by this bundle. By doing this, you may experience compatibility issues when you change the internals of this bundle in the future, even if the service API remains the same.
With the above in mind, I decided to refactor the affected bundles to eliminate circular dependency instead of just "work around" the problem using DynamicImport-Package.
To wrap it up: I suggest you to think about the architecture first and use DynamicImport-Package if you really need it.

OSGi and the infamous class loading problems

2008-01-14T18:42:00.000+01:00

I just fought my fight with OSGi and JCL (Jakarta Commons Logging). I was porting an old Spring-based app to OSGi+Spring-DM, so I tried to use commons logging in my bundles. This ended up getting a nice exception:

org.apache.commons.logging.LogConfigurationException:
java.lang.NoClassDefFoundError (Caused by
java.lang.NoClassDefFoundError)
...

So I refactored all of my bundles to use the OSGi LogService instead of JCL. Re-deploy, start ... and no change. After some googling I found an interesting article which explained that JCL uses a custom class loading scheme which does not cause problems in standalone applications, but shows this weird behaviour under an OSGi environment. The article pointed to another logging framework (SLF4J) which provided a nice solution for the problem. A few lines from my config.ini:

jcl104-over-slf4j-1.4.3.jar@start,\
slf4j-simple-1.4.3.jar@start,\
slf4j-api-1.4.3.jar@start,\

And that's all. So please do not use JCL unless you want to bang your head against the wall.

(This madness drove me to an OSGi-related rule of thumb: if something looks suspicious around your bundles and you have no idea what's wrong, you may have a class loading issue.)

Java closures one more time

2007-12-23T13:11:00.000+01:00

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.

Equinox with Spring-DM

2007-12-22T17:20:00.000+01:00

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à!

Fun for boring mondays...

2007-12-17T15:11:00.000+01:00

I just found: Monsters of the Programming World. I am thinking about making a T-shirt...

JavaPolis - CBD

2007-12-15T17:55:00.002+01:00

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

2007-12-15T12:17:00.000+01:00

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).

Use the right level of abstraction

2007-12-03T15:00:00.000+01:00

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.

More on Android and OSGi

2007-11-26T13:05:00.000+01:00

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.

Google Android - is it the way to go?

2007-11-12T23:36:00.000+01:00

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?

MIDP3 - is it worth waiting for it?

2007-11-08T08:38:00.000+01:00

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.

Component management in CLDC

2007-10-27T20:12:00.000+02:00

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.

OSGi on low-end mobiles?

2007-10-14T15:55:00.000+02:00

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

2007-10-14T13:20:00.000+02:00

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

OSGi in mobiles?

2007-10-13T13:39:00.000+02:00

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.

Podcasts about software engineering

2007-09-04T17:17:00.000+02:00

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

Closures and Java

2007-09-04T15:50:00.000+02:00

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);