Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

On Tue, 14 Sep 2021 12:36:28 GMT, Jim Laskey 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

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

On Wed, 18 Nov 2020 00:30:53 GMT, Paul Sandoz wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge branch 'master' into 8248862 >> - 8248862: Implement

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

On Wed, 18 Nov 2020 00:29:36 GMT, Paul Sandoz wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge branch 'master' into 8248862 >> - 8248862: Implement

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

On Mon, 23 Nov 2020 14:57:59 GMT, Jim Laskey wrote: >> src/java.base/share/classes/module-info.java line 250: >> >>> 248: exports jdk.internal.util.xml.impl to >>> 249: jdk.jfr; >>> 250: exports jdk.internal.util.random; >> >>

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

On Tue, 17 Nov 2020 23:46:12 GMT, Paul Sandoz wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge branch 'master' into 8248862 >> - 8248862: Implement

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

On Tue, 17 Nov 2020 21:22:28 GMT, Paul Sandoz wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge branch 'master' into 8248862 >> - 8248862: Implement

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

rface and several optional > methods like we have with the collections, it means that we are loosing the > possibilities to precisely type a method that only works with a precise type > of generator but it will be more future proof. > > Rémi > > - Mail orig

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

On Wed, 18 Nov 2020 13:18:30 GMT, Jim Laskey wrote: >> I am unsure if the intent is also to support external libraries providing >> `RandomGenerator` implementations. Currently there is an implicit contract >> for properties (reflectively invoking a method returnin

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

On Wed, 18 Nov 2020 00:51:43 GMT, Paul Sandoz wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge branch 'master' into 8248862 >> - 8248862: Implement

Withdrawn: 8248862: Implement Enhanced Pseudo-Random Number Generators

On Tue, 17 Nov 2020 19:58:47 GMT, Jim Laskey wrote: > This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . This pull re

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

> This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . Jim Laskey has updated the pull request with a new target

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

On Tue, 17 Nov 2020 21:59:04 GMT, Jim Laskey wrote: >>> my local branch seems to have the right sources for doc >> >> Maybe, but your branch on GitHub does not. > > @kevinrushforth What is the recommended approach to remove the doc > edit/commit?

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth wrote: >> @erikj79 my local branch seems to have the right sources for doc > >> my local branch seems to have the right sources for doc > > Maybe, but your branch on GitHub does not. @kevinrushforth What is the recommended approach to remove

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v2]

> This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . Jim Laskey has updated the pull request incrementally with one a

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . > > It looks like

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . > > It looks like

RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . - Commit messages: - 8248862: Implement Enhanced Pseudo-Random

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

(meaning: lack of optimization > for macOS), please do create one so that it at least is documented somewhere. > > Thank you, > > -hendrik > >> On Jun 5, 2020, at 13:59, Jim Laskey > <mailto:james.las...@oracle.com>> wrote: >> >> I know there

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

I know there was a discussion about this elsewhere but I would like to take the opportunity to correct this now make//autoconf/flags-cflags.m4:241 elif test "x$TOOLCHAIN_TYPE" = xclang; then if test "x$OPENJDK_TARGET_OS" = xmacosx; then # On MacOSX we optimize for size, something

Re: RFR 8241749: Remove the Nashorn JavaScript Engine

+1 > On Apr 15, 2020, at 12:56 PM, sundararajan.athijegannat...@oracle.com wrote: > > Please review. > > Nashorn script engine modules (jdk.scripting.nashorn, > jdk.scripting.nashorn.shell) and jjs tool are removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241749 > > JEP:

Amber repo build issue on MacOSX

cp: /Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/link_opt/classlist: No such file or directory make[3]: *** [/Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/modules_libs/java.base/classlist] Error 1 make[3]: *** Waiting for unfinished jobs

Re: RFR: JDK-8191203 Remove duplicated jimage.hpp

The file was moved from hs to the jdk to simplify the API, not sure why it’s still there. A bulk merge issue maybe. I don’t recall clearly but I think the BSD license was a request from that other big company. Cheers, — Jim > On Nov 21, 2017, at 10:00 AM, Magnus Ihse Bursie >

Re: How to get full path linkage for the jvm shared library

t.com> wrote: > > On 02/03/17 12:53, Jim Laskey (Oracle) wrote: >> Seems that -Wl,-rpath, does what I need. > > -rpath is very dangerous. -rpath-link is much better. > > Andrew. >

Re: How to get full path linkage for the jvm shared library

