Support for JDK 1.4.2

Jun 23, 2008 at 8:28 PM
Current version of HealthVaultJavaLib requires JDK 1.5. Is there any version available that supports JDK 1.4.2? We are currently on JDK 1.4.2 platform and are not able to upgrade to 1.5.


Thanks
Fazal
Coordinator
Jun 24, 2008 at 8:11 PM
This code base does not support older jdk versions.  If anybody is interested in back porting the code, let us know and we'll take a look at what you come up with.
Aug 20, 2008 at 6:10 PM
Edited Aug 20, 2008 at 6:11 PM
Just to add more information and close the loop here.

The biggest hurdle supporting JDK 1.4.2 is in the HTTP connection library delivered with JDK 1.4 and below.  It isn't very robust and doesn't support timeouts.  Most companies making web requests in Java use a library either from their J2EE vendor, Apache or elsewhere.  Sun rewrote this layer in Java 1.5 and fixed some of the major issues. <o:p></o:p>

At first glance back porting the library involves:

  1. Creating an implementation of the Transport interface with an HTTP client based on something else (Apache's HttpClient perhaps?).  This layer is interface based so it shouldn't be difficult to switch between implementations.
  2. Removing all generic collection classes and use their unchecked counterparts.
  3. Removing the enum for response code.  This may have been a mistake anyways since in order to make it forwards compatible, we really need the integer response code.
  4. Reworking the XPath parsing of the response code since XPath is not part of v1.4.
  5. Changing all StringBuilders to StringBuffers 
Aug 21, 2008 at 10:48 PM
I am not sure about 3 - "Removing the enum for response code.  This may have been a mistake anyways since in order to make it forwards compatible, we really need the integer response code. "
Aren't the response codes already integers - 7, 8, 11.....etc?


Fazal
Coordinator
Aug 21, 2008 at 11:07 PM
Edited Aug 21, 2008 at 11:17 PM
When the response contains a status code != 0, the integer code is set on the Response object and an HVRequestException is thrown containing a StatusCode enum.  The enum is populated with the codes known at development time, and any new codes are mapped to UNKNOWN at runtime   This probably needs cleaning up and unifying regardless of JDK version.

--Rob