ObjectLabKit 1.1.0 released - Date Calculators for Business and Finance

We are pleased to announce the ObjectLab Kit 1.1.0 release!

http://objectlabkit.sourceforge.net

---

Changes in this version include:

New Features:

• Changed JODA dependency to 1.5
  
• Feature Requests item #1832345, make the Tenor Serializable Fixes 1832345. Thanks to Kieron Wilkinson.
  
• Added 2 methods on factory to check if a calendar is registered.
  
• Added method calculateTenorDates with/without a spot lag to enable calculation of a series of Tenor dates without changing the current business date in the calculator.
  
• Added method moveByTenor without a spot lag to allow tenor calculation based on the CURRENT date and not the spot lag.
  
• Valid Range via HolidayCalendar. HolidayCalendar should replace the simple Set of dates for holidays. A HolidayCalendar MAY contain an early and late boundary, if the calculation break a boundary, an exception is thrown, if there are no boundaries no exception would be thrown. This would ensure that calculations are not going outside the valid set of holidays. Fixes 1575498. Thanks to Paul Hill.
  
• Added a standard Tenor 2D. Fixes 1601540. Thanks to Anthony Whitford.
  
• Added new handler type ForwardUnlessNegative: a handler that acts like a Forward handler if the increment is positive otherwise acts like a Backward handler.
  

Fixed bugs:

• fix NPE issue if the calendar name is null.
  
• Deprecated ACT/UST and END/365 Day Count Conventions, which weren't very common. Also added a link to some documentation.
  
• The calculation of Spot date should take into account holidays BETWEEN now and spot (aka moveByBusinessDay). Thanks to David Owen.
  
• Spelling mistake in the code, sorry for breaking your code with this release. Fixes 1601542. Thanks to Anthony Whitford.
  

---

Issues, bugs, and feature requests for ObjectLab Kit
should be submitted to the following issue tracking system:

http://www.sourceforge.net/tracker/?group_id=175139

Have fun!
-The ObjectLab Kit development team

FlatPack 3.1.1. is released.

FlatPack 3.1.1. is released.

It is a simple bug fix release:

• [1818818] ClassCastException when accessing header or trailer records.


• Fixed bug in delimited parse when using Reader for data and map. Parameters were being reversed in the code.


• [1811210] When parsing multi-line delimited files, blank lines inside the elements were being removed from the result of the parse. Blank lines inside a delimited element were also causing a StringIndexOutOfBoundsException.

Released on maven Repositories:
M1: http://objectlabkit.sf.net/m1-repo
M2: http://objectlabkit.sf.net/m2-repo

Enjoy!

Paul & Benoit.

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.