J2EE and Swing Jobs @ ObjectLab London.

Hi All,

Does this qualify as "ObjectLab Open Source News"? may be not exactly... it is simply ObjectLab News, so sorry in advance:

ObjectLab Financial recently launched its global portfolio financing product; we’re in the final phases of rolling out Release 1.0 to our first client and already have several additional leads.

As such, we are recruiting and have 2 positions in London:
• A proficient J2EE Developer: JDK 5, EJB/POJOs, Spring, Hibernate, JBoss, Mule, JMS, ActiveMQ, XML, JAXB etc
see http://www.objectlab.co.uk/jobs/index.shtml?j2ee.inc

• A proficient Swing Developer: JDK 5, Swing, Spring 2 (Spring Rich Client a plus), Jasper Reports, etc
see http://www.objectlab.co.uk/jobs/index.shtml?swing.inc

Both roles should attract dedicated, hardworking developers looking for a challenging and rewarding job opportunity. Working in a small, delivery-focused team, you’ll have the chance to use your skills and knowledge, to find the best solutions to the challenges presented, as well as shaping the future of a new company with a great product!

We will offer a competitive package that will be complemented with performance related bonuses (including stock options).

Feel free pass onto experienced Java Developers that would fit the requirements.

Please use the links to contact us more privately.

Many thanks

Benoit.

FlatPack 3.1.0 released with Mule Contribution

Second post in 3 days... wow! Things are happening!

We are pleased to announce release 3.1.0 of FlatPack for Java 1.4+.

FlatPack is the new name for PZFileReader as the project has outgrown the initial scope of reading files...

Open Source flat file parser (CSV, Fixed Length, Custom) using XML to configure formats.

http://flatpack.sourceforge.net

This is an important release with a new name and package structure. Users of previous version should find it easy to migrate as most classes have kept their original name.

A major development is the experimental release of writers for exporting DataSets. We would like to thank Dirk and Holger from the Mule Project for their kind contribution to FlatPack. We're looking forward to the result of using FlatPack in Mule, a great Open Source ESB.

This release also adds a few convenience methods on a DataSet and the Parser classes, fixes a couple of bugs.
More on changes at: http://flatpack.sf.net/changes-report.html.

FlatPack is released under the business friendly Apache License v2.0.

The library is small, lightweight and does not force you to adopt a framework.

The implementation is useful to any business that deal with flat files. Not only can it parse very quickly some CSV or any-user defined delimiter, this library can parse FIXED LENGTH files.

The library allow you to define an XML mapping (or in a database) of the format of your file. Once this is done, the parsed data can be accessed via a simple name lookup mechanism.

It is our aim to publish at some point some well know file formats for your immediate use. Please contribute if you have some standard files...

It is available for download via SourceForge or the Maven Central Repository (both Maven 1 and Maven 2). The homepage has some very quick examples.

Maven Repositories:
M1: http://objectlabkit.sf.net/m1-repo
M2: http://objectlabkit.sf.net/m2-repo

