I've reviewed exception classes: General: security has javadocs that reword SUN's spec, while sec2 does not have security seems to follow 1.4 spec, while sec2 - 1.5
AccessControlException - almost no difference. permission field is private in s2 and package-vis in sec PrivilegedActionException - almost the same. the difference is in toString() DigestException, GeneralSecurityException InvalidAlgorithmParameterException InvalidKeyException KeyException NoSuchAlgorithmException SignatureException cert/CertificateEncodingException cert/CertificateException cert/CertificateParsingException cert/CRLException - sec misses two constructors (new in 1.5) and serialVersionUID. sec2 has them. InvalidParameterException NoSuchProviderException cert/CertificateExpiredException cert/CertificateNotYetValidException - sec misses serialVersionUID. sec2 has it. KeyManagementException KeyStoreException ProviderException UnrecoverableEntryException UnrecoverableKeyException acl/* spec/* cert/CertStoreException cert/CertPathBuilderException cert/CertPathValidatorException - present in security2 only The question is: are we going to take javadocs? Thanks, Mikhail On 2/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > I'm going to walk method by method, compare and present results starting > with the easiest cases. > > I've already taken some look at security so I think it would not be > very difficult - > it has 50+ classes, ~20 of them are exceptions, there are some interfaces... > > Thanks, > Mikhail > > On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > > Tim Ellison wrote: > > > +1 to consolidating on a single security module. > > > I'm also interested to hear what merging Mikhail has in mind. > > > > > > I was led to believe that security2 was a proper superset of security, > > > so we should be able to do a 'big bang' switch. The security_orig won't > > > be too far away if we need to pull something in. (Perhaps move it out > > > of trunk/modules/ to avoid confusion?) > > > > Right - it will live forever in SVN, and of course we always can "copy > > forward" in time if we need to - i.e. copy from some past rev into > > "now", whenever that is. > > > > I just don't want to lose anything useful that may be in security... > > > > geir > > > > > > > > Regards, > > > Tim > > > > > > Geir Magnusson Jr wrote: > > >> Before you do that... > > >> > > >> What are you thinking as your approach? > > >> > > >> geir > > >> > > >> Mikhail Loenko wrote: > > >>> I suggest merging these two bundles. I can do this and provide a > > >>> patch... > > >>> > > >>> Thanks, > > >>> Mikhail > > >>> > > >>> On 2/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > >>>> security classes are a subset of security2 classes. > > >>>> > > >>>> security2 is 1.5-ready while security has javadocs. What do you mean > > >>>> by 'better'? > > >>>> Are there any original approaches or efficient algorithms used in > > >>>> security? > > >>>> > > >>>> Thanks, > > >>>> Mikhail > > >>>> > > >>>> > > >>>> On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > >>>>> Hm. I thought security was stubs, but it isn't. > > >>>>> > > >>>>> Is there anything in security/ that we don't have in security2/ or is > > >>>>> better? > > >>>>> > > >>>>> geir > > >>>>> > > >>>>> Geir Magnusson Jr wrote: > > >>>>>> Unless I hear massive bellowing in opposition, I'm going to move > > >>>>>> security -> security_orig and security2 -> security sometime > > >>>>>> tomorrow. > > >>>>>> Please register protests now... > > >>>>>> > > >>>>>> geir > > >>>>>> > > >>>>>> > > >>> > > > > > >
