Java Client Library Release History

Version 1.4

• Added net.degreedays.api.regression package to give API access to advanced regression functionality that was previously only available via the online regression tool.
• Updated minimum Java version from 1.4 to 1.5 so we could make use of generics, varargs, and enums in the new regression classes. We also made some minor modifications to some pre-existing classes, to allow for generics and varargs, and to covert all enum-like classes to proper enums. Binary compatibility with earlier versions of this client library is maintained. Java 1.5 is ancient, but we had no need for anything that would have required a newer version of Java, so we figured we might as well aim for maximum compatibility. The client library will of course work in recent versions of Java as well.
• Increased the maximum number of DataSpec items in a request from 100 to 120.

Version 1.3

Added allowPartialLatest property to DatedBreakdown, to make it possible to fetch time-series data (like hourly temperature data) that includes figures for the current day so far.

Version 1.2

• Added TimeSeriesDataSpec and related classes for fetching time-series data (like hourly temperature data).
• Added support for custom breakdowns (typically used to fetch degree days to match irregular energy-usage data).

Version 1.1.2

Fixed an issue that was preventing the client library from working in Java version 1.4. If you need ongoing compatibility with a very old version of the JRE like 1.4, please email us at info@degreedays.net to let us know. We value compatibility (and backwards compatibility) very highly, but at some point we may consider dropping support for Java 1.4 in client-library updates if we aren't aware of any customers that continue to need it.

Version 1.1.1

Made all request and response classes serializable.

Version 1.1

Added LocationInfoRequest to make two-stage data fetching possible. Now you can find out what station the API would use to generate data for a geographic location (postal/zip code or longitude/latitude position), without having to use up a lot of request units actually fetching that data. This is useful if you are storing data by station ID and have enough real-world building locations that many of them share the same weather station.

Version 1.0

First stable release.

Pre-1.0 releases

There were several, but we've not documented them here as they were only available in private beta.

Back to Java Quick-Start Guide