-----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Berin Loritsch
Avalon 4 today fits a certain number of needs, and that is great.
Evolution is better than revolution in many respects. I think that is a perfectly natural way to move forward. But think about it, in Avalon 4 there is a bunch of cruft. It would be best to get rid of that cruft. So
a fresh Avalon 5 approach does not mean coming up with all new interfaces for what you need to do. It means that you should trim the fat and work from there. In doing this, you can remove all the ties that bind you to those undocumented or back-compatibility traps that add to the bulk and complexity of the current crop of containers.
Berin,
JDK 1.5 is so tempting. Getting rid of cruft and having a clean start is so tempting. Couple of questions and thoughts though:
It pains me to ask, but what about earlier virtual machines? I'm still fuzzy on JDK 1.5 (that's my fault), but will this stuff even run on earlier VM's? My impression is no. I'm still having trouble moving my developers from JDK 1.2 to 1.3, let alone 1.5! :) So, if Avalon 5 targets JDK 1.5, then what will Avalon offer to non-1.5 users? Do you, should we, even care?
Are you proposing a clean slate approach or a refactoring approach?
The former consensus was Avalon 4 for current crop and Avalon 5 for new work.
How you get there is up to you. Refactoring is the cleanest approach to minimizing impact on users. If you simply get rid of all deprecated stuff, it is no longer back compatible, but users who are already up to speed won't have any impact.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
