Mikhail Loenko wrote: > Sounds reasonable. > > Sure, I can make 'getInstance' functionality visible as an internal API. > > So we put classes that has many internal dependencies into the same component, > but not only that. For example java.lang.Error and java.lang.Ecxeption do not > have internal dependencies but we put them into the same component.
I agree, let's not split a package across multiple modules(*) (*) the exception that proves the rule here is KERNEL, which does contain package fragments. But KERNEL is special. > Having internal dependency is not the only reasong to go into the same > component. Other reasons could be belonging to the same package or having > some semantical connection. I agree. > For example I'd put java.security.cert and javax.security.cert into the same > component. Sounds great. (In this case the 'x' is merely an artifact of Java's history.) > What do you think? +1 Regards, Tim > On 2/15/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> Mikhail Loenko wrote: >>> There is coupling. >>> BTW... Could you give an example of "close" and "weak" coupling? >> Sure. The goal is to define modules that represent functional units >> whose implementation can be contained within the module as much as >> possible. The measure of coupling is the number of internal-API >> dependencies shared between two modules. (Internal-APIs are those that >> Anton described, and that we are proposing to put into >> org.apache.harmony.<module_name>.<whatever> packages and explicitly >> export from the module.) >> >> For example, we have code like LUNI and NIO that require some >> non-Java-API dependencies upon one another, but these are 'weakly' >> coupled because they are coupled by a small number of 'internal APIs'. >> >> Where the code has a large number of implementation dependencies that >> you would not want to export then that is an indication of close >> coupling. So, for example, if we tried to separate java.io into its own >> module we would have lots of impl dependencies between that module and >> LUNI that would indicate poor modularity. Similarly trying to move the >> NIO buffers impls out to a separate module to NIO would result in those >> two modules being closely coupled. >> >>> The following two groups of classes use the same internal stuff: >>> GROUP1 (use/provide inernal implementation of 'getInstance' ): >> Can you make this visible as an internal API (e.g. exported factory type)? >> >>> java.security.AlgorithmParameterGenerator >>> java.security.AlgorithmParameters >>> java.security.KeyFactory >>> java.security.KeyPairGenerator >>> java.security.KeyStore >>> java.security.KeyStoreSpi >>> java.security.MessageDigest >>> java.security.Provider >>> java.security.SecureRandom >>> java.security.Security >>> java.security.Signature >>> java.security.cert.CertPathBuilder >>> java.security.cert.CertPathValidator >>> java.security.cert.CertStore >>> java.security.cert.CertificateFactory >>> javax.crypto.Cipher >>> javax.crypto.ExemptionMechanism >>> javax.crypto.KeyAgreement >>> javax.crypto.KeyGenerator >>> javax.crypto.Mac >>> javax.crypto.SecretKeyFactory >>> javax.net.ssl.KeyManagerFactory >>> javax.net.ssl.SSLContext >>> javax.net.ssl.SSLServerSocketFactory >>> javax.net.ssl.SSLSocketFactory >>> javax.net.ssl.TrustManagerFactory >>> >>> GROUP2 (all use internal implementation of ASN.1): >> >> The ASN.1 code is a good example of an internal-API that we would want >> to expose to other module developers. >> >> To be clear, we are not extending the Java API here, just making it >> visible as a contract that replacements to <whatever module implements >> it> must conform. >> >>> java.security.cert.PolicyQualifierInfo >>> java.security.cert.TrustAnchor >>> java.security.cert.X509CRLSelector >>> java.security.cert.X509CertSelector >>> javax.crypto.EncryptedPrivateKeyInfo >>> javax.security.auth.kerberos.KerberosKey >>> javax.security.auth.kerberos.KerberosTicket >>> >>> All other dependencies seem to be public ones. >> Sounds good. >> >> Regards, >> Tim >> >> >>> On 2/14/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >>>> Mikhail Loenko wrote: >>>>> Tim >>>>> >>>>> On 2/13/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >>>>>> Mikhail Loenko wrote: >>>>>>> It looks good but it is not clear where would you put certification >>>>>>> stuff. >>>>>>> According to SUN's guide it is splitted between JSSE and general >>>>>>> security. >>>>>>> (According to SUN general security includes also crypto architecture) >>>>>> I wouldn't get too hung up about where Sun put it. There is likely a >>>>>> different partitioning about where the architectural/semantic boundaries >>>>>> are best placed, and how we componentize the implementation. >>>>>> >>>>>> Looking into this a bit more, the certificate management >>>>>> (java.security.cert.*) code should likely go in 'general security'. >>>>>> >>>>>> It is mostly instinct behind the decision, but that was formed by the >>>>>> following reasoning: >>>>>> >>>>>> Historical - JCE, JSSE and JAAS used to be optional packages for the JDK >>>>>> at a time when the certificate management code was included in the JDK >>>>>> By process of exclusion - the other modules ('crypto', 'x-net' and >>>>>> 'jaas') are self-contained and can be removed without breaking any other >>>>>> APIs. >>>>> That was in the past. In 1.5 for example >>>>> java.security.KeyStore.SecretKeyEntry.getSecretKey() >>>>> returns >>>>> javax.crypto.SecretKey >>>>> >>>>> Method >>>>> java.security.AuthProvider.login() >>>>> takes arguments >>>>> javax.security.auth.Subject and >>>>> javax.security.auth.callback.CallbackHandler >>>>> >>>>> Another example >>>>> java.net.SecureCacheResponse.getPeerPrincipal() >>>>> throws >>>>> javax.net.ssl.SSLPeerUnverifiedException >>>>> >>>>> So, none of the components is self-contained. >>>> Right, but these are all public type dependencies, for sure the modules >>>> will have many dependencies on other modules' public types. >>>> Do you see a close coupling of the implementation types too? >>>> >>>> Regards, >>>> Tim >>>> >>>>> Removing certificate management would break APIs in java.util.jar >>>>>> and java.security so it doesn't make sense to separate it from them. >>>>>> >>>>>> US Export Control office is less interested in digital >>>>>> signing/verification than they are in the cryptography and secure >>>>>> communications packages. Keeping them pluggable makes sense. >>>>>> >>>>>> Perhaps we should name the 'jaas' package 'auth'. JAAS may be a >>>>>> protected trademark. The org.ietf.jgss package may belong in 'auth' as >>>>>> well. >>>>>> >>>>>> Regards, >>>>>> Tim >>>>>> >>>>>>> I'd rather put it into crypto (or maybe into x-net) - all of them use >>>>>>> service-provider architecture. What do you think? >>>>>>> >>>>>>> Thanks, >>>>>>> Mikhail >>>>>>> >>>>>>> On 2/10/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >>>>>>>> Mikhail Loenko wrote: >>>>>>>>> What I'd like to propose is: >>>>>>>>> >>>>>>>>> 1. separate Authentication and Authorization stuff (javax.security >>>>>>>>> package) from general security >>>>>>>> Ok, so I can see this. >>>>>>>> >>>>>>>>> 2. unite crypto (java.security) and crypto extension (javax.crypto) >>>>>>>> but this makes no sense to me. Why would you want to unite JCE with >>>>>>>> general security? There is no close coupling afaict. >>>>>>>> >>>>>>>> How about >>>>>>>> - general security >>>>>>>> - crypto >>>>>>>> - x-net >>>>>>>> - jaas >>>>>>>> >>>>>>>> there may be good reason to want to replace crypto independently of >>>>>>>> general security. Am I missing something? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Tim >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Tim Ellison ([EMAIL PROTECTED]) >>>>>>>> IBM Java technology centre, UK. >>>>>>>> >>>>>> -- >>>>>> >>>>>> Tim Ellison ([EMAIL PROTECTED]) >>>>>> IBM Java technology centre, UK. >>>>>> >>>> -- >>>> >>>> Tim Ellison ([EMAIL PROTECTED]) >>>> IBM Java technology centre, UK. >>>> >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.