On Thu, 14 Apr 2022 16:04:22 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following PR review please? It adds a new JDK specific
> extended socket option
> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4
> and IPv6
> UDP sockets
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additiona
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additiona
On Tue, 19 Apr 2022 16:07:29 GMT, Daniel Fuchs wrote:
>> I'm not sure there is value in testing all of these permutations.
>> Distinguishing DatagramChannel and DatagramSocket probably made sense, but
>> it's all the same implementation under the hood.
>
> 1. `DatagramChannel.open()` => opens
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additiona
On Tue, 19 Apr 2022 14:50:57 GMT, Daniel Fuchs wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix whitespace
>
> src/jdk.net/windows/native/libextnet/WindowsSocke
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one addition
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additional
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request with a new target base due to a
On Fri, 15 Apr 2022 10:04:48 GMT, Daniel Jeliński wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> builds in github action now
>
> src/jdk.net/windows/native/libextnet/WindowsSoc
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additional
On Fri, 15 Apr 2022 09:19:48 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Could I get the following PR review please? It adds a new JDK specific
>> extended socket option
>> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4
>> and IPv6
>> UDP sockets (NIO DatagramChannels).
Hi,
Could I get the following PR review please? It adds a new JDK specific extended
socket option
called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4 and
IPv6
UDP sockets (NIO DatagramChannels). For IPv4 in particular, it sets the DF
(Dont Fragment) bit
in the IP
On Wed, 24 Nov 2021 17:29:40 GMT, Julia Boes wrote:
>> This change introduces jwebserver, a dedicated JDK tool for the Simple Web
>> Server.
>>
>> A description is provided in a follow-up comment.
>
> Julia Boes has updated the pull request incrementally with one additional
> commit since
On Tue, 12 Oct 2021 10:40:15 GMT, Julia Boes wrote:
>> This change implements a simple web server that can be run on the
>> command-line with `java -m jdk.httpserver`.
>>
>> This is facilitated by adding an entry point for the `jdk.httpserver`
>> module, an implementation class whose main
On Tue, 12 Oct 2021 10:40:15 GMT, Julia Boes wrote:
>> This change implements a simple web server that can be run on the
>> command-line with `java -m jdk.httpserver`.
>>
>> This is facilitated by adding an entry point for the `jdk.httpserver`
>> module, an implementation class whose main
On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote:
>> This change implements a simple web server that can be run on the
>> command-line with `java -m jdk.httpserver`.
>>
>> This is facilitated by adding an entry point for the `jdk.httpserver`
>> module, an implementation class whose main
On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote:
>> This change implements a simple web server that can be run on the
>> command-line with `java -m jdk.httpserver`.
>>
>> This is facilitated by adding an entry point for the `jdk.httpserver`
>> module, an implementation class whose main
On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote:
>> This change implements a simple web server that can be run on the
>> command-line with `java -m jdk.httpserver`.
>>
>> This is facilitated by adding an entry point for the `jdk.httpserver`
>> module, an implementation class whose main
On Wed, 15 Sep 2021 08:42:40 GMT, Julia Boes wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java
>> line 152:
>>
>>> 150: return server;
>>> 151: }
>>> 152:
>>
>> Too bad we couldn't simplify the setting up a basic certificate for https.
>
> That
On Tue, 14 Sep 2021 16:51:40 GMT, Daniel Fuchs wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> line 129:
>>
>>> 127: * response body bytes are a {@code UTF-8} encoded byte
>>> sequence of
>>> 128: * {@code body}. The response {@linkplain
>>>
> Continuing this review as a PR on github with the comments below
> incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I me
> Continuing this review as a PR on github with the comments below
> incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I me
On Mon, 5 Oct 2020 12:58:52 GMT, Erik Joelsson wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> - simplified Copy.gmk to CAT source files directly
>> - renamed net.
> Continuing this review as a PR on github with the comments below
> incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I me
On Sun, 4 Oct 2020 08:27:39 GMT, Alan Bateman wrote:
>> Good points. I will update as suggested. Thanks.
>
> I would prefer if we didn't rename net.properties. Can we use the same
> approach as lib/security/default.policy where
> the share and platform specific are concatenated?
Okay, I have
On Fri, 2 Oct 2020 12:58:02 GMT, Erik Joelsson wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> unixdomainchannels: error in the last commit in
>> make/modules/java.base/Copy.
> Continuing this review as a PR on github with the comments below
> incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I me
> Continuing this review as a PR on github with the comments below
> incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I me
in a
subsequent step. This should be more robust.
* sed doesn't like newlines in replaced text in Mac. I've thus omitted
the newline from the SOURCE template - as that was mostly cosmetic.
Thanks for Michael McMahon to report (and figure out how to deal with)
these issues, and to Alan Bateman
Hi Chris
As regards the networking changes, they look fine to me.
As discussed off list, I think the link generated by the @Incubating
tag might possibly point to a new page in the docs bundle rather than
directly to the JEP 11 page. But, that can be the subject of another change.
Thanks,
That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?
Would it be feasible to remember which (if any) patches had been popped
first, and only push the same ones again?
Michael
On 11/04/14 15:58, Chris Hegarty wrote:
Anyone using MQ
On 11/04/14 16:19, Chris Hegarty wrote:
On 11/04/14 15:59, Michael McMahon wrote:
That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?
Would it be feasible to remember which (if any) patches had been popped
first, and only push
, at 02:02 , Michael McMahon
michael.x.mcma...@oracle.com wrote:
Just wondering is there a plan to deal with build warnings on Linux?
I was experimenting with macros that could be used to deal with the
-Wunused-parameter
warning, but there are over 3700 occurrences and frankly it's not a
very
Just wondering is there a plan to deal with build warnings on Linux?
I was experimenting with macros that could be used to deal with the
-Wunused-parameter
warning, but there are over 3700 occurrences and frankly it's not a very
useful
warning in the context of JNI formal function parameters
Can I get the following change for jdk 8 reviewed please?
It's a simple build change to enable compilation of the dummy
SCTP API layer on macosx, plus the dummy implementation
used on windows.
The existing jdk_sctp tests cover this.
http://cr.openjdk.java.net/~michaelm/7076487/webrev.1/
On 10/10/13 12:01, Alan Bateman wrote:
On 10/10/2013 11:10, Michael McMahon wrote:
Can I get the following change for jdk 8 reviewed please?
It's a simple build change to enable compilation of the dummy
SCTP API layer on macosx, plus the dummy implementation
used on windows.
The existing
On 16/07/13 14:42, Volker Simonis wrote:
On Tue, Jul 16, 2013 at 3:02 PM, Tim Bell tim.b...@oracle.com wrote:
Hi Michael:
Since my latest sync of jdk8/cpu (today) I can't run configure. I get the
following
error:
Looks like your merge touched some of the .m4 files
I ran configure with
--with-javafx-zip-dir=/java/re/javafx/jdk-cobundle/8, but I don't see
any Java FX artifacts in the resulting build.
What am I doing wrong?
Thanks!
Michael
or make installer
/Erik
On 2013-07-03 15:19, Michael McMahon wrote:
I ran configure with
--with-javafx-zip-dir=/java/re/javafx/jdk-cobundle/8, but I don't see
any Java FX artifacts in the resulting build.
What am I doing wrong?
Thanks!
Michael
Are you building on a remote filesystem like NFS? Those .DS_Store files
get created by the finder
and can cause problems on remote filesystems where they become visible
to other software.
There is a way to disable creation of .DS_Store on remote filesystems
documented at
On 27/03/12 16:04, Fredrik Öhrström wrote:
2012-03-27 16:39, Michael McMahon skrev:
A few more things I'd like to understand are:
1) In what circumstances exactly would the configure script have to
be re-run?
You run configure once to setup a particular build configuration.
After
On 23/03/12 19:11, Fredrik Öhrström wrote:
in increasing order of verbosity
make VERBOSE=
make VERBOSE=-d
make VERBOSE=-d -p
Thanks. It looks like the first of the three options above is most
similar to the verbosity
level of the old build. Is all of this documented anywhere?
I think at the
Can I get the following jdk8 change reviewed please?
It is a simple sanity check on Mac OS X to ensure that
LANG is set in the environment. Currently, the build fails
if it's not set, but the failure is quite obscure.
http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/
Thanks
Michael.
fine to me.
-kto
On Mar 15, 2012, at 9:18 AM, Michael McMahon wrote:
Can I get the following jdk8 change reviewed please?
It is a simple sanity check on Mac OS X to ensure that
LANG is set in the environment. Currently, the build fails
if it's not set, but the failure is quite obscure.
http
support UI. But I'd check the JCK guys on that
one,
don't take my word for it.
-phk.
On 2/14/2012 6:49 AM, Michael McMahon wrote:
On 14/02/12 13:47, Fredrik Öhrström wrote:
Is the use of HEADLESS in gcc.make (linux and bsd) an archaeological
remnant and should be removed? (No source in the hotspot
On 14/02/12 13:47, Fredrik Öhrström wrote:
Is the use of HEADLESS in gcc.make (linux and bsd) an archaeological
remnant and should be removed? (No source in the hotspot repo looks a
the HEADLESS define.)
Is there any reason to not build a headless version of awt? (ie modify
BUILD_HEADLESS to
to some
other name before doing the jdk build.
Thanks,
Michael
On 06/02/12 23:21, Scott Kovatch wrote:
On Feb 6, 2012, at 2:31 PM, Michael McMahon wrote:
There are a few problems with the Mac build at the moment.
1. If SKIP_BOOT_CYCLE=false then the build fails, due to two problems:-
1
There are a few problems with the Mac build at the moment.
1. If SKIP_BOOT_CYCLE=false then the build fails, due to two problems:-
1) top level Makefile doesn't know about Mac OS image directory
structure
2) it also fails due to problem 2. below
2. General bootstrapping problem. The
49 matches
Mail list logo
