Re: [cp-patches] [RFC] JSSE 1.5 classes and methods

[Mark Wielaard]

Hi Casey,

Chris already replied to this and I largely agree with him. But since
you didn't follow up to this yet and I think people would like this
functonality let me also reply.

On Mon, 2005-09-12 at 22:33 -0700, Casey Marshall wrote:
> Attached is a patch to implement most of the javax.net.ssl methods  
> and classes introduced in J2SE 1.5.
> 
> This isn't complete, partly due to missing classes elsewhere  
> (java.security.KeyStore.Builder) and due to the introduction of two  
> enums. To work around the latter, I've created a 'PseudoEnum' class  
> that mostly matches 'Enum,' and extend that for the enums in the JSSE  
> API.
> 
> I'm looking for comments about this approach, since I imagine it is  
> controversial; this looks closely compatible with 1.5, according to  
> japicompat, but I'm not sure if that level of compatibility is close  
> enough. There are a couple alternatives to a new class under 'gnu':
> 
>    - Implement a pre-1.5 java.lang.Enum, and use that.
>    - Don't use any superclass, and treat the two enums as one-off  
> types that contain all the methods they currently inherit from the  
> superclass.

I also feel that introducing a pre-1.5 java.lang.Enum class is just
asking for trouble. Since this is just for these two classes (State and
HandshakeState) then I would go either for your PseudoEnum or the
approach that just doesn't use a superclass. They really are just
type-safe constants so I would go for the don't use super class route
here. We could think a bit about serialization in which case you have to
take into account keeping the instances unique and make sure the
ordinals match up. But I wouldn't really worry in this specific case and
just drop everything of 'Enum' that you don't explicitly need. Just
treat them as one-off types that represent constants and be done with
it. If the static field names match it should even be source and binary
compatible with an implementation based on "real Enums".

Is this the only place where the new functionality you want to provide
uses 1.5 language constructs?

> My reason for doing this is to introduce NIO support in Jessie  
> (http://jessie.nongnu.org/), and to eventually see projects like  
> gumdrop (http://gumdrop.nongnu.org/) have SSL support through Jessie,  
> on existing Classpath runtimes.

That would indeed be really cool to have!

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part