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 is
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
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:
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:
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;
>>
>>
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:
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:
interface 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
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 returning a
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:
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
> 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 base
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?
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 the
> 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
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
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
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 Number
eaning: 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 was a d
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
+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: https://op
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
make[2]:
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
> wrote:
>
> O
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.
>
Seems that -Wl,-rpath, does what I need.
> On Mar 1, 2017, at 5:58 PM, Jim Laskey (Oracle)
> 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 or how the environment is
> configured, i
ting 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.
>>
>> Neither the xcode-sel
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:
/Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/De
+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: http://cr.openjdk.java.net/~sundar/8171316/jdk/webrev.
+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/
>
> thanks
> Mandy
> [1]
>
+1
> On Sep 7, 2016, at 9:10 AM, Sundararajan Athijegannathan
> wrote:
>
> Please review http://cr.openjdk.java.net/~sundar/8165595/webrev.01/ for
> https://bugs.openjdk.java.net/browse/JDK-8165595
>
> Thanks
>
> -Sundar
>
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.
+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
>
+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
> Webrev: http://cr.openjdk
Boot JDK - got to stop installing EA
> On May 9, 2016, at 11:11 AM, Jim Laskey (Oracle)
> wrote:
>
> Forwarding from jdk9-dev.
>
>> Begin forwarded message:
>>
>> From: "Jim Laskey (Oracle)" > <mailto:james.las...@oracle.com>>
>>
Forwarding from jdk9-dev.
> Begin forwarded message:
>
> From: "Jim Laskey (Oracle)"
> Subject: Re: Having problem building jdk9-dev
> Date: May 9, 2016 at 11:07:15 AM ADT
> To: jdk9-dev , jigsaw-dev
>
>
> Mac OS X - reproducible with a fresh repo.
>
gt; /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 AM, Erik Joelsson wrote:
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
> this optimization. As I
I didn’t at the time. Thank you.
> On Apr 25, 2016, at 8:51 AM, Erik Joelsson 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
>
> On 2016-04-25 13:24, Jim La
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 wrote:
>
> Does it happen repeatedly?
>
> /Erik
>
> On 2016-04-25 12:31, Jim Laskey (Oracle) wrote:
>> Mac OS X 10.11.4, Xcode 7.3. This was t
Mac OS X 10.11.4, Xcode 7.3. This was the first time I encountered this build
issue.
> On Apr 25, 2016, at 5:27 AM, Erik Joelsson wrote:
>
> Which version of Macosx and Xcode were used? Did this start happening
> recently?
>
> /Erik
>
> On 2016-04-22 18:10, J
> Begin forwarded message:
>
> From: "Jim Laskey (Oracle)"
> Subject: Build craziness
> Date: April 22, 2016 at 11:59:35 AM ADT
> To: jigsaw-dev
>
> make clean ; make images
>
> Building target 'images' in configuration
> 'mac
>> Ideally hotspot would review this, not build.
>> so it would be helpful if hotspot found an engineer to own the bug :-
>> https://bugs.openjdk.java.net/browse/JDK-8138820
>> <https://bugs.openjdk.java.net/browse/JDK-8138820>
>> So far as I know this is not tr
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 ver
+1
> On Aug 12, 2015, at 2:03 PM, Sundararajan Athijegannathan
> 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"
> https://bugs.openjdk.java.net/browse/JDK-8080678
>
> This subtask addr
I was wrong - that didn’t resolve my issue.
> On Apr 17, 2015, at 5:07 PM, Jim Laskey (Oracle)
> wrote:
>
> java.lang.module.ResolveException: Hash of java.security.jgss
> (IPAH/Z1wbzCE8aG78apqik6QR94TaBJqcatAkW+35rs=) differs to expected hash
> (O61Gv4243oRyV7LoD/FjaNBXg
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
java.lang.module.Resolver.che
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 ) {
+1
On Jan 8, 2015, at 2:52 AM, A. Sundararajan
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.
> I'm cc'ing nashorn-dev and jdk8u
+1
On Nov 28, 2014, at 6:41 AM, A. Sundararajan
wrote:
> Hi,
>
> Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8066146
>
> Thanks,
> -Sundar
Yes
On Mar 28, 2014, at 11:05 AM, Staffan Larsen 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) wrote:
>
/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
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
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
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
On
4
On 2013-03-04, at 12:59 AM, David Holmes wrote:
> On 27/02/2013 10:14 PM, Jim Laskey (Oracle) wrote:
>> 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 oth
2013-03-04, at 11:58 AM, Jim Laskey (Oracle) 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 wrote:
>
>> It seems to me that using $ in class names when they are NOT
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 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 us, multiple times
57 matches
Mail list logo
