gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Upgraded vmgump to JDK 1.5
Date Sun, 19 Feb 2006 21:03:07 GMT

"Leo Simons" <> wrote in message
> On Sun, Feb 19, 2006 at 10:37:37AM +0100, Stefan Bodewig wrote:
>> On Sat, 18 Feb 2006, Leo Simons <> wrote:
>> > This is to "solve" the junit stuff right?
>> JUnit is the most prominent project to require Java 5 ATM, but hardly
>> the only one.  We've had other projects breaking for months now
>> because we didn't provide a Java 5 environment.
> Oh. Do you have a (partial) list (in your head or elsewhere)? Are these
> projects "leaf" projects or "core" projects?

I believe that mina was the only one with a significant number of dependant 
projects (and, it still won't build since it now requires Maven2 :).

JacORB, jdbm were also on the list.  I think that their were about 4 or 5 
others, but I don't remember them off the top of my head.

>> > I'm personally not happy with how effectively there's this one
>> > project run by a bunch of people who don't particulary understand
>> > enough about backwards compatibility
>> I don't think you are fair here.  JUnit 4 uses a completely different
>> approach that has been enabled by annotations.  I'm a happy NUnit user
>> (.NET unit testing framework) and can tell you that using annotations
>> really is a step forward over the JUnit 3.x approach.
> Right. The other big one is the template collections (whatever its called,
> the <Foo>List stuff). I understand how cool and useful it is. I agree I
> wasn't fair, sorry.
> However, JUnit is one of the "corest of core" projects, much like Xerces
> and/or Ant. The ant project is an example of a project which is very
> aware of its role like that. Log4j is one where its lead to friction in
> the past but where gump in the end was used as a tool to have a net
> positive effect on e.g. migration strategies and backward compatibility
> and the like.
> I feel that gump is failing in that role with this jdk 1.4 -> 1.5 stuff,
> and failing in a big way, and I find it frustrating that we're not able as
> a team to contribute a whole lot to easing this kind of thing and this 
> kind
> of mess.
> Its my perception that the people working on JUnit 4 have decided to take
> a "bite the bullet" (or the "sour apple") approach to this migration, and
> I think this is wrong, and I know there is no way I can help here or 
> change
> it and I probably shouldn't try (well, of course I could go and try and 
> change
> the java landscape by contributing to having open source and "open" style
> change management processes for the JDK...hey...ehm...), and I'm sorry for
> mentioning "people" instead of "project" and casting it as a "personal"
> thing. The big picture is just so ugly.
>> And when it comes to backwards compatibility, it is very likely that
>> all our JUnit 3.8 tests in Gump will work with JUnit 4 as well.  It's
>> simply that JUnit wants to use annotations and the only way forward
>> was to require Java 5 at compile time.
> Yeah I know.
> LSD 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message