ObjectLab is not new to the open-source community having used numerous OS projects, It has recently launched the ObjectLab Kit family, including:
- QALab (http://qalab.sourceforge.net), a tool that keeps track over-time of the static analysis results from FindBugs, Checkstyle, PMD, Cobertura etc.
- DateCalculators (http://objectlabkit.sourceforge.net), a set of generic lightweight and thread-safe Date calculators for Business and Finance.
- JTreeMap, (http://jtreemap.sourceforge.net), probably the only Java Open Source implementation of treemap/heatmaps, available as a Swing or SWT component.
- StatSVN, (http://www.statsvn.org), statistics for your Subversion repo.

We would like to thanks our friends and colleagues for their help, reviews and suggestions.

Sorry for the long post...

Feel free to pass on to people who may be interested.

Enjoy!!

Paul Zepernick and Benoit Xhenseval

ObjectLabKit selected for Open Financial Market Platform

Hi

I meant to send this a long long time ago... So here is the not-so-new news.

My friend Neil Barlett (Mr OSGi and Eclipse) spotted this mention of the ObjectLabKit (DateCalculator) as part of the proposal for the Open Financial Market Platform.

http://www.eclipse.org/proposals/ofmp/

I can only say this: Wow!

I hope it succeeds as the main reason for creating this little library was our frustration at re-inventing the wheel so many times... I know a couple of big investment banks using it now, so it was worth it!

Back to work now...


Benoit

Accessing JavaBeans Nested Properties: testing Spring, BeanUtils and OGNL

One our application needs to access properties from a javabean using reflection
e.g. get(“property1”, object)…

Rather than re-inventing the wheel, I thought that we should use a library. There are quite a few that do this kind of get/set properties… So the question was: Which One???

I know of:

1. Spring beans (2.0.5) http://www.springframework.org


2. Apache Commons BeanUtils (1.7.0) http://jakarta.apache.org/commons/beanutils/


3. my colleague Gerald mentioned OGNL from www.ognl.org (pronounced ‘like a drunken orthogonal’ to quote their documentation).

So with 3 candidates… which one is the best performing?

OGNL seems to be, by far, the most flexible and rich library, but does that means it runs like a dead dog?

I limited the problem to accessing a property value: being simple, nested or as part of an array.
The Test: I shall access 100,000 a series of 8 properties. The classes are:

public class A {
  private int intProperty;
  private Long longProperty;
  private String stringProperty;
  private Date dateProperty;
  private B b = new B();
}
public class B {
  private int intProperty = 5;
  private C c = new C();
  private D[] d = new D[10];
}
public class C {
  private String stringProperty;
}
public class D {
  private int intProperty = 1;
}

The Test creates one instance of A, that contains 1 instance of B which contains 1 instance of C and an array of 10 Ds. I hope this is clear…
The set of properties to get are: "intProperty", "longProperty", "dateProperty", "stringProperty", "b.intProperty", "b.c.stringProperty", "b.d[1].intProperty", "b.d[7].intProperty".

So… the results?

Library	Total time (ms)	average per set (micro sec)
Spring	1,783 ms	17.8 micro sec
Bean Utils	2,242 ms	22.4 micro sec
OGNL	50,293 ms	503 micro sec
OGNL Expression	1,595 ms	16 micro sec

What does this tell us?

OGNL is at the same time the slowest and the fastest library on my laptop (Lenovo, dual-core) under java 1.5.0_10. OGNL has 2 mechanisms, one is simply to call Ognl.getValue(“pathToProperty”, object) and the other one is to evaluate the expression upfront by Object expression = Ognl.parseExpression(“pathToProperty”) and then Ognl.getValue(expression, object);

The second one is the fastest mechanism so, if you have the ability to ‘pre-compile’ your expressions, OGNL is for you… otherwise Spring Beans is doing a good job!

The entire source code and Eclipse project is available here, feel free to comment and tell us about your experience.

Enjoy!

Spring prototypes and auto-wire byType are expensive

In designing a new, very performance-sensitive part of our systems we investigated the runtime performance of retrieving beans (singleton and prototype) from a Spring bean factory versus creating them via a hand-coded factory. For the Spring code we also measured any additional overhead of auto-wiring beans and doing dependency checks on beans.

The test repeatedly retrieves 5 beans which are the roots of a highly interconnected object graph (comprising 4 other beans) from a Spring bean factory. In the prototype tests each bean in that graph is a Spring prototype bean, i.e. a new instance is create whenever a bean is needed from the bean factory. In the singleton tests each bean in that graph is a Spring singleton and so the same instance is returned every time a bean is retrieved. By comparison, the hand-coded factory always creates each object in that graph and hence behaves identical to the Spring prototype test.

The results give the time in nanoseconds for retrieving a bean (which is the root of the object graph) from the factory:

Bean retrieval / nanoseconds	Spring 2.0.5	Spring 2.0.4	Spring 2.0.3	Spring 2.0.2
Spring, prototype, autowire=byType, depend check	442365	500050	945551	958805
Spring, prototype, autowire=byName, depend check	253870	255557	667352	678782
Spring, prototype, no autowire, depend check	172412	173539	624171	639640
Spring, prototype, no autowire,no depend check	162300	162950	586144	600320
Spring, singleton, autowire=byType, depend check	608	841	1075	1134
Spring, singleton, autowire=byName,depend check	710	840	1069	1132
Spring, singleton, no autowire,depend check	609	842	1097	1161
Spring, singleton, no autowire, no depend check	614	837	1102	1135
No Spring (hand-coded factory),always create (prototype)	284	284	288	292

The numbers speak for themselves, but the shown figures visualise them.

The code we used to perform these measurements and all results are available here.

Goodbye PZFileReader! Hello FlatPack!

Paul and I have been muling (pun intended... more on that later!) about the name of our parser project. PZFileReader is very useful and originated in the world of "reading files", its capabilities have outgrown the name for quite some time.

We then thought about the basics, what does this project do?

Well, it parses files, string or messages that are in a delimited format (e.g. csv) or fixed length format (when a field is delimited by an offset and a length). It would even support parsing records that are across multiple lines. Furthermore, the project allowed an XML definition of a given format... Some work is also ongoing to create 'Writers' that would allow you to create such delimited, we hope to reveal more shortly.

And so.. enter FlatPack!

The common denominator of those files/messages is that they are "flat" and not hierarchical a la xml.

We were lucky enough to get the url: http://flatpack.sf.net

The packaging and website will be updated soon!

Enjoy!


Benoit & Paul

JTreeMap 1.1.0 released!

Hi *,

ObjectLab is very pleased to announce the immediate release of JTreeMap 1.1.0, a heatmap/treemap visual library for JDK 5.0. We believe this is the only open source library of this kind under a business friendly license.

Towards the end of 2006, ObjectLab got involved with JTreeMap as part of a financial application. Laurent Dutheil had been developing it but found it more time consuming that anticipated. It is where ObjectLab offered some expertise and the result is the new release 1.1.0. We acknowledge and thank Laurent for his great contribution.

Home page: http://jtreemap.sourceforge.net

The release is available on SF and on 2 Maven repositories (whilst we’re going through the process of adding it in the official repository). The ObjectLab Open Source repositories are:

http://objectlabkit.sourceforge.net/m2-repo

and

http://objectlabkit.sourceforge.net/m1-repo

The question of how to represent and visualize a lot of information at a glance is a hot topic in IT. A Treemap, also known as Heatmap, is an important tool for this. A TreeMap graphically represents a hierarchical structure.

Typically, the hierarchy will involve a tree of nodes of different sizes and different colours. The size and colours are determined by parameters such as the relative importance of a node in comparison to the full size. A well known examples is the Map of the Market on www.smartmoney.com but their library is not open source (and very pricey!).

JTreeMap comes in 2 flavours: JTreeMap for Swing and KTreeMap for SWT.

Enjoy!

Benoit & the rest of the ObjectLab Team.