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
_______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
