On 3/8/06, Noel J. Bergman <email@example.com> wrote:
> Util-concurrent and newer crypto can be covered by other means, but I
> feel strongly about SASL.
On this we agree. But such benefits can often be obtained optionally, so
that the bulk of code does not require bleeding edge JDKs. If I want to use
MINA or ApacheDS on JDK 1.4, I would have to give up certain features, which
I gain by upgrading the JDK. That would be fine. For example, if we change
JAMES to use MINA and embed ApacheDS, I would not expect to be able to
support STARTTLS unless running on JDK 1.5.
I agree with you all ApacheDS and MINA users should be able to use them on JDK 1.4. My idea is to enable backward compatibility using bytecode manipulator which is a reasonable solution so the requirement remains the same and we can use advanced language features like generics and covariant return types yet. These language features help us to program more effectively and users to use cleaner API if they use the API on Java 5. We'll also have to be careful not to expose unsafe collections and APIs without backward compatibility where user and our software interacts, but it's just another matter.
what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6