From daniel.fuchs at oracle.com Fri Nov 16 02:18:52 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 16 Nov 2012 11:18:52 +0100 Subject: jmx-dev Review: JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code Message-ID: <50A6130C.9040400@oracle.com> Hi, This is a call for review for JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code I have also added @Override annotations wherever they were missing, but only in the files that had warnings. best regards, -- daniel From stuart.marks at oracle.com Fri Nov 16 16:59:04 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 16 Nov 2012 16:59:04 -0800 Subject: jmx-dev Review: JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code In-Reply-To: <50A61662.5030307@oracle.com> References: <50A6130C.9040400@oracle.com> <50A61662.5030307@oracle.com> Message-ID: <50A6E158.6050204@oracle.com> > This is a call for review for > JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code > > I have also added @Override annotations wherever they were missing, > but only in the files that had warnings. > > Hi, overall mostly looks fine. The things that caught my eye were a number of occurrences of wildcarded generics when it appears that a specific type could be used. === EnumRowStatus.java === Possibly join lines shortened by using diamond, if there's room, e.g. lines 285, 287. === IPAcl/JJTParserState.java, 32-33 === Can this be Vector instead? === IPAcl/Parser.java, line 1171 === Should that be Vector or Vector ? Looks like it really contains int[]. Maybe Vector ? === InetAddressAcl.java === The methods getTrapDestinations(), getTrapCommunities(), getInformDestinations(), getInformCommunities() all list specific types as elements of returned enumeration in their doc, but all return Enumeration. Can specific types be used instead? === SnmpRequestTree.java === The getSubRequests() method returns Enumeration, but it looks like it could return Enumeration instead. This would remove some casts from callers, such as in SnmpMib.java. === SnmpMibAgent.java === Did you intend to omit concatVector(Vector, Vector) ? === SnmpMibRequest.java and SnmpMibSubRequest.java === Can getElements() return Enumeration? That's what it says are contained in the enumeration. This will remove some casts in calling code. === SnmpMibTable.java === Did you intend to delete getInsertionPoint(SnmpOid) and some associated javadoc? Line 2359 typo, "hastable" => "hashtable" Also, should the values in handbackTable be Vector or Vector ? It looks like the callers treat them as Vector but it's declared here as Vector. It's not a huge problem since the callers seem to have to do casting anyway, but the semantics are slightly different. Vector means a vector of some specific type that's not known here, whereas Vector means a vector of objects that are subclasses of Object -- essentially anything. I'm not sure which is appropriate in this case, but it doesn't seem quite right to mix them. === CommunicatorServer.java === Looks like fatherThread and loadClass() were removed, presumably they're dead code? This is a bit beyond what we usually do for warnings cleanup, although if you're confident these are safe changes I don't object to them. === SnmpRequestHandler.java === Can 'mibs' be of type Vector ? Maybe the 'Vector m' constructor argument can also be Vector ? ======= Thanks, s'marks From daniel.fuchs at oracle.com Mon Nov 19 06:36:49 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 19 Nov 2012 15:36:49 +0100 Subject: jmx-dev Review: JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code In-Reply-To: <50A6E158.6050204@oracle.com> References: <50A6130C.9040400@oracle.com> <50A61662.5030307@oracle.com> <50A6E158.6050204@oracle.com> Message-ID: <50AA4401.3080100@oracle.com> On 11/17/12 1:59 AM, Stuart Marks wrote: >> This is a call for review for >> JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code >> >> I have also added @Override annotations wherever they were missing, >> but only in the files that had warnings. >> >> > > Hi, overall mostly looks fine. The things that caught my eye were a > number of occurrences of wildcarded generics when it appears that a > specific type could be used. > > === EnumRowStatus.java === > > Possibly join lines shortened by using diamond, if there's room, e.g. > lines 285, 287. Will do. > > === IPAcl/JJTParserState.java, 32-33 === > > Can this be Vector instead? Good catch. nodes can be Stack. marks can be Stack as well. BTW - this code was originally generated by jjtree. > === IPAcl/Parser.java, line 1171 === > > Should that be Vector or Vector ? Looks like it really > contains int[]. Maybe Vector ? Vector is not an option - since Vector.addElement() is called. Vector would be the right thing to do. Will do. > > === InetAddressAcl.java === > > The methods getTrapDestinations(), getTrapCommunities(), > getInformDestinations(), getInformCommunities() all list specific types > as elements of returned enumeration in their doc, but all return > Enumeration. Can specific types be used instead? > > === SnmpRequestTree.java === > > The getSubRequests() method returns Enumeration, but it looks like it > could return Enumeration instead. This would remove > some casts from callers, such as in SnmpMib.java. These are undocumented sun proprietary public interfaces subject to change without notice, so backward compile-compatibility is not enforced - right? Can we do that in a 'cleanup warnings' bug? > > === SnmpMibAgent.java === > > Did you intend to omit concatVector(Vector, Vector) ? Yes. That's dead code. The best way to fix warnings in dead code is to remove the dead code - IMHO ;-) > > === SnmpMibRequest.java and SnmpMibSubRequest.java === > > Can getElements() return Enumeration? That's what it says > are contained in the enumeration. This will remove some casts in calling > code. > > === SnmpMibTable.java === > > Did you intend to delete getInsertionPoint(SnmpOid) and some associated > javadoc? Yes. dead code. > Line 2359 typo, "hastable" => "hashtable" > > Also, should the values in handbackTable be Vector or Vector > ? It looks like the callers treat them as Vector but it's declared > here as Vector. > > It's not a huge problem since the callers seem to have to do casting > anyway, but the semantics are slightly different. Vector means a > vector of some specific type that's not known here, whereas > Vector means a vector of objects that are subclasses of Object > -- essentially anything. I'm not sure which is appropriate in this case, > but it doesn't seem quite right to mix them. They are Vector. But some time we don't care about what's in them - so we can manipulate them as Vector. They can't be declared as Vector however since it would prevent adding to them... > > === CommunicatorServer.java === > > Looks like fatherThread and loadClass() were removed, presumably they're > dead code? This is a bit beyond what we usually do for warnings cleanup, > although if you're confident these are safe changes I don't object to them. Yes - dead code. father thread was private, and loadClass package protected - so we can safely remove them. > > === SnmpRequestHandler.java === > > Can 'mibs' be of type Vector ? > > Maybe the 'Vector m' constructor argument can also be > Vector ? Yes - it can - good point. > > ======= > > Thanks, > > s'marks From stuart.marks at oracle.com Mon Nov 19 22:51:24 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 19 Nov 2012 22:51:24 -0800 Subject: jmx-dev Review: JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code In-Reply-To: <50AA4401.3080100@oracle.com> References: <50A6130C.9040400@oracle.com> <50A61662.5030307@oracle.com> <50A6E158.6050204@oracle.com> <50AA4401.3080100@oracle.com> Message-ID: <50AB286C.9040700@oracle.com> Hi Daniel, Comments inline. On 11/19/12 6:36 AM, Daniel Fuchs wrote: > On 11/17/12 1:59 AM, Stuart Marks wrote: >> >> === InetAddressAcl.java === >> >> The methods getTrapDestinations(), getTrapCommunities(), >> getInformDestinations(), getInformCommunities() all list specific types >> as elements of returned enumeration in their doc, but all return >> Enumeration. Can specific types be used instead? >> >> === SnmpRequestTree.java === >> >> The getSubRequests() method returns Enumeration, but it looks like it >> could return Enumeration instead. This would remove >> some casts from callers, such as in SnmpMib.java. > > These are undocumented sun proprietary public interfaces subject > to change without notice, so backward compile-compatibility is > not enforced - right? > Can we do that in a 'cleanup warnings' bug? Well, they may be undocumented, but that doesn't mean that nobody depends on them. :-/ I think these changes are all binary compatible, since the erasures of the new versions are all the same as the raw type. Source compatibility is a different issue. Actually it doesn't seem too bad. The old version returned a raw Enumeration, and the new version returns either an Enumeration or Enumeration or whatever. So callers will get a rawtypes warning when they recompile, but only if they enable the right -Xlint option. Given that the compatibility issues seem quite minor, and our assumption that it's unlikely that code outside the JDK uses these interfaces, these changes seem pretty safe. Sound reasonable? >> === SnmpMibAgent.java === >> >> Did you intend to omit concatVector(Vector, Vector) ? > > Yes. That's dead code. The best way to fix warnings in dead code is to > remove the dead code - IMHO ;-) OK. I just wanted to mention these deletions, since it's a bit unusual to delete dead code as part of warnings cleanup. (Do you have a tool that issues warnings for dead methods? I don't think javac does.) If you're sure the code really is dead -- not just mostly dead :-) -- then it's fine to remove. >> === SnmpMibTable.java === >> >> Also, should the values in handbackTable be Vector or Vector >> ? It looks like the callers treat them as Vector but it's declared >> here as Vector. >> >> It's not a huge problem since the callers seem to have to do casting >> anyway, but the semantics are slightly different. Vector means a >> vector of some specific type that's not known here, whereas >> Vector means a vector of objects that are subclasses of Object >> -- essentially anything. I'm not sure which is appropriate in this case, >> but it doesn't seem quite right to mix them. > > They are Vector. But some time we don't care about what's > in them - so we can manipulate them as Vector. They can't be > declared as Vector however since it would prevent adding > to them... If you think it makes sense this way, I'm ok with it. Thanks for acting on my other comments. s'marks From daniel.fuchs at oracle.com Tue Nov 20 02:15:45 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 20 Nov 2012 11:15:45 +0100 Subject: jmx-dev Review: JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code In-Reply-To: <50AB286C.9040700@oracle.com> References: <50A6130C.9040400@oracle.com> <50A61662.5030307@oracle.com> <50A6E158.6050204@oracle.com> <50AA4401.3080100@oracle.com> <50AB286C.9040700@oracle.com> Message-ID: <50AB5851.3010809@oracle.com> On 11/20/12 7:51 AM, Stuart Marks wrote: > Well, they may be undocumented, but that doesn't mean that nobody > depends on them. :-/ > > I think these changes are all binary compatible, since the erasures of > the new versions are all the same as the raw type. > > Source compatibility is a different issue. Actually it doesn't seem too > bad. The old version returned a raw Enumeration, and the new version > returns either an Enumeration or Enumeration or > whatever. So callers will get a rawtypes warning when they recompile, > but only if they enable the right -Xlint option. > > Given that the compatibility issues seem quite minor, and our assumption > that it's unlikely that code outside the JDK uses these interfaces, > these changes seem pretty safe. > > Sound reasonable? Yes - I will make the changes! -- daniel From daniel.fuchs at oracle.com Wed Nov 21 06:15:44 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 21 Nov 2012 15:15:44 +0100 Subject: jmx-dev Review: JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code In-Reply-To: <50AB5851.3010809@oracle.com> References: <50A6130C.9040400@oracle.com> <50A61662.5030307@oracle.com> <50A6E158.6050204@oracle.com> <50AA4401.3080100@oracle.com> <50AB286C.9040700@oracle.com> <50AB5851.3010809@oracle.com> Message-ID: <50ACE210.6060204@oracle.com> Hi, Here is a revised webrev taking into account Stuart's comments. http://cr.openjdk.java.net/~dfuchs/JDK-8003476/webrev.01/ I have identified further places where Object or could be replaced with more specific types - which allowed me to get rid of yet more ugly casts. best regards, -- daniel On 11/20/12 11:15 AM, Daniel Fuchs wrote: > On 11/20/12 7:51 AM, Stuart Marks wrote: >> Well, they may be undocumented, but that doesn't mean that nobody >> depends on them. :-/ >> >> I think these changes are all binary compatible, since the erasures of >> the new versions are all the same as the raw type. >> >> Source compatibility is a different issue. Actually it doesn't seem too >> bad. The old version returned a raw Enumeration, and the new version >> returns either an Enumeration or Enumeration or >> whatever. So callers will get a rawtypes warning when they recompile, >> but only if they enable the right -Xlint option. >> >> Given that the compatibility issues seem quite minor, and our assumption >> that it's unlikely that code outside the JDK uses these interfaces, >> these changes seem pretty safe. >> >> Sound reasonable? > > Yes - I will make the changes! > > -- daniel > > From stuart.marks at oracle.com Tue Nov 27 16:52:52 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 27 Nov 2012 16:52:52 -0800 Subject: jmx-dev Review: JDK-8003476 Cleanup warnings in com.sun.jmx.snmp code In-Reply-To: <50ACE210.6060204@oracle.com> References: <50A6130C.9040400@oracle.com> <50A61662.5030307@oracle.com> <50A6E158.6050204@oracle.com> <50AA4401.3080100@oracle.com> <50AB286C.9040700@oracle.com> <50AB5851.3010809@oracle.com> <50ACE210.6060204@oracle.com> Message-ID: <50B56064.9050103@oracle.com> Hi, sorry for the delay, long holiday weekend here in the U.S. The latest webrev looks good, just a couple comments on indentation. See below. No need to reissue a webrev after fixing these up. I guess you can push this yourself. Thanks, s'marks ------- SnmpMibTable.java, lines 1818, 1832 -- Adjust indentation so that second parameter lines up with open-parenthesis on the previous line. SnmpAdaptorServer.java, lines 1345-1350, 2321 -- Maybe adjust indentation to line up with open-parenthesis, although this may make the lines too long. (Not that the code in this area respects any kind of width limit.) Use your judgment. ------- On 11/21/12 6:15 AM, Daniel Fuchs wrote: > Hi, > > > Here is a revised webrev taking into account Stuart's comments. > > http://cr.openjdk.java.net/~dfuchs/JDK-8003476/webrev.01/ > > I have identified further places where Object or could be > replaced with more specific types - which allowed me to get > rid of yet more ugly casts. > > best regards, > > -- daniel > > > On 11/20/12 11:15 AM, Daniel Fuchs wrote: >> On 11/20/12 7:51 AM, Stuart Marks wrote: >>> Well, they may be undocumented, but that doesn't mean that nobody >>> depends on them. :-/ >>> >>> I think these changes are all binary compatible, since the erasures of >>> the new versions are all the same as the raw type. >>> >>> Source compatibility is a different issue. Actually it doesn't seem too >>> bad. The old version returned a raw Enumeration, and the new version >>> returns either an Enumeration or Enumeration or >>> whatever. So callers will get a rawtypes warning when they recompile, >>> but only if they enable the right -Xlint option. >>> >>> Given that the compatibility issues seem quite minor, and our assumption >>> that it's unlikely that code outside the JDK uses these interfaces, >>> these changes seem pretty safe. >>> >>> Sound reasonable? >> >> Yes - I will make the changes! >> >> -- daniel >> >> >