Archive for Java

Counting UTF-16 Characters in Java 5

If you take I18N serious, then you should take a look at Sun’s latest “Core Java Technologies Technical Tips” covering Strings if you think the following code sample is always the correct way to count the length of a string:

private String testString = "abcd\\u5B66\\uD800\\uDF30";
int charCount = testString.length();

Java 5 introduces support for Unicode 4.0, which defines a significant number of new characters above U+FFFF (the U+ prefix signifies a valid Unicode character value as a hexadecimal number.). Thus, the 16-bit char type does no longer represent all characters!

Read the rest of this entry »

Comments (1)

PDFs available for JavaOne 2006 Sessions

Check out the JavaOne 2006 Conference Session Catalog. Presentation files available for download are indicated with a paperclip icon. After clicking on a paperclip, you will be prompted to enter the following Username “contentbuilder” and Password “doc789”.

Tip: Use a mass download tool like FlashGet, which can use the given username and password for all accesses — saves you a lot of typing.

Leave a Comment

EJB Container-Managed vs POJO Relationships

When moving from EJB 2.x CMP Entity Beans to O/R Mapping Frameworks like Hibernate or Toplink you should be aware of the fundamentally different approaches in dealing with relationships between persistent objects. Today, I had a look at the book “Hibernate in Action“; on page 106 in chapter 3.7.1, the authors discuss “managed associations” and this is very interesting and important:

If you’ve used CMP 2.0/2.1, you’re familiar with the concept of a managed association(or managed relationship). CMP associations are called container-managed relationships (CMRs) for a reason. Associations in CMP are inherently bidirectional:

A change made to one side of an association is instantly reflected at the other side. For example, if we call bid.setItem(item), the containe automatically calls item.getBids().add(item).

Transparent POJO-oriented persistence implementations such as Hibernate do not implement managed associations. Contrary to CMR, Hibernate associations are all inherently unidirectional. As far as Hibernate is concerned, the association from Bid to Item is a different association than the association from Item to Bid.

To some people, this seems strange; to others, it feels completely natural. After all, associations at the Java language level are always unidirectional – and Hibernate claims to implement persistence for plain Java objects. We’ll merely observe that this decision was made because Hibernate objects, unlike entity beans, are not assumed to be always under the control of a container. In Hibernate applications, the behavior of a non-persistent instance is the same as the behavior of a persistent instance.

For an example consider a manager entity with a (bidirectional) 1:N relationship to employees that work for him. Additionally, a manager is associated with projects (N:M relationship), for some of them, he is even a teamleader (unidirectional relationship of teamleader entity). Now, a certain manager, for some reason, moves to another department and is disassociated with his employees and his current projects (and vice versa) and is teamleader no more.

With EJB 2.x CMP Entity Beans and their Container-Manager Relationships (CMR) this is one line of code:

// Implicitly removes manager from its employees and projects
// and also removes him as any teamleader

That’s it! The Persistence Manager handles all the details, because he has to enforce referential integrity and knows the entity model/relationships from the deployment descriptor. What details? Well, look at how this is achieved with Toplink (same with Hibernate):

Iterator iterator = (Vector)manager.getEmployees().iterator();
    employee = (Employee);
    // For bi-directional relationships,
    // it is important to maintain both sides
    // of the relationship when changing it:
manager.setEmployees( new Vector() );

