Steve Loughran wrote:
I don't see reasons to try to back-port fixes made on 1.6 to the 1.5. Only
bugs identified by people running JDK 1.1 should make it to the 1.5 branch.
This should be the only activity going on in that 1.5 branch.
to date we are putting fixes to the 1.5 branch into 1.5.x, both minor and major, the zip work being the biggest. If any of that work had been in Java1.2 style, we couldnt have back ported it. Some of the changes (I think of the weak reference stuff) did have extra work to get into 1.1 compliance, incidentally.
Once 1.6 ships, then we can stop doing any work to the 1.5.x branch, so this issue of having to back port code into a java1.1. compatible branch goes away. Except for people who want to maintain 1.1 support, and they get to do the work themselves.
So we should wait till after the release to refactor our code?
Given the above, there are no reasons to limit the 1.6 code base from *any*
change that's JDK 1.2 (Java 2) compatible. That includes moving everything
to the Java 2 Collections.
I dont see the java2 collections as the compelling reason for this. They are nice, I use them, but it is really things like classloader, security manager, weak references and other major system changes that are forcing the move.
I also see the reflection tests for existance of 1.2 methods as adding substantial clutter to the code. I think removing these is quite valuable to people trying to understand the flow of our code. I think these should be eliminated at a rate greater than slowly but surely :).
As I said before, 1.5.x is a damn good release (once 1.5.3 is out), and
should more than satisfy JDK 1.1 users (wherever they're hiding). The buck
has to stop somewhere, and from the votes, it's clear 1.6 should depend on
JDK 1.2. This should not prevent though JDK 1.2 to be fully used everywhere
it's possible.
Steve and Costin might as well -1 the move to JDK 1.2 with this kind of thinking. --DD
I'm very happy with the move. I just don't think we should use this as an excuse to go s/Hashtable/HashMap/ s/Vector/ArrayList/ through all the
I would agree that this type of conversion is of limmited value. It should probably happen, but it would be low on the priorety list I think. Use of Iterator rather than enumeration might be of some value, again from the standpoint of code clarity.
old code, of which there is a frighteningly large amount, just for the sake of it. I know this is at odds with 'refactor mercilessly', but as Conor's test coverage data shows, we dont have the test coverage to refactor mercilessly :(
Perhaps, rather than saying don't refactor until 1.7, (or will it be 2.1?) we should say if you want to refactor it, and it doesn't have a test case write the testcases before refactoring it?
