Java Everest (jEverest) Update

I was looking through some old Everest code on the trunk and 1.0 branch about a month ago and realized that the jEverest project had stalled. I was trying to think of a killer new feature for Everest 1.2 and I hadn’t realized the answer was staring me right in the face this whole time.

jEverest is a Java version of Everest which was intended to be completed by January of this year, however because of more pressing issues it was dropped in favour of other work (such as the Client Registry reference implementation and Shared Health Record implementations). But not anymore. We’ve made some really good progress on the datatypes and supporting classes and with our public SVN server you can take a look!

jEverest is in the 1.1 branch (1.2 development) of the Everest project on the server. So far we have completed a port of the majority of data types and some enhancements to the GPMR java renderer. Hopefully we’ll have something to demonstrate by HL7 WGM in January but I wouldn’t expect a release until later in 2013.

Anyone who has talked to me (in person) knows that I’m not the biggest fan of the Java platform (IMO C# and .NET is much better) however it is not nearly as terrible as I had remembered it. Java 1.7 does have some nice features (like strings in switch cases, finally!) however I do have some legitimate complaints about Java development (just observations, don’t want to start a war)

1. Eclipse : Nice IDE, lots of features and bells and whistles however I’d much rather prefer an IDE which has less features but does them properly. For example:
   • Subclipse isn’t the best when you’re in the “Java perspective”, it simply wraps the SVN command line and places conflict markers directly in your code which I then have to resolve by “Right Click -> Open in Conflict Editor”. Why? Maybe I’m just used to VisualSVN.
   • Why are there two places to get Eclipse extensions? Some extensions I have to visit “Help -> Install New Software” and others “Help -> Eclipse Marketplace”. There should be one place to get extensions.
   • On the topic of extensions, my major complaint with Eclipse is the plethora of options. Everywhere I look, options options options! The context menus are huge and cluttered with options.
2. Type Erasure : By far, this is my number one pet-peeve with Java. The fact that LIST<REAL> at runtime is indistinguishable from LIST<INT>. This causes lots of problems especially since the majority of data types use generics. Every time I implement a conversion method or validation method that really does need to know the type of a generic I can’t (or I have to use some hack)
3. Closures : Believe it or not, this actually does matter in jEverest, especially when searching a collection. In Everest all collections have a Find() method (for example, to find all numbers in a list larger than a given number : for(int i = 0; i < 10; i++) numbers.FindAll(o=>o > i);). This can be a problem jEverest and to get around it I have to use a custom IPredicate / Predicate implementation. (contrast the previous Everest example with jEverest : for(int i=0; i<10; i++) numbers.findAll(new Predicate<INT>(i) { public bool match(INT c) { return c > this.getScopeValue(); } }); )

Overall these aren’t showstoppers, just require some clever trickery to make compatible solutions. The idea behind jEverest isn’t to be 100% code compatible with the .NET version, but to be a meaningful port of the functionality.

I’ll end on a positive note: Java enumerations are really cool and much better than C#/.NET. Being a class means that enumerations in Java can implement interfaces and I’ve taken full advantage of this for representing enumerated vocabularies (via IEnumeratedVocabulary) and hierarchical vocabularies (via IHierarchicEnumeratedVocabulary).

Keep your eyes open, jEverest is coming!