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.
