On 17.02.2013 22:48, Konstantin Kolinko wrote: > 2013/2/18 <[email protected]>: >> Author: markt >> Date: Sun Feb 17 20:36:24 2013 >> New Revision: 1447074 >> >> URL: http://svn.apache.org/r1447074 >> Log: >> UCDetector >> - use final >> - reduce visibility >> - remove unused code > > Note that because of earlier (today's) Rainer's e-mail what you are > editing here belongs not to "trunk" but to 1.1.x branch of Tomcat > native. See r1447038, r1447045 > > Adding "finals" to apparent constant fields is OK (e.g. those > CONNECTING, CONNECTED fields), but generic reducing visibilities here > and there seems wrong. > > I think we either have to revert most of this commit and resort to the > usual routine of @deprecating and leave current visibilities as is, > or change external in tc-native to point to 7.0.x code instead of > trunk. > > That is just based on our policies. I personally do not use this > AprSocket class. > > > Other possible worry is that I think that UCDetector cannot detect > when something is used from the native side. I wonder whether it > proposed to delete the private constructor of o.a.t.jni.Error class, > which is not used from Java but is used from native/src/error.c. > (It is not a concern for these AprSocket, AprSocketContext classes as > they appear to be never mentioned in the native code).
One more aspect: there was no separate "trunk" version of the tcnative Java classes. Maintaining two versions didn't work well. That's why we falled back to linking branches/1.1.x jni classes to TC trunk. We could of course link 1.1.x to TC 7 and reintroduce the java classes to tcnative trunk as an external to TC trunk. I must say I doubt that this works. Most development on tcnative happens in 1.1.x, so IMHO the Java classes in tcnative 1.1.x seem to be better suited by a more relaxed version compatibility requirement. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
