Thank you for this explanation. It is good to actually look at the code
instead of making assumptions, which is what I have been doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I find
that there are differences between JSSE 1.0.3 and the packages in JDK
1.4, such that there is no backward compatibility. Basically, JSSE
1.0.x is a prototype, a hack through which Sun worked out the bugs,
culminating in the better implementation that they released in 1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense to tie
into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a clean
way to have one code base that will work the way we'd like it for both
cases.
Therefore, I think the solution for this is for Jakarta Commons Net to
take Rory Winston's suggestion and start a new branch of Commons Net for
JDK 1.4 only (for this and other reasons) and maintain two branches for
awhile, the current HEAD branch for 1.3 compatibility and the new branch
for 1.4. The new branch can use the javax.ssl.net classes, the old one
can use com.sun.net.
Jose Juan Montiel wrote:
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement FTPS
(in the way that Paul did and I modified, maybe there is another...)
are...
com.sun.net.ssl.KeyManagerFactory
(http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html)
com.sun.net.ssl.SSLContext
(http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html)
com.sun.net.ssl.TrustManager
(http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html)
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun says that
com.sun.net may go away with some future release, but not javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the stability is worth
it.
This three classes in JDK 1.4.2, were move to
javax.net.ssl.KeyManagerFactory
(http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html)
javax.net.ssl.SSLContext
(http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html)
javax.net.ssl.TrustManager
(http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html)
But if you download for example JDK 1.4.2 and look inside of (jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code...
In other way if use javax.net.ssl.KeyManagerFactory ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate...
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't know what the hell they're doing or who
on earth they are can, for only $2.95, get not
just a cup of coffee but an absolutely defining
sense of self: Tall. Decaf. Cappuccino.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
