Wednesday, March 21, 2007

Java 5 Conversion Notes

Having finished hackyCore_Kernel, my basic strategy for updating Hackystat code to 1.5 is currently the following:

(0) SVN update, then 'ant -q freshStart all.junit'. Make sure the system isn't busted before you start busting on it. (Be sure to configure the hackystat.build.properties file to include the modules you will be working on.)

(1) Use Eclipse to identify a class containing at least one warning.

(2) Fix instance variables. Navigate to that class, then go to the top of the file and check for any collection classes as instance variables. If present, add type information. For example,
private static TreeMap  numOfPeriodsMap = null;
becomes
private static TreeMap<String, String> numOfPeriodsMap = null;
Note that this often requires some hunting through the file to determine the kinds of objects being added to the collection.

(3) Fix collection references. Continue through source code, updating references to collection classes to include type information. For example,
numOfPeriodsMap = new TreeMap(new StringIntegerComparator());
becomes
numOfPeriodsMap = new TreeMap<String, String>(new StringIntegerComparator());
(4) Update comparators to include type information. For example,
public class StringIntegerComparator implements Comparator {
public int compare(Object o1, Object o2) {
becomes
public class StringIntegerComparator implements Comparator<String> {
public int compare(String o1, String o2) {
(5) Update method signatures to include type information. For example,
public static TreeMap getYearOptions() {
becomes
public static TreeMap<String, String> getYearOptions() {
(6) Remove occurrences of "old style" for loops. For example,
Set analysisNameList = manager.getAnalysisNames();
for (Iterator i = analysisNames.iterator(); i.hasNext();) {
String analysisName = (String) i.next();
String enabled = request.getParameter(analysisName);
becomes
Set<String> analysisNameList = manager.getAnalysisNames();
for (String analysisName : analysisNames) {
String enabled = request.getParameter(analysisName);
In some situations, it doesn't make sense to update them. For example, I've seen loops where the next() method was called twice in each body (the list contained "pairs" of objects that were operated on two at a time.) In this case, you must leave it as an "old style" loop.

(7) Implement Iterable<T> if necessary. In some cases, to accomplish (6) you must have a class implement "Iterable". For example, the SdtManager class should enable you to iterate across all instances of SensorDataTypes using the following for/in loop:
for (SensorDataType sdt : SdtManager.getInstance())
To accomplish that, the SdtManager class had to be changed from:
public class SdtManager  {
:
public Iterator iterator() {
to
public class SdtManager implements Iterable<SensorDataType> {
:
public Iterator<SensorDataType> iterator() {

(8) Remove vestigial casts. After adding in the type information, you will hopefully be able to remove casts.

(9) Remove vestigial imports. When you're all done with a class, you will hopefully need to remove imports. For example:
import java.util.Iterator;

(10) Use @SuppressWarnings for the SerialVersionUID warning. There's just no reason to add this instance variable for Hackystat code; it will not be serialized.

(11) Continue until Eclipse reports no warnings for this class.

Note that sometimes this strategy requires working on several classes at once when they are interdependent.

(12) 'ant -q freshStart all.junit', then SVN commit. Be sure the system is OK, then commit your changes du jour. I found that my Java 5 updates would sometimes create Checkstyle errors, so be sure to do a 'freshStart'. (Double check that the hackystat.build.properties file includes the modules you have been working on.)

Also, I'm cleaning up documentation, removing the @version tag that is a relic of the CVS days, etc. as I work on the class. As long as I'm touching it, I might as well make the JavaDocs better and fix any coding bogosities I encounter.

Monday, March 19, 2007

Scalability and StringListCodec

Now that I'm worrying about Large Scale Hackystat applications, I've run across a scalability issue in StringListCodec. It currently hardwires the maximum string size as 99,999 and the maximum number of strings as 9,999.

These translate to constraints on (a) the size of a sensor data instance and (b) the number of sensor data instances that can be sent in any individual Hackystat SOAP transmission.

Fortunately, this is easy to fix: these are constants that could potentially be overridden, for example, by a property value. The cost of increasing them is an increase in the "fixed cost" of a sensor data transmission, due to the way StringListCodec works.

Friday, March 16, 2007

Java 5 Migration

Frustrations du jour:
  • SerialVersionUID. Eclipse generates a warning whenever a serializable class (such as all classes that inherit from Exception) don't define this instance variable. I've decided to add an @SuppressWarnings("serial"), but I'm not sure if this is the right decision.

Thursday, March 15, 2007

To Do

  • Remove obsolete configurations from build.
  • Fix Hackystat HPC dependencies
  • Update Version 8 document to include scalability section

Wednesday, March 14, 2007

Java 5 migration

Now beginning the great Java 5 update of the Core subsystem.



Used Eclipse and set the compiler warnings back to 'default'. Got 587 warnings.



HackyCore_Telemetry is going to be a problem since it has JavaCC generated code. I don't know if I can disable Eclipse warnings on just a set of packages. I know I can individually change the warnings settings for a single Project.

Decided to work on one module at a time. Now fiddling with HackyCore_Build.


Here's an issue: I would like to write the following code:

List propertyList = project.getChildren("property");

However, project is a class from JDOM and is not generic, so I get the following warning:

Type safety: The expression of type List needs unchecked conversion to conform to List

That kind of sucks. Either propertyList is a raw collection class (and I have to do a class cast when iterating through it) or I have this warning. Here's my options:

http://www.onjava.com/pub/a/onjava/2005/07/06/generics.html?page=last&x-showcontent=text

I'm going to go with the @SuppressWarnings

Online Engineering Logs

Overview
A traditional engineering log (EL) is a notebook. Developers maintain an EL to record information that facilitates software development, including "to do" lists, emergent designs, problems they are encountering, and rationales for implementation decisions. They serve as a kind of "offline memory", that helps engineers in several ways:
  • It helps them to quickly re-establish what they were working on at the start of each day, or if they have been interrupted from the project for multiple days.
  • It provides a media in which to work out issues and questions they are having during development.
  • It supports management of the many 'micro-tasks' that emerge during development. By maintaining a "to do" list, the engineer can keep track of things that need to be done later without interrupting the current task.
For over 10 years, I have kept a traditional engineering log in a series of notebooks. This blog represents an experiment in moving my private, personal, offline EL into a shared, public, online setting. I am interested in understanding what the trade-offs are between private offline ELs and public online ELs.

Pros and Cons:

Advantages of Online Engineering Logs:
  • People can comment on postings. So, you can indicate an issue you're having in your EL and someone might help you with it.
  • By tagging a post with the issue ID, you can search the online EL later to recover design rationale information.
  • Other developers in your workgroup can subscribe to your blog in order to keep track of what you're doing without interrupting you.
  • It is easy to include images.
  • It is easy to include links.
Disadvantages of Online Engineering Logs:
  • There is a huge privacy hit. It is definitely way different to be writing in a public forum vs. your own notebook where no one is going to see it. I am interested to see whether this is ultimately positive or negative.
  • You have to be online to manipulate them. I will perhaps be writing things on paper and transferring to this blog?
  • At first, you spend a lot of time fooling around with formatting.
  • It is hard to doodle.

Adapting the Blog media to Engineering Logs:
  • It's not clear that you want to maintain strict timestamps. For example, I want to maintain this list within this entry over time and edit it repeatedly. It would not make sense to build up this list by scattering it across all of the days that I came up with items. I have edited this entry repeatedly over the past several weeks, which seems perfectly appropriate. This seems quite counter to the conventional wisdom for maintaining engineering notebooks, where timestamping your thoughts is a critical feature.
  • Personal vs. Project Engineering logs. One could imagine keeping a single blog for a project, with multiple authors, or having each author keep their own blog, and use tags to indicate the project. I am not at all sure what the pros and cons these approaches are.
Related links:

Engineering notebooks are related to engineering logs but are more focussed on patent protection:


Some example online engineering logs:

None of these seem to fully exploit the possibilities of modern blogging infrastructure for supporting online engineering logs.