Re: [Classpathx-discuss] Activation implementation

[David Brownell]

Curious.  Maybe that's the exception that shows the rule?  :)  

A see a few classes in javax.mail.internet that do that
(looking just at the GNU classes).  Several of those look
like cleaned-up versions of some APIs I recall living in
the "sun.*" hierarchy back in JDK 1.0 days, before folk
at Sun started to push "javax.*" for all such APIs that
were widely needed but not worth the "java.*" costs.
Particularly the "base64" and "uuencode" I/O support!

- Dave


----- Original Message ----- 
From: "dog" <address@hidden>
To: "David Brownell" <address@hidden>
Cc: "Andrew Selkirk" <address@hidden>; <address@hidden>
Sent: Tuesday, December 04, 2001 12:33 AM
Subject: Re: [Classpathx-discuss] Activation implementation


> dixit david-b:
> > Isn't the point that the "activation" code should be used directly
> > to process mailcaps?  As a rule, one doesn't want javax.* code
> > to depend on any other package that's not called out by the API
> > specs (e.g. java.* is OK, neither sun.* nor gnu.* would be).
> 
> fyi:
> 
> both the sun and the gnu javax.mail.* implementations rely on
> implementation-specific (com.sun.* or gnu.*) utility streams that manage
> transfer encoding schemes.
> 
> also the java-to-mime and mime-to-java charset mappings are held in a
> separate resource in /META-INF outside the javax.* hierarchy.
> -- 
> dog
> zx750-p5 sl-mille ukrmma#18
> sol lucet omnibus ... praeter anglorum