Re: RFC: Jessie, enums, and loggers

[Casey Marshall]

Andrew John Hughes wrote:
> On Sat, 2005-06-04 at 12:02 -0700, Casey Marshall wrote:
>
>>Hi,
>>
>>I've started work on bringing Classpath's JSSE API (javax.net[.ssl]) up
>>to 1.5-level coverage, and the natural snag in doing this in mainline is
>>that it uses new language features -- two enums. It's easy enough to
>>write these two classes as pseudo-enums, but I was curious if there was
>>enough interest in making a PseudoEnum class that can be used by other
>>parts of the API. I'm not sure, but I think it should be possible to
>>make a mostly-binary-compatible enum class for pre-1.5 Java, but
>>wouldn't mind some advice if someone is more familiar with this.
>>
>
>
> There is already working enum support (with a suitable compiler)
> available on the generics branch of Classpath.  Thus, the general
> consensus on 1.5 extensions that need 1.5 language features (generics,
> annotations and enums primarily -- the rest are syntactic shortcuts) is
> to add this code to the generics branch.  I've recently been using this
> as my primary development environment (ecj+jamvm 1.3+classpath-generics)
> and haven't experienced any major problems.  We can't add enums to HEAD
> until there is more widespread support, primarily in the compiler realm
> (VM support is largely reflection-based; the binaries are compatible
> with the new data being stored in optional sections).
>
> I can see your reasoning for a pseudo-enum class but I would only think
> it necessary to add something to HEAD if it really can't work on the
> generics branch.  The two are relatively in sync (just about to do
> another merge of the two).  However, if there is a consensus that we
> should have such support, may I suggest that you don't write a new
> class, but instead simply drop the parametric typing from the one on the
> generics branch and merge this across.   This keeps the two fairly in
> sync, and means that we can just merge the two files when the time
> comes.  As a binary, the compiled version works fine with a VM that only
> supports 1.4 (I've used an older version of JamVM with enums simply by
> adding the class onto the classpath with a HEAD build).
>

My motivation is that I want to implement SSLEngine, the 1.5 NIO API, in
Jessie and rewrite the SSLSocket implementation using that class. It
wouldn't make much sense to have two implementations, one for
non-blocking IO, one for blocking, and, naturally, I want Jessie to
remain compatible with existing free compilers.

signature.asc
Description: OpenPGP digital signature