classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Casey Marshall
Subject: Re: [cp-patches] [RFC] JSSE 1.5 classes and methods
Date: Thu, 27 Oct 2005 20:27:16 -0700

On Oct 27, 2005, at 9:28 AM, Mark Wielaard wrote:

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.


Okay. One issue with this is that since Sun introduced new abstract methods to a few classes and interfaces (boo Sun! Booo!) existing Jessie releases won't compile against them.

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".


That matches my thinking; I'll go with 'PseudoEnum' if/when I check these in. Since there isn't any software written yet that will use them, I will wait on checking these in.

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


Yes.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]