iterator = (Vector)employee.getProjects().iterator();
    project = (Project);
    if(project.getTeamLeader() == manager){
manager.setProjects( new Vector() );


Why I am mentioning this? Because EJB 2.x Container-Managed Relationships (CMR) are really easy to use, quite fool-proof. POJO persistence, on the other hand, requires a lot of involvement and understanding of the entity relationship model from you. Actually, you manually express the logic which is already expressed in the mapping descriptor in your source code, a somehow redundant work. I think this approach lacks scalability w.r.t. the model complexity and coding errors quickly lead to an inconsistent database (or to SQL exceptions in case of foreign key constraints).

Comments (3)

Generating .dll files for JNI under Windows/Cygwin/GCC

In Windows you can use the Cygwin GCC compiler/linker to produce the .dll files needed for JNI (Java Native Interface) applications. Take for example the JNI HelloWorld example from Sun.

But there seem to be several obstacles. First I got compiler errors (concerning undefined jlong type) and after resolving this I wondered how to produce a Win32 native .dll file.

The solution is as follows (my environment is J2SE 1.4.2-b4, Cygwin GCC 3.3.1):

Changes to JDK headers needed for GCC

(Take from here) GCC doesn’t have a __int64 built-in, and this patch basically uses “long long” instead.

  1. Edit the file /include/win32/jni_md.h, Where   is the installation root (eg., c:/jdk1.4.2).

  2. Replace the segment:

    typedef long jint;
    typedef __int64 jlong;
    typedef signed char jbyte;


    typedef long jint;
    #ifdef __GNUC__typedef long long jlong;
    typedef __int64 jlong;
    typedef signed char jbyte;

Modify the GCC spec file

This modification is only important if the next step (compiling and linking) produces an linker error “dllcrt2.o not found”.

(Take from here) In the Cygwin shell edit the file “/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs” (replace 3.3.1 with your GCC version). Find the text “dllcrt2” and replace it with the absolute (Cygwin) path to dllcrt2.o, e.g. “/lib/mingw/dllcrt2”.

Compile and Link the .dll file

(Take from here) Call the compiler:

gcc -L /lib/mingw -Wl,--kill-at -mno-cygwin -shared -I /include/ -I /include/win32/ HelloWorldImpl.c -o hello.dll

Replace with the Cygwin path to your J2SE, e.g. “/cygdrive/c/Java/jdk1.4.2”.

That’s it. Now I get “Hello World!”. Fine.

Comments (11)

Articles I read today (eBay, JBoss, C++)

  • Nuggets of Wisdom from eBay’s Architecture
    This blog posting recaps the statements of a former JavaOne session about eBay’s J2EE architecture, the motivations and experiences.

    The impressive part is that eBay had 380M page views a day with a site availability of 99.92%. In addition to that, nearly 30K lines of code changes per week. […] The key nuggets of wisdom are a stateless design, the use of a flexible and highly tuned OR-mapping layer and the partitioning of servers based on use cases.

  • The Unofficial JBoss Performance Tuning Guide
    The articles show how to strip down JBoss, i.e. remove all services which are not neccessary for your application’s needs (Okay, I don’t use JBoss, but still good to know.)

    There isn’t a lot of consolidated information in this area, and the information presented here is through trial and errors and bits and pieces of information found on the JBoss forums and weblogs of JBoss developers. Comments and corrections are very much welcome.

  • Announcing The C++ Source
    Good to know that C++ still has an active development and community. Reading the article “C++ Reloaded” I really appreciate the “world dominance” of Java:

    As we speak, the C++ standards committee […] and its members are adding powerful abstractions that at once increase the power and the ease of use of your favorite language. Hash tables, tuples, regular expressions, numerous useful smart pointers, more mathematical functions, and fewer syntax ambiguities are coming our way, and that’s only the beginning.

    I really liked C++ ten or so years ago and used it a lot. Today, I wonder how the C++ world and myself could live years without an API and general framework backing the core language. (Can someone please count the numerous String class implementations available in C++?)

Leave a Comment

Two great Frameworks I never heard before

Some friends (Klaus Krüger from MGM and Berthold Maier from Oracle) today mentioned two frameworks they have very successfully used in recent J2EE projects. I haven’t had the chance to check them out in detail yet…

Open Generator FrameWork

The Open Generator FrameWork is a full featured MDA/D tool kit written in Java. It comes with an XMI based import interface supporting several popular design tools, powerful meta model framework, and a simple and elegant template language. Due to its modular design, each component can easily be extended or replaced.

It is the successor of the core of the b+m Generator FrameWork distributed by b+m Informatik AG and is currently being rereleased under the LGPL as part of the project (note the missing ‘e’ before ‘ware’; sf has a 15 character limit on project names).

Carbon Component Framework

Carbon is a lightweight component model for the Java programming language built to support enterprise applications and compliment J2EE and other traditional technologies. The technology provides a basic abstraction for the development and deployment of modular services. Included with the framework are caching, a JDBC accelerator, metadata driven deployment and management, XML and JNDI-based configuration, user and group management supporting JAAS and other technical utilities and services.

Carbon provides improved flexibility by providing robust multi- deployment, type-safe configuration support and remote management capabilities through little to no additional code. It also provides a simple name-based lookup mechanism to deployed services. The component model employs basic lifecycle support and the architecture can be configured with additional interceptor plug-ins that add functionality across the architecture.

Leave a Comment

Articles I read today

  • The Mythical Man-Month Revisited
    This is a developer’s view on the classic book (“Adding manpower to a late project makes it later”).
  • The unofficial A to Z of J2EE Stuff
    The A to Z of (roughly) J2EE relevent tools, technologies and ideas… Nice list, comes in handy for a quick survey.
  • How Microsoft Lost the API War
    From “Joel on Software”. Basically, the article says M$ wants rich clients (desktop applications) since they depend on their big cash cows Windows and Office. The Web as an application platform is the rival. That’s the reason they stopped IE development and they FUD again for Windows Longhorn (in 2006+) and its new desktop technologies like XAML and Avalon, WinFS etc. They lost the war to Web standards like HTML, CSS and Web Services, which gives developers and vendors a freedom of choice for their server platform. Not only this, but worse, they encouraged developers to switch to the Web platform by abandoning their Win32 API for the novel, but completely incompatible .NET framework. Not a safe place to develop either, since the upcoming Longhorn will again be all brand new and incompatible:

    And if you’re developing a Windows GUI app today using Microsoft’s “official” latest-and-greatest Windows programming environment, WinForms, you’re going to have to start over again in two years to support Longhorn and Avalon. Which explains why WinForms is completely stillborn. Hope you haven’t invested too much in it. Jon Udell found a slide from Microsoft labelled “How Do I Pick Between Windows Forms and Avalon?” and asks, “Why do I have to pick between Windows Forms and Avalon?” A good question, and one to which he finds no great answer.

Leave a Comment

IoC Containers and Dependency Injection

Today I investigated the state of application configuration management (J2EE and Java in general) and quickly was tied to the not-so-new but very promising approach called “Inversion of Control” (IoC) and its specific implemention via “Dependency Injection” (DI). There are a huge amount of talks, blogs etc. on this subject. The paper “Inversion of Control Containers and the Dependency Injection pattern” from Martin Fowler helped me to get familar with the principles, the acronyms and key frameworks for IoC and DI – a must-read for Java developers. Another fine paper is Rod Johnson’s “Introduction to the Sping Framework“, posted at

As it turns out, the Java Open Source community offers a lot of IoC/DI containers/frameworks:

  • Apache Avalon is fairly heavyweight and complex, and seems more invasive than newer IoC solutions
  • PicoContainer is lightweight and emphasizes the expression of dependencies through constructors rather than JavaBean properties
  • Jakarta HiveMind
  • Spring is general purpose application framework with a IoC/DI container as its core.

Some time ago, Howard Lewis (related with the HiveMind project) wrote a Blog posting “Comparing HiveMind to Spring“. On this blog page there are also other postings on HiveMind and Spring.

Leave a Comment