Seems that -Wl,-rpath, does what I need. > On Mar 1, 2017, at 5:58 PM, Jim Laskey (Oracle) <james.las...@oracle.com> > wrote: > > I have a service library that creates an instance of the jvm (on OEL linux.) > I have no control of where the library is used o

Re: JDK 8 cannot be built on Sierra, correct?

> David DeHaven suggests creating a VM to build in. > > http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018518.html > > /Erik > > On 2017-02-01 20:00, Jim Laskey (Oracle) wrote: >> I haven’t tried in a while, but I ran up against it today. >> &

JDK 8 cannot be built on Sierra, correct?

I haven’t tried in a while, but I ran up against it today. Neither the xcode-select (xcode4) or configure --with-xcode-path work. dyld: Library not loaded: @rpath/DVTFoundation.framework/Versions/A/DVTFoundation Referenced from:

Re: RFR 8171316: Add IMPLEMENTOR property to the release file

+1 > On Dec 15, 2016, at 11:32 AM, Sundararajan Athijegannathan > wrote: > > Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8171316 > > top level webrev: http://cr.openjdk.java.net/~sundar/8171316/top/webrev.00/ > jdk webrev:

Re: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory

+1 > On Nov 22, 2016, at 5:07 PM, Mandy Chung wrote: > > This patch moves src.zip and jrt-fs.jar from the top-level into > the `lib` directory in the run-time image as we proposed [1]. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ >

random jdk9-dev build error

After a clean got dtrace: failed to compile script /Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot_jni.h.d: line 1: empty D program translation unit second time worked fine.

Re: RFR 8156847: jdk.dynalink package is shown under "Other Packages" section

+1 > On May 16, 2016, at 12:08 PM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8156847/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8156847 > > Thanks, > > -Sundar >

Re: RFR: 8156756: Enable build-time use of resource ordering plugin

+1 > On May 11, 2016, at 12:56 PM, Claes Redestad > wrote: > > Hi, > > please review this change to enable the --order-resources plugin during > build, which helps cold start scenarios by improving locality > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156756

Re: Having problem building jdk9-dev

Boot JDK - got to stop installing EA > On May 9, 2016, at 11:11 AM, Jim Laskey (Oracle) <james.las...@oracle.com> > wrote: > > Forwarding from jdk9-dev. > >> Begin forwarded message: >> >> From: "Jim Laskey (Oracle)" <james.las...@oracle.

Fwd: Having problem building jdk9-dev

Forwarding from jdk9-dev. > Begin forwarded message: > > From: "Jim Laskey (Oracle)" <james.las...@oracle.com> > Subject: Re: Having problem building jdk9-dev > Date: May 9, 2016 at 11:07:15 AM ADT > To: jdk9-dev <jdk9-...@openjdk.java.net>, jigsaw-dev

Re: RFR: 8150044: Generate classlists at build-time

and straightforward too. > > /Erik > > [1] http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz > > On 2016-05-04 16:13, Jim Laskey (Oracle) wrote: >> Correct. How do I set up autogen so I can apply these changes? >> >> >>> On May 4, 2016, at 11:11

Re: RFR: 8150044: Generate classlists at build-time

Correct. How do I set up autogen so I can apply these changes? > On May 4, 2016, at 11:11 AM, Erik Joelsson wrote: > > Build changes look ok to me, but I also helped write most of them. > > This certainly adds some build complexity and might seem overly so for just

Re: Build craziness

I didn’t at the time. Thank you. > On Apr 25, 2016, at 8:51 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > Then I suspect it's this bug https://bugs.openjdk.java.net/browse/JDK-8154326 > > Do you have the fix for that in your forest? > > /Erik > >

Re: Build craziness

A re-run worked fine (but note that the first time was after a clean.) — Jim > On Apr 25, 2016, at 8:19 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > Does it happen repeatedly? > > /Erik > > On 2016-04-25 12:31, Jim Laskey (Oracle) wrote: >

Re: Build craziness

> On 2016-04-22 18:10, Jim Laskey (Oracle) wrote: >> >>> Begin forwarded message: >>> >>> From: "Jim Laskey (Oracle)" <james.las...@oracle.com> >>> Subject: Build craziness >>> Date: April 22, 2016 at 11:59:35 AM ADT >>&g

Fwd: Build craziness

> Begin forwarded message: > > From: "Jim Laskey (Oracle)" <james.las...@oracle.com> > Subject: Build craziness > Date: April 22, 2016 at 11:59:35 AM ADT > To: jigsaw-dev <jigsaw-...@openjdk.java.net> > > make clean ; make images > > Buildin

Re: CLANG special case

