On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> It's the last issue in the series, and it still touches different areas of
> the code.
Logging/JNDI OK
-
Marked as
On Fri, 13 May 2022 14:36:02 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix the failure
>> handler command `dmesg` on macOS?
>>
>> As noted in the JBS issue, the command currently fails with permission
>> error. The commit in this PR uses `sudo` as
On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285915?
>
> With this change, the environment details collected by the failure handler
> will now include the contents of the
On Wed, 20 Apr 2022 14:30:21 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 (NIO
On Tue, 19 Apr 2022 15:54:02 GMT, Michael McMahon wrote:
>> test/jdk/jdk/net/ExtendedSocketOption/DontFragmentTest.java line 44:
>>
>>> 42: StandardProtocolFamily fam = args[0].equals("ipv4") ? INET :
>>> INET6;
>>> 43: System.out.println("Family = " + fam);
>>> 44:
On Tue, 19 Apr 2022 14:47:01 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 (NIO
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 (NIO DatagramChannels). For
On Mon, 29 Nov 2021 13:57:13 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 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 Fri, 26 Nov 2021 14:31:04 GMT, Julia Boes wrote:
>> make/jdk/src/classes/build/tools/taglet/ToolGuide.java line 159:
>>
>>> 157: .toString()
>>> 158: .replace('.', '/')
>>> 159: .replaceAll("[^/]+", "..");
>>
>> If the
On Thu, 25 Nov 2021 15:58:58 GMT, Julia Boes wrote:
> This change adds support for the `@toolGuide` tag in class-level API
> documentation.
>
> (A use case is the jwebserver tool, where the
> com.sun.net.httpserver.SimpleFileServer class provides API points for
> extension and customization
On Wed, 24 Nov 2021 17:15:35 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 Mon, 22 Nov 2021 09:43:19 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.
src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/resources/simpleserver.properties
On Mon, 22 Nov 2021 09:43:19 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.
src/jdk.httpserver/share/classes/com/sun/net/httpserver/SimpleFileServer.java
line 110:
> 108: *
On Wed, 29 Sep 2021 11:02:05 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, 28 Sep 2021 10:08:29 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, 22 Sep 2021 15:26:33 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 16:03:28 GMT, Hannes Wallnöfer wrote:
>> Hmm... When printing messages on the console don't we want a localized date?
>> Or are you referring to other usages of the date formatter? Worth double
>> checking in any case.
>
> The problem I was referring to was not about
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 15:06:09 GMT, Hannes Wallnöfer wrote:
>> test/jdk/com/sun/net/httpserver/simpleserver/SecurityManagerTest.java line
>> 198:
>>
>>> 196:
>>> 197: static final DateTimeFormatter HTTP_DATE_FORMATTER =
>>> 198: DateTimeFormatter.ofPattern("EEE, dd MMM
On Mon, 20 Sep 2021 16:09:14 GMT, Daniel Fuchs wrote:
>> Julia Boes has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 12 commits:
>>
>> - Merge branch 'master' into simpleserver
>> - check isHidden,
On Mon, 20 Sep 2021 15:28:05 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, 14 Sep 2021 16:47:45 GMT, Daniel Fuchs 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 i
On Tue, 14 Sep 2021 08:52:37 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 method
On Tue, 14 Sep 2021 12:38:19 GMT, Jim Laskey wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> line 128:
>>
>>> 126: * {@code headers} are the effective headers of the response.
>>> The
>>> 127: * response body bytes are a {@code UTF-8} encoded
On Tue, 14 Sep 2021 16:07:21 GMT, Julia Boes wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line
>> 288:
>>
>>> 286: }
>>> 287:
>>> 288: private static final Headers EMPTY = new UnmodifiableHeaders(new
>>> Headers());
>>
>> IDEA warns here:
On Tue, 14 Sep 2021 13:19:17 GMT, Andrey Turbanov
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
On Tue, 31 Aug 2021 01:05:05 GMT, Ioi Lam wrote:
>> When the classlist is generated using build.tools.classlist.HelloClasslist,
>> its contents may be non-deterministic due to Java thread execution order.
>>
>> We should sort the generated classlist to make the JDK image's contents more
>>
On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote:
> When the classlist is generated using build.tools.classlist.HelloClasslist,
> its contents may be non-deterministic due to Java thread execution order.
>
> We should sort the generated classlist to make the JDK image's contents more
>
On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote:
>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>>
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>>
>> This could be done more efficiently(up
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Wed, 28 Oct 2020 08:54:31 GMT, Peter Levart wrote:
>> Some thoughts regarding the parameter type of refersTo. Summary: I think
>> `refersTo(T)` is fine and that we don't want to change it to
>> `refersTo(Object)`.
>>
>> I don't think we have a migration issue similar to generifying
[resending with correct subject]
Hi,
https://bugs.openjdk.java.net/browse/JDK-8205945
8205945: Revert unintended changes to
make/gensrc/Gensrc-jdk.hotspot.agent.gmk
My fix for 8205397 [1] includes a change to
make/gensrc/Gensrc-jdk.hotspot.agent.gmk that was not intended:
diff --git
Hi,
My fix for 8205397 [1] includes a change to
make/gensrc/Gensrc-jdk.hotspot.agent.gmk that was not intended:
diff --git a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
b/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
--- a/make/gensrc/Gensrc-jdk.hotspot.agent.gmk
+++
Hi Erik,
The modifications to the logging test look good to me.
Caveat: I don't speak chinese nor japanese ;-)
cheers,
-- daniel
On 13/06/18 20:47, Erik Joelsson wrote:
Hello,
Oracle will reduce the number of languages that it maintains
translations of JDK resources for. The current
Thanks for that Erik!
It's been annoying me for a couple of days :-)
I have imported your patch locally in my repo and it seems to
be working fine.
Hopefully someone from the build team will give you a thumbs up!
best regards,
-- daniel
On 14/11/2017 22:35, Erik Joelsson wrote:
When I
+1
libmanagement_agent is indeed a better name :-)
best regards,
-- daniel
On 02/02/17 22:27, Mandy Chung wrote:
libmanagement_agent should be the proper library name for jdk.management.agent.
It was an oversight with the current name.
Hi,
A direct consequence of this change is that you may have
to either blow up your ./build directory, or run
'make clean-java' after pulling this fix.
Otherwise you may see strange build failures like below:
Error occurred during initialization of VM
java.lang.RuntimeException: Package
Hi Mandy,
On 02/02/17 02:41, Mandy Chung wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06
Does java.management still depend on java.base/jdk.internal.module?
Well spotted! It doesn't. I have updated module-info.java for java.base.
Hi,
Please find below a patch for:
8173607: JMX RMI connector should be in its own module
https://bugs.openjdk.java.net/browse/JDK-8173607
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05
This patch makes it possible to remove the requires transitive
java.rmi from the
Hi Mandy,
Looks good to me in general.
Suggestion: FileLoginModule.java
112 private static final String PASSWORD_FILE_NAME =
"jmxremote.password";
Maybe the constant could be public, then it could be
referred to by ConnectorBootstrap?
I see that com.sun.jmx.remote.internal is already
/index.action
cheers,
-- daniel
Pete
On 6/20/16 4:30 AM, Daniel Fuchs wrote:
Hi Pete,
I had the same problem recently - and solved it by installing
Xcode 6.3 - which I was told is the officially supported version.
best regards,
-- daniel
On 18/06/16 01:20, Pete Brunet wrote:
I haven't done a full
Hi Pete,
I had the same problem recently - and solved it by installing
Xcode 6.3 - which I was told is the officially supported version.
best regards,
-- daniel
On 18/06/16 01:20, Pete Brunet wrote:
I haven't done a full build in around a month, but just pulled (tpull
-u) / cleaned /
On 17/02/15 16:38, Erik Joelsson wrote:
Right, thanks for catching that. The OS specific file is not there for
every OS. This patch should fix it. I'm testing all platforms now.
Webrev: http://cr.openjdk.java.net/~erikj/8073328/webrev.jdk.03/
Thanks Erik.
This one appears to work like a
Hi Erik,
I tried to import your patch, and now the build fails with the
following error:
make[3]: *** No rule to make target
`/Users/danielfuchs/workspaces/jdk/jdk9-dev-java-time/jdk/make/data/charsetmapping/stdcs-macosx',
needed by
On 24/11/14 11:44, Erik Joelsson wrote:
Hello Daniel,
Test seems like a great idea. Thanks!
OK - I have logged JDK-8065748
https://bugs.openjdk.java.net/browse/JDK-8065748
I'll send a patch for review when your fix is in :-)
Thanks!
-- daniel
/Erik
On 2014-11-20 18:25, Daniel Fuchs
Hi Chris,
I had a look at the changes in java.logging and java.management modules
(+ corresponding tests) and they look reasonable to me.
I also had a cursory look at the jdeps changes. It's difficult for me
to review that without importing the changes and playing with the
tool as this is a
Chung wrote:
On 11/19/2014 12:50 PM, Daniel Fuchs wrote:
On 11/19/14 9:36 PM, Mandy Chung wrote:
resources.jar will be gone when we move to the modular runtime
image
(JEP 220 [1]).
JDK-8065138 and JDK-8065365 will become non-issue in JDK 9.
Do you mean that the property files will no longer
not forget this target
I filed a separate issue [1] for investigating the use of pipefail.
/Erik
[1] https://bugs.openjdk.java.net/browse/JDK-8065576
On 2014-11-20 10:34, Daniel Fuchs wrote:
On 11/20/14 10:26 AM, Erik Joelsson wrote:
Hello,
On 2014-11-20 02:20, Martin Buchholz wrote:
Amusingly
On 15/10/14 17:19, shanliang wrote:
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/
The new version looks fine :-)
-- daniel
I add:
./01/jdk9-make/
for updating ./make/CompileJavaModules.gmk
./01/jdk9-jdk-src/ is same to ./00
Thanks,
Shanliang
Erik
alan.bate...@oracle.com wrote:
On 14/10/2014 14:34, Daniel Fuchs wrote:
Hi Pavel,
I saw your mail on build-dev.
I guess the issue will resolve itself once we have the
modular image.
I wonder whether the way to go for now would be
to add a single META-INF/services file - as you suggest
Hi Mandy,
I'm seeing some small differences in the various VirtualMachineImpl.java
files, but if I'm not mistaken, all the new AttachProviderImpl.java look
all the same. I wonder if the patch could be further simplified by
moving AttachProviderImpl.java to jdk.attach/share/classes (unless
, Aix and Solaris versions could probably be unified.
Ah - right - I missed those. Forget my comment then!
Thanks Staffan!
-- daniel
/Staffan
On 26 aug 2014, at 12:40, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi Mandy,
I'm seeing some small differences in the various
Hi Mike,
sorry for not reacting sooner.
I applied your patch on my machine, and now get the following:
sh ./get_source.sh
./get_source.sh: line 70: [: too many arguments
./get_source.sh: line 76: [: `)' expected, found -1
./get_source.sh: line 82: [: `)' expected, found -1
I have added:
echo
is neither an empty string nor 0.
1 the expression is an empty string or 0.
2 the expression is invalid.
[ ... ]
-- daniel
On 7/8/14 12:30 PM, Daniel Fuchs wrote:
Hi Mike,
sorry for not reacting sooner.
I applied your patch on my machine, and now get the following:
sh
Hi,
Thanks Dave,
yes - your patch works like a charm :-)
best regards,
-- daniel
Note: the following also works on my machine:
--
check() {
read var
if expr 1 + $var /dev/null ; then
echo $var
else
return 2
fi
}
Hi Mike,
This one works perfectly on my machine :-)
Thumbs up!
-- daniel
On 7/8/14 7:40 PM, Mike Duigou wrote:
I've updated the webrev with yet a different variant of the extract version
field function.
http://cr.openjdk.java.net/~mduigou/JDK-8048184/1/webrev/
Sorry Dave, I resist all
On 12/10/13 12:06 PM, Alan Bateman wrote:
(This one is for the jdk9-dev forest once it is created)
The addPropertyChangeListener and removePropertyChangeListener methods
defined by Pack200.{Packer,Unpacker} and LogManager methods are
deprecated and flagged with a warning that they will be
On 10/4/13 7:05 PM, Francis ANDRE wrote:
Hi
This page http://openjdk.java.net/guide/codeReview.html states that one
should use webrev for providing support of Community Code Review but it
also states that any user with push access to the OpenJDK Mercurial
http://hg.openjdk.java.net server can
On 6/18/13 8:28 AM, David Holmes wrote:
On 18/06/2013 4:02 PM, Jonathan Gibbons wrote:
The only problem with using N is that you don't know whether you have
broken building with N-1. Therefore the general recommendation for most
people should be to always use N-1. I think Stuart is just
Hi,
After cloning jdk8/tl you need to cd to the new clone and run:
$ sh ./get_sources.sh
to get the whole forest. Then you need to run configure
(sh ./configure) and then only can you call make images.
Hope this helps,
(and BTW you may need to install Xcode its command line tools
as well
On 4/16/13 5:02 PM, Jim Gish wrote:
I've updated the version to 24.0 and add Mike as a reviewer. Could
someone please push this for me?
Hi Jim,
Done.
Thanks for the fix!
-- daniel
Thanks,
Jim
On 04/15/2013 06:34 PM, Mike Duigou wrote:
I think the version number needs to be
On 4/16/13 5:02 PM, Jim Gish wrote:
I've updated the version to 24.0 and add Mike as a reviewer. Could
someone please push this for me?
Hi Jim,
I think you will need to update the bug id in your comment:
http://cr.openjdk.java.net/~jgish/Bug8011347-webrev/tl.changeset
8009824: JDK-8009824
in the editor.
I have also restrained the packageset for the javadoc
target as suggested by Joe.
-- daniel
On 3/25/13 12:45 PM, Daniel Fuchs wrote:
Hi guys,
I'd like to propose a small change to jaxp/build.xml and
jaxp/nbproject/project.xml - in order to allow editing
JAXP sources in NetBeans, as well
Hi guys,
I'd like to propose a small change to jaxp/build.xml and
jaxp/nbproject/project.xml - in order to allow editing
JAXP sources in NetBeans, as well as generating the JAXP
javadoc for previewing purposes.
I actually stole the javadoc target from
jdk/make/netbeans/common/shared.xml
The
Hi Peter,
Did you 'install the command line tools' in Xcode?
The fact that you have to refer to /Applications/Xcode.app/... let me
think that
perhaps you didn't.
Start Xcode, go to preferences, and explore the different panes: there's
one that
will let you install the command line tools.
I Tamer,
I believe you need to define this variable:
bootstrap.jdk=path to an existing jdk 6 or 7
in $HOME/.openjdk/build.properties.
see make/netbeans/README
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d782143219d6/make/netbeans/README
Best regards,
-- daniel
http://blogs.sun.com/jmxetc
Hi Ted,
To complete Erick's answer I believe you will find some in-depth
explanation on Kelly's blog - and more particularly in these two
articles:
OpenJDK Mercurial Forest
http://blogs.sun.com/kto/entry/openjdk_mercurial_forest
and OpenJDK Mercurial Wheel (Integration Wheel of Open Life)
68 matches
Mail list logo
