Markus Wiederkehr wrote:
On Tue, Jan 6, 2009 at 2:19 PM, Stefano Bagnara <[email protected]> wrote:
Markus Wiederkehr ha scritto:
Mime4j uses the retrotranslator maven plugin to build a JDK1.4
compatible jar file. Now I've noticed a few problems with that.
For example CipherStorageProvider contains this innocent looking lines of code:
catch (NoSuchAlgorithmException e) {
throw new IllegalArgumentException(e);
}
The problem is that constructor IllegalArgumentException(Throwable)
was introduced in Java 5 and retrotranslator wants to embed its own
version of IllegalArgumentException because of that.
Another problem is the @Deprecated annotation used in a few classes.
Retrotranslator seems to retain that annotation. Annotations require
enums, enums require classes from java.util.concurrent, and so on.
Resulting in over 130 classes that would need to be embedded, adding
200 kb to the retrotranslated jar file.
I also think Iterable would be nice to have in a few places. Enums, too.
All these features can be used of course, but not without embedding a
lot of classes or adding a dependency on retrotranslator-runtime.jar.
We already had this discussion and I was in favor of keeping JDK1.4
support because it comes cheaply. I'm not so sure anymore if it's
worth it.
+1 If someone will need java 1.4 support they will help reintroducing
the retrotranslator stuff. AFAIK no mime4j user expressed the need to
have a java 1.4 version yet.
Another solution would be to declare a dependency on
retrotranslator-runtime in the POM using the scope "provided".
This way retrotranslator translates java.lang.Enum in
net.sf.retrotranslator.runtime.java.lang.Enum_, for example. The
translated Enum_ does not have to be embedded, instead the 1.4 version
of Mime4j would have a dependency on retrotranslator-runtime.
"Provided" would ensure that the regular Java 5 version of Mime4j
would not be affected because the dependency is not transitive.
This is the solution I would like to go for if nobody objects.
+1 to dropping support for java 1.4 altogether. It is just not worth the
trouble.
Oleg
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
