Re: hg: jdk7/jsn/jdk: 6717876: Make java.net.NetworkInterface.getIndex() public
Andrew John Hughes wrote: On 27/08/2008, Mark Wielaard <[EMAIL PROTECTED]> wrote: Hi, On Mon, Aug 25, 2008 at 12:43:59PM +, [EMAIL PROTECTED] wrote: > URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/f4289d75cd29 > > 6717876: Make java.net.NetworkInterface.getIndex() public > Summary: Make getIndex() and getByIndex() public. Required a name change in native code > Reviewed-by: alanb, chegar, michaelm This seems to introduce a new public API in the java.net package. I was wondering how that works for someone that wants to introduce such things in openjdk. I do see the bug report that mentions making this public should be done for JDK7. But there seems to missing a real justification for adding these new interfaces. Is there any policy for introducing such new public interfaces? I might be reading this wrongly but it seems the only thing this API does is expose some random internal "index" numbers for an NetworkInterface. Seeing that there are no guarantees on whether there are index numbers in the first place for any or all interfaces it seems not that useful imho. An example of how an application would use this new interface would be nice to get a better idea in what situations this would be used. Thanks, Mark I also thought the change was odd, given it adds two methods based on otherwise undefined 'system specific' values. From the methods given, there is no information as to how many of these index numbers are in use. The only way I can see to enumerate them is to get all instances of NetworkInterface and call getIndex() on each. I assume that the application of these methods is to resolve ambiguity between two interfaces with the same name but a different index, but it would be more helpful if the Javadoc included example usage and some information on what these numbers might be. More generally, it's not clear where the decision was made to make this part of the (as yet non-existent) JDK7 platform JSR. Will there be more insight into this process from outside Sun in the near future A network interface index is hardly a "random internal number". This is a value attributed by the operating system and is as significant as an interface name. The reason it was made public is because it's an information that is needed by other APIs (like NIO) and applications. An example is that such an index can be used inside an IPv6 address to force routing through a specific interface. There are multiple, legitimate, uses of an interface index. Initially these 2 methods were kept private because of some security concerns. After consideration and maturation of the NetworkInterface class, these concerns were deemed not justified any longer. begin:vcard fn:Jean-Christophe Collet n:Collet;Jean-Christophe org:Sun Microsystems;Java Security and Networking adr:;;2 rue de Jargonnant;Geneva;GE;1702;Switzerland email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard
Re: hg: jdk7/jsn/jdk: 6717876: Make java.net.NetworkInterface.getIndex() public
Mark Wielaard wrote: : This seems to introduce a new public API in the java.net package. I was wondering how that works for someone that wants to introduce such things in openjdk. There is still some infrastructure and process that isn't externalized yet. The change approval process for API additions and behavior changes is one of them. In the interim, this means finding a buddy or sponsor to work with when proposing updates to APIs. I'm happy to act as a proxy in the interim and I'm sure others are too. I do see the bug report that mentions making this public should be done for JDK7. But there seems to missing a real justification for adding these new interfaces. Is there any policy for introducing such new public interfaces? I might be reading this wrongly but it seems the only thing this API does is expose some random internal "index" numbers for an NetworkInterface. Seeing that there are no guarantees on whether there are index numbers in the first place for any or all interfaces it seems not that useful imho. An example of how an application would use this new interface would be nice to get a better idea in what situations this would be used. Jessie is the best person to answer this but if my memory is correct, exposing the index was first discussed back in 1.4 as part of the API changes required to support IPv6. The index is mostly used to identify the interface when doing IPv6 multicasting and the getByIndex/getIndex methods were to be the approximate equivalent of RFC 2133's if_nametoindex and if_indextoname. In jdk5 the IPv6 support was updated to support IPv6 scoped addresses. This is important to disambiguate the destination when there are multiple interfaces and hosts with non-global addresses. Typically the scope identifier is the interface index so it has been exposed since jdk5. Jessie's updates, while niche, go further to completing this API. -Alan.
Re: hg: jdk7/jsn/jdk: 6717876: Make java.net.NetworkInterface.getIndex() public
Andrew John Hughes wrote: : More generally, it's not clear where the decision was made to make this part of the (as yet non-existent) JDK7 platform JSR. Will there be more insight into this process from outside Sun in the near future? The change approval process for API additions and changes isn't externalized yet. I've cc'ed Mark Reinhold in case he can say any more about this. In JCP terms it's the "Maintenance Review" that captures the many additions, changes and corrections to the Java SE specification that aren't covered by their own JSRs. There may not be a JSR for Java SE 7 yet but I assume that down the road there will be a Maintenance Review for Java SE 7 detailing all the API changes. -Alan.
Re: hg: jdk7/jsn/jdk: 6717876: Make java.net.NetworkInterface.getIndex() public
On Thu, 2008-08-28 at 12:16 +0100, Alan Bateman wrote: > Mark Wielaard wrote: > > : > > This seems to introduce a new public API in the java.net package. > > I was wondering how that works for someone that wants to introduce > > such things in openjdk. > There is still some infrastructure and process that isn't externalized > yet. The change approval process for API additions and behavior changes > is one of them. In the interim, this means finding a buddy or sponsor to > work with when proposing updates to APIs. I'm happy to act as a proxy in > the interim and I'm sure others are too. Thanks. On irc I was pointed to "CCC" review board which currently is "under construction": http://openjdk.java.net/guide/reviewBodies.html and not planned to be made public till 2008/Q2. Would it be possible to publish a summary whenever such a CCC has occurred to the announce/discuss list till then? Just something simple like "The CCC received a request from X for public interface change Y with as justification Z. The CCC process ended in an Approval/Disapproval for the following reason...". Then at least these kind of changes don't just have a commit without any public discussion. > > I might be reading this wrongly but it seems the only thing this API > > does is expose some random internal "index" numbers for an > > NetworkInterface. Seeing that there are no guarantees on whether there > > are index numbers in the first place for any or all interfaces it seems > > not that useful imho. An example of how an application would use this > > new interface would be nice to get a better idea in what situations > > this would be used. > > > Jessie is the best person to answer this but if my memory is correct, > exposing the index was first discussed back in 1.4 as part of the API > changes required to support IPv6. The index is mostly used to identify > the interface when doing IPv6 multicasting and the getByIndex/getIndex > methods were to be the approximate equivalent of RFC 2133's > if_nametoindex and if_indextoname. In jdk5 the IPv6 support was updated > to support IPv6 scoped addresses. This is important to disambiguate the > destination when there are multiple interfaces and hosts with non-global > addresses. Typically the scope identifier is the interface index so it > has been exposed since jdk5. Jessie's updates, while niche, go further > to completing this API. Aha. OK. I might be dense, but I don't think I am the only person not immediately making the link between these methods and the RFC 2133 "Interface Identification" and how they are used as described in RFC 2292 for selecting the outgoing interface. So a pointer to this in the documentation might be helpful. Also an small code example how to actually use these interface identifiers would help make the interface more clear. So I assume the Index returned can be used as an Scope identifier when creating a Inet6Address. In that case it would be good to mention that in the documentation also. And maybe even change the method name (if not too late) to getScopeIndex() or something a bit more descriptive. Cheers, Mark
Re: hg: jdk7/jsn/jdk: 6717876: Make java.net.NetworkInterface.getIndex() public
Mark Wielaard wrote: : Thanks. On irc I was pointed to "CCC" review board which currently is "under construction": http://openjdk.java.net/guide/reviewBodies.html and not planned to be made public till 2008/Q2. Would it be possible to publish a summary whenever such a CCC has occurred to the announce/discuss list till then? Just something simple like "The CCC received a request from X for public interface change Y with as justification Z. The CCC process ended in an Approval/Disapproval for the following reason...". Then at least these kind of changes don't just have a commit without any public discussion. This seems a reasonable suggestion to me. I don't know the priority of this compared to other infrastructure work but sending notifications to a public mailing list might be a good start. : Aha. OK. I might be dense, but I don't think I am the only person not immediately making the link between these methods and the RFC 2133 "Interface Identification" and how they are used as described in RFC 2292 for selecting the outgoing interface. So a pointer to this in the documentation might be helpful. Also an small code example how to actually use these interface identifiers would help make the interface more clear. So I assume the Index returned can be used as an Scope identifier when creating a Inet6Address. In that case it would be good to mention that in the documentation also. And maybe even change the method name (if not too late) to getScopeIndex() or something a bit more descriptive. I agree that the new methods and the section in Inet6Address that defines scoped addresses should reference each other. This is something I suggested to Jessie a few months ago but it didn't make it into these changes. I'm not sure about the suggested method name though. The zone index, or scope id as it is known in the Inet6Address spec, might be something that isn't an interface index. This means the integer that identifies the interface might not always correspond to the zone index (Michael, Jessie, correct me if I've got this wrong). -Alan.