browse/JDK-8138820> >> So far as I know this is not tracked under any other bug id. >> >> -phil. >> >> On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote: >>> I’ve updated to El Capitan and, of course, builds fail, and, of course, I >>> m

CLANG special case

I’ve updated to El Capitan and, of course, builds fail, and, of course, I modify hotspot/make/bsd/makefiles/gcc.make one more time and… I think this conditional clause should be removed at the very least (commenting to indicate needs investigation), or someone should research and see which

Re: RFR 8133347: Add makefiles support and basic session, persistence history navigation with jline

+1 On Aug 12, 2015, at 2:03 PM, Sundararajan Athijegannathan sundararajan.athijegannat...@oracle.com wrote: Hi, Please review changes for the bug: https://bugs.openjdk.java.net/browse/JDK-8133347 This is a subtask of jjs should use jline

Jake, hashes and aliases

java.lang.module.ResolveException: Hash of java.security.jgss (IPAH/Z1wbzCE8aG78apqik6QR94TaBJqcatAkW+35rs=) differs to expected hash (O61Gv4243oRyV7LoD/FjaNBXgRtREFjG4p1Q//V8cGI=) at java.lang.module.Resolver.fail(java.base@9.0/Resolver.java:416) at

Re: Jake, hashes and aliases

I was wrong - that didn’t resolve my issue. On Apr 17, 2015, at 5:07 PM, Jim Laskey (Oracle) james.las...@oracle.com wrote: java.lang.module.ResolveException: Hash of java.security.jgss (IPAH/Z1wbzCE8aG78apqik6QR94TaBJqcatAkW+35rs=) differs to expected hash (O61Gv4243oRyV7LoD

clang 6.1 inteference

Run into an issue after upgrade to clang 6.1 /Volumes/Elephant/Projects/sandbox/hotspot/src/share/vm/opto/chaitin.cpp:2098:8: error: 'this' pointer cannot be null in well-defined C++ code; pointer may be assumed to always convert to true [-Werror,-Wundefined-bool-conversion] if( !this ) {

Re: RFR 8068650: https://bugs.openjdk.java.net/browse/JDK-8068650

+1 On Jan 8, 2015, at 2:52 AM, A. Sundararajan sundararajan.athijegannat...@oracle.com wrote: Hi, Please review http://cr.openjdk.java.net/~sundar/8068650/ for https://bugs.openjdk.java.net/browse/JDK-8068650 This issue was caused by another makefile fix to generate docs for nashorn.

Re: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs

+1 On Nov 28, 2014, at 6:41 AM, A. Sundararajan sundararajan.athijegannat...@oracle.com wrote: Hi, Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8066146 Thanks, -Sundar

-Wformat-nonliteral

/Projects/jdk9-dev/hotspot/src/share/vm/utilities/debug.cpp:105:19: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf(err, format, ap); ^~ Try to build jdk9-dev tip I ran into this. Wassup? -- Jim

Re: -Wformat-nonliteral

Yes On Mar 28, 2014, at 11:05 AM, Staffan Larsen staffan.lar...@oracle.com wrote: Building with clang? https://bugs.openjdk.java.net/browse/JDK-8037816 https://bugs.openjdk.java.net/browse/JDK-8019470 /Staffan On 28 mar 2014, at 14:28, Jim Laskey (Oracle) james.las...@oracle.com

sjavac

The Nashorn team is wondering about the status of sjavac and the builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 . There are two occurances of -cp which should be convered to -classpath in makefiles/BuildNashorn.gmk . Cheers, -- Jim

Re: 8008977: profiles build broken by Nashorn build changes

I have a change set making its way to tl that removes this requirement. -- Jim On 2013-03-04, at 11:54 AM, Kelly O'Hair kelly.oh...@oracle.com wrote: It seems to me that using $ in class names when they are NOT Inner Classes is a huge mistake. Mark my words, this will come back to haunt

Re: 8008977: profiles build broken by Nashorn build changes

On 2013-03-04, at 11:58 AM, Jim Laskey (Oracle) james.las...@oracle.com wrote: I have a change set making its way to tl that removes this requirement. -- Jim On 2013-03-04, at 11:54 AM, Kelly O'Hair kelly.oh...@oracle.com wrote: It seems to me that using $ in class names when

Re: Dollar ($) expansion still needs attention

I wanted to double check and trace the origins of the MakeBase.gmk patch before I responded. It was part of the original set Erik sent me, but looking thru the other parts of the patch it's not clear why it was necessary. http://cr.openjdk.java.net/~erikj/nashorn-build/webrev.01/ -- Jim