+1 Geir Magnusson Jr wrote: > So it's javadoc. > > I vote that we : > > - take security up and outside of modules/ to a archive/ directory for now > - move security2->security > - over time, start migrating javadoc > > > > Mikhail Loenko wrote: >> 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 >>>>>>>>>> >>>>>>>>>> >> >> >
-- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
