On 17/02/2013 21:48, Konstantin Kolinko wrote: > Adding "finals" to apparent constant fields is OK (e.g. those > CONNECTING, CONNECTED fields), but generic reducing visibilities here > and there seems wrong.
o.a.tomcat.jni.socket is the package added for spdy support. The code is still a work in progress. For example: - keepAliveTimeout (currently unused) - Look at the TODOs - hard-coded flags such as USE_TICKETS, nonBlockingAccept, debugPoll I have no problem reducing visibility as I did. UCDetector raises many more issues than I fixed. I left those because I judged that as the code was completed those issues would be resolved. > 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. I disagree with both suggestions. > That is just based on our policies. I personally do not use this > AprSocket class. Our policy varies depending on the stability of the code in question. This code is a work in progress (much like the WebSocket code) so we can change pretty much whatever we like. > 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). That should be the least of your worries. UCDetector doesn't spot use by the digester (hence suggests most getters and setters can be removed) nor does it spot use in generated code by Jasper (hence suggests large chunks of Jasper code can be removed). Because of the rather non-standard things we do in Tomcat, UCDetector isn't a tool that can be followed blindly. It needs to be used by someone with a reasonable understanding of the code and the suggestions (particularly those to remove code) need to be checked carefully before following them. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
