Archive for February, 2010|Monthly archive page

jetty 7.01 minimum jar requirements

In Intigrix, Java on February 20, 2010 at 11:50 am

i’ve finally upgraded Intigrix’s HTTP engine from 6.1.22 (Jetty) to 7.01, the latter already being hosted in eclipse.org and (necessarily?) changing its packaging. This means some minor changes to Intigrix’s content handler.   I dont know if this will solve our NIO issue with 6.1.22 (Jetty developers say its a JVM issue) but the performance seems to be impressive.  From a typical  load factor of 4-5 (just a few minutes from startup–it is a very busy server), with Jetty 7.01 its just 0.45-1.0.  I’ll know for sure next week during a business day load what the load profile will be like with this update.

Anyway, as usual sans documentation we have to look for the minimum jars to use.   To run Jetty 7.01 as an embedded webserver you’d need the following jars:



JRockit and JVM integration possible

In Java on February 17, 2010 at 12:52 pm

looks like people are hunching down to make sense on the future of the two  JVM’s.  According to a JavaLobby post..Mark Reinhold (Sun’s principal engineer)..

“..has been in several meetings with developers from Sun, Oracle, and other sources to discuss the possible integration of HotSpot and JRockit.  They’re very much in the exploratory stages right now, seeing how the two JVMs will fit together.”

well its a good thing to know that that’s being contemplated, add to that the impending release of JDK7 at least I have something to look forward to.

Oracle: Sun’s JVM or JRockit?

In Java on February 16, 2010 at 10:42 am

our production web services have been bedeviled with serious performance issues  largely due to documented issues with NIO (we’re using Jetty for its http engine).  As its a known JVM bug, our options are really limited to a) hacking Java and fix the bug ourselves, b) wait for a new release of Java and ‘hope’ they’ll finally fix this particular bug or c) look for a different JVM.   I dont have the patience to do A. Considering that this bug was reported in 2006, option B may take a long time coming.. option C: an alternative JVM poses an interesting scenario as there’s really only 4 JVM implementations out there: Sun’s Java Implementation (the de facto of course), OpenJDK (same code base really as Sun’s), IBM’s implementation and BEA’s JRockit (bought by Oracle in ’08).   IBMs implementation seems to be stuck at 1.5 version of the Java API and I cant find any new developments there so that leaves me with Oracle’s  JRockit.   Unfortunately, JRockit is not free (as in install anywhere to anybody’s production server) anymore, according to its FAQ:

All Oracle JRockit products are free of charge for evaluation and development .

So the question is.. now that Oracle has purchased Sun/Java/MySQL and they have their own money making JRockit/OracleDB what’s the incentive for them to continue on developing the erstwhile de facto Java implementation? Goodwill? its not far-fetched to imagine that one day the current Sun- Java implementation will have similar license terms.

On the other hand, Oracle can just be subtle about it and will just slowly starve the Sun-Java effort of development resources as Oracle peddles a ‘better’ (and paid)  JVM in JRockit.  This remains to be seen of course.. meanwhile I’m stuck with this bug.. option A looks attractive all of a sudden.

Oracle shuts down ex-Sun open source site kenai.com

In Java on February 5, 2010 at 3:27 pm

Oracle will shutdown kenai.com by April 2010.  Kenai is an open source hosting site operated by Sun.. havent really used it although I know Netbeans 6.8 has close integration with it.  This is probably the first of Sun’s assets (if you can call it that — certainly not in the eyes of Oracle) that Oracle is dissolving.  While Oracle will continue to use the project ‘internally’ they will already stop accepting new postings and will delete all its contents in April.  Boy.. they really work fast.

What’s next for Oracle? Netbeans?  I certainly hope not, although that might be wishful thinking as they’ve got their own JDeveloper IDE which is closely tied to their (revenue-generating) products.  So far, according to an Oracle-Sun Exec presentation they’ll be treating Netbeans as a ‘light weight’ IDE and will continue to support it.. we’ll see.

FlexOODB milestone screen snapshots

In Database, FlexOODB, Java on February 5, 2010 at 9:48 am

here’s some snapshots of the generated prototype (all generated screens use AJAX):

Image 1: splashpage

Image 2:  Listing the ‘Account’ records.

Image 3:  Viewing an ‘Account’ (includes export to XML and Printer icons)

Image 4: Child classes of ‘Account’

Image 5: Viewing ‘Account’s child elements ‘Subscriptions’

Major milestone for FlexOODB API

In Database, FlexOODB, Java on February 4, 2010 at 6:19 pm

Whew! just finished the second major milestone of  the (then proof-of-concept) FlexOODB API .

In a nutshell, the motivations  for developing FlexOODB are to a) replace “mainstream” clunky and rigid persistence API’s (no inheritence or abstraction capabilities, can’t extend it, quirky must-be-embedded configuration requirements just to cite some reasons)  b) develop a platform where ‘I-dont-have-to-manually-create-the-tables-for-my-apps!’  and c) provide Rapid Application Development (RAD) utilities for the Intigrix Platform.  My goal is to minimize (if not take out!) the tedious and time consuming user interface<->data and data relationship binding from systems development, doing so will allow developers to focus on the more esoteric requirements of the system. This also means that software is easier to manage and time-to-market is a lot faster.

I’m satisfied with this milestone version: given a Schema (ie XSD) as the system’s data definition, the API can already generate a User Interface definition file (where we can set things like should a field be editable, updateable, auto-increment etc), generate the class entities then finally create the necessary java code, html and application files for CRUD (plus XML exporting and print friendly versions of the data).  The API fully supports and generates the necessary CRUD code for multi-generational (ie parent-child-grandchild…ad infinitum) data structures, at this point though, each generation has to be of different class types — not really an issue for majority of apps.

In practical terms, using the old API, I was able to develop a working prototype (includes user management and authentication) of a personal healthcare system in a week (5 working days).  I expect to improve on this by at least 25% as pages I had to manually make before (e.g. paging of items, child templates etc) are already created by default with this milestone version.