Re: Reminder about reported problem in NetworkInterface.c
On 12.05.2016 13:18, Ivan St. Ivanov wrote: Hello Alan, If that is the showstopper for moving this change forward, Quoting from the very first step of the OpenJDK contribution guide at http://openjdk.java.net/contribute/ "If you haven't yet signed the Oracle Contributor Agreement (OCA) then please do so, scan it and e-mail the result to oracle-ca_us(at)oracle.com." Doychin is part of the Bulgarian JUG. Which has signed the OCA. That's not correct. The Bulgarian JUG does not have an OCA on file, as you can see at http://www.oracle.com/technetwork/community/oca-486395.html#b . You may be confusing the OCA with something else. At this time, there are no JUGs with an OCA. cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: JEP 321: HTTP Client (Standard)
On 04.12.2017 22:56, David Lloyd wrote: saying "Here it is, it's all done, what do you think?". I've certainly never had opportunity to try it out: given its status as an incubating module present only in OpenJDK, the only people who are really in a position to try it out are those using OpenJDK (as opposed to other JDKs) That's not quite correct. The jdk.incubator.httpclient module is part of Oracle JDK 9, as well. It has been part of the JDK 9 Early Access builds since about a year ago, afaik. The Early Access builds can be found at jdk.java.net, fwiw. But those who are best able to make this kind of determination are those who need to be able to immediately use the API, and rely upon it indefinitely (for good or bad), which is definitely not the case for anything incubated in the OpenJDK project. This seems to be a more general criticism of the incubator module mechanism as defined in JEP 11, rather than directed at this API specifically. It wasn't raised on jdk-dev when JEP 11 was discussed about a year ago, fwiw. I would take issue with the qualifier 'best' in the above, as the qualification offered for making best determinations is necessity, rather than expertise, for example. In some cases, both properties may hold, of course, but I don't think that's a valid assertion in general. cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: JEP 321: HTTP Client (Standard)
On 05.12.2017 14:48, David Lloyd wrote: On Tue, Dec 5, 2017 at 5:48 AM, dalibor topic wrote: On 04.12.2017 22:56, David Lloyd wrote: saying "Here it is, it's all done, what do you think?". I've certainly never had opportunity to try it out: given its status as an incubating module present only in OpenJDK, the only people who are really in a position to try it out are those using OpenJDK (as opposed to other JDKs) That's not quite correct. The jdk.incubator.httpclient module is part of Oracle JDK 9, as well. It has been part of the JDK 9 Early Access builds since about a year ago, afaik. The Early Access builds can be found at jdk.java.net, fwiw. Sure, but that's all the same ecosystem. An organization tied to, say, the IBM JDK won't have access to these. Fwiw, IBM's OpenJ9 builds for JDK 9 would seem to include this incubator module as well. I'd naively assume the same to be the case for Azul's JDK 9 builds, etc. This seems to be a more general criticism of the incubator module mechanism as defined in JEP 11, rather than directed at this API specifically. It wasn't raised on jdk-dev when JEP 11 was discussed about a year ago, fwiw. Of course; sometimes a thing must be tried before the weaknesses are apparent. If we all designed perfect things from the start, we wouldn't need standards and evolution. :) Touché - The sample size of one for modules going through the incubation module mechanism may still be too small for a categorical critique, though. ;) cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Re: RFR: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use an IPPROTO_ICMP socket type before attempting RAW_SOCK
On Sun, 29 Nov 2020 07:54:23 GMT, Jamie Le Tual wrote: > Users have been able to send ICMP packets without the need for root > privileges or the CAP_NET_RAW capability since at least kernel 3.11. > > For some time now, if the kernel parameter net.ipv4.ping_group_range included > the gid of a user sending an icmp packet with the IPPROTO_ICMP protocol, then > the packet would> > It's important to note that the both the checksum and ident field are > overwritten by the kernel when this is done. > > Newer distributions are now setting the default value of > net.ipv4.ping_group_range to be open to all possible group ids (Fedora 31 and > Ubuntu 20.04 for example) so it can b> > > Also of note is the that this is also implemented in MacOS. > > This patch proposes attempting to use IPPROTO_ICMP first, and then fall back > to attempting a raw socket and ultimately failing over to tcp echo. > This patch also alters the logic for identifying icmp reply packets, since > the kernel overwrites id ident field when using the IPPROTO_ICMP protocol. > The method is similar to that used by the ping(8) utility in the iputils > package, where we compare data in the icmp_data member of the icmp struct > to identify the packet as our response. The ping utility compares the > timeval, whereas this patch proposes to compare both the timeval and the > user's pid. > > Please not that my OCA has been sent in and is pending. Thank you for sending in an OCA for processing, Jamie, your account has now been verified. - PR: https://git.openjdk.java.net/jdk/pull/1502
Re: Request for comments: Bug 6306820
Richard Kennard <[EMAIL PROTECTED]> writes: > > Dear All, > > Please find the latest version of URLEncodedQueryString at... > > > https://jdk-collaboration.dev.java.net/ [snip] > Thanks again for all your help, and I look forward to hearing from you, Hi Richard, a small meta-comment: URLs to the jdk-collaboration site will only be visible to members of that project, i.e. not to all OpenJDK developers. cheers, dalibor topic
Re: Request for comments: Bug 6306820
Richard Kennard <[EMAIL PROTECTED]> writes: > > Dalibor, > > Fair point. I am only following the original advice of the Peabody > initiative to use http://jdk-collaboration, and the more recent advice > of the OpenJDK project to use the net-dev mailing list. > > If there is a new preference I am happy to switch to that? No need to switch, if that works for you. But for the benefit of others who would be interested in following the discussion along with the code, I'd suggest posting the patches as unified diffs attached to your RFCs. cheers, dalibor topic
