On 9/6/17 01:42, Weijun Wang wrote: > Hi Joe > > When I said it's a compatible change, I meant the behavior is compatible, so either initSecContext or acceptSecContext still throws an exception instead of returning KRB-ERROR in a byte array. I know "compatibility" has lots of different meanings. > > If this method is called directly (not via refection) it will only compile with a new JDK. The program will not run with an old JDK because in Java the class file contains a magic number that increases with each version. This happens before you can see a NoSuchMethodError. Yes, compile-time will stop you. But if you distribute an app with someone else's jar... (I know you know this :-) ). > > If a developer wants an application or library runnable with an old JDK release but also like to benefit from the new method when running with a new release, some kind of reflection (GSSException.class.getMethod) is needed. In this case the developer will certainly be aware that this method might not exist and deal with it carefully. > > I feel hesitated to add reflection calls to all examples since that will look quite a mess. How about changing the last paragraph of Section 11 1) to something like: > > New JGSS programs should make use of this new method but it is not mandatory. > A program that intends to run with both old and new Java releases can use > reflection to check the availability of this new method and call it accordingly. I'm good with this. A slight change, though: "A program that intends to run with both old and new GSS Java bindings can use reflection to check the availability of this new method and call it accordingly." You're right that adding reflection to the example would just muddle it. In a perfect world, you'd have the latest jar with the an app written for it. So the example is good. But my experience with Java is that you may not get the jar you expect, and changes like this that are said to be "compatible" can often bite you. Joe > > Thanks > Max > > >> >> On Sep 6, 2017, at 3:00 AM, Joe Clarke <jclarke@xxxxxxxxx> wrote: >> >> Reviewer: Joe Clarke >> Review result: Ready >> >> I have been asked to do an LC review of draft-ietf-kitten-rfc5653bis on behalf >> of the ops directorate (OPS-DIR). >> >> This draft is an update to the Java bindings for the Generic Security Service >> API Version 2. >> >> Overall, this document is READY. It clearly articulates the reason for the >> modifications in the Appendix, and the changes feel straight-forward and make >> sense in light of the C API capabilities. >> >> My one concern is the compatibility of this change relative to the previous >> RFC5653 bindings. That is, the previous GSSException does not have a >> getOutputToken method. The sample application in the draft (section 7) calls >> this new method (and I like the same covers the relevant change in this doc). >> But what happens if my Java library is the older 5653 version? A >> NoSuchMethodError will be thrown, which is not ideal. >> >> If there is a set of static properties one can check to see if they have the >> supported version of the library (and thus the GSSException.getOutputToken() >> method exists), then the example should use those, and that process should be >> called out in the text. In lieu of that, introspection could be used to >> determine if the new method exists in the current library before it is used. >> >> This is immediately a concern with any API change, but since the appendix >> mentions this is a compatible change, I wanted to raise the point. >> >> _______________________________________________ >> Kitten mailing list >> Kitten@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/kitten >