Looks good!
With kind regards,
Ivan
On 11/27/18 8:54 PM, Hamlin Li wrote:
Would you please review the following patch?
https://bugs.openjdk.java.net/browse/JDK-8211975
http://cr.openjdk.java.net/~mli/8211975/webrev.00/
Thank you
-Hamlin
--
With kind regards,
Ivan Gerasimov
Would you please review the following patch?
https://bugs.openjdk.java.net/browse/JDK-8211975
http://cr.openjdk.java.net/~mli/8211975/webrev.00/
Thank you
-Hamlin
On Tue, Nov 27, 2018 at 7:25 PM, Nick Gasson wrote:
> > I missed one thing then looking at this. In TimeZone_md.c it should be
> > #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but
> > I need to change this one line before pushing.
>
> Hi Alan,
>
> Yes feel free to modify
> I missed one thing then looking at this. In TimeZone_md.c it should be
> #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but
> I need to change this one line before pushing.
Hi Alan,
Yes feel free to modify it. I think looking at the at other files
with these #defines more
On 11/27/18 2:55 PM, Mandy Chung wrote:
On 11/27/18 2:43 PM, naoto.s...@oracle.com wrote:
If no-arg constructor does not exist, the javadoc does not specify
its behavior (or I'm missing it?). I believe the current behavior
is consistent with JDK 8 behavior which throws
Hi,
Please review a follow up webrev[1] based on Priyanka’s patch, it simply added
a test case for Mac only that will link with libjli.
Note that, to use invoke API, one should probably link with libjvm, which works
for all supported platforms, not just Mac.
Cheers,
Henry
[1]
On 11/27/18 2:43 PM, naoto.s...@oracle.com wrote:
If no-arg constructor does not exist, the javadoc does not specify
its behavior (or I'm missing it?). I believe the current behavior
is consistent with JDK 8 behavior which throws
NoSuchMethodException. We should fix the spec to
Hi Deepak,
Roger is right about trying to avoid the extra copy. Sorry I did not point
that out previously.
WRT using 47 vs ‘/‘, given that the rest of ZipFileSystem uses ‘/‘, it would
be best keep the usage consistent within the class.
Best,
Lance
> On Nov 27, 2018, at 4:51 AM, Deepak
Hi Mandy,
On 11/27/18 12:23 PM, Mandy Chung wrote:
On 11/27/18 10:36 AM, naoto.s...@oracle.com wrote:
Comment modified as suggested:
http://cr.openjdk.java.net/~naoto/8214170/webrev.01/
What is the exception message? I think it's
"PrivateConstructorRB.()" which would be confusing.
A
Looks good to me.
Mandy
On 11/27/18 1:00 PM, Roger Riggs wrote:
Hi,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw-4/index.html
- Updated defaults for VENDOR, VENDOR_URL, VENDOR_URL_BUG to:
COMPANY_NAME=N/A
VENDOR_URL=https://openjdk.java.net/
Hi,
In ZipFileSystem.java, at 1071.
- The code will be more readable if you use character literal '/'
instead of 47.
- Save making an extra copy of the name array by testing for '/'
directly in the cen array
and create either the full name or the name without the '/'.
- 1073: The
This looks good to me.
/Erik
On 2018-11-27 13:00, Roger Riggs wrote:
Hi,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw-4/index.html
- Updated defaults for VENDOR, VENDOR_URL, VENDOR_URL_BUG to:
COMPANY_NAME=N/A
VENDOR_URL=https://openjdk.java.net/
Hi,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw-4/index.html
- Updated defaults for VENDOR, VENDOR_URL, VENDOR_URL_BUG to:
COMPANY_NAME=N/A
VENDOR_URL=https://openjdk.java.net/
VENDOR_URL_BUG=https://bugreport.java.com/bugreport/
- Added Brent's suggestion to
On 11/26/18 10:41 AM, Lance Andersen wrote:
Hi,
Please review this change which allows the jar tool to set the module version
without specifying the setting a main class
The relevant jck tests have run clean in mach 5 as do the tier1, tier2 and
tier3 tests run clean
The webrev can be
Mostly great. I look forward to being able to use it (eventually) in
tools like javac, javadoc.
Doc nits:
I would suggest using "Although" instead of "Though" in "Though the
strings are typically filesystem paths", and since it follows "Note:" it
does not need to be capitalized.
More
On 11/27/18 10:36 AM, naoto.s...@oracle.com wrote:
Comment modified as suggested:
http://cr.openjdk.java.net/~naoto/8214170/webrev.01/
What is the exception message? I think it's
"PrivateConstructorRB.()" which would be confusing.
A better fix may be using getDeclaredConstructor and
Please review a refreshed API for parsing search and using paths.
Thanks for the earlier comments and suggestions.
java.util.SearchPath is an immutable sequence of strings, typically
filesystem paths.
A search path is created from a list of strings or by splitting a string
using
Hi,
Please review a fix for the adoptNode impl. Before a node from a
deferred DOM can be adopted, it needs to be fully expanded.
JBS: https://bugs.openjdk.java.net/browse/JDK-8213117
webrev: http://cr.openjdk.java.net/~joehw/jdk12/8213117/webrev/
Thanks,
Joe
Hi Thomas,
On 11/26/2018 10:05 AM, Thomas Stüfe wrote:
Hi Roger,
On Wed, Nov 21, 2018 at 4:03 PM Roger Riggs wrote:
Hi Thomas,
I'd be interested in hearing more about the use cases.
There seem to be many cases where containers are doing the management
of groups of processes.
The function
On 26/11/2018 09:08, Nick Gasson wrote:
Hi Alan,
I've done this here:
http://cr.openjdk.java.net/~njian/8214077/webrev.3/
I missed one thing then looking at this. In TimeZone_md.c it should be
#ifdef MACOSX rather than #ifndef. I can sponsor the change for you but
I need to change this one
Please review a test update to address an intermittent test failure.
The test is modified to accept the current implementation behavior of
the input streams
from processes that may under race conditions with close throw
IOE("Stream closed").
Details and analysis in the Jira:
By the way, in hotspot we are generating a .def file dynamically while keeping
the JNICALL calling convention (for symbols such as JNI_CreateJavaVM) I believe
(just by looking through the code in
http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk,
unless this
Hi Roger,
Thanks for the review.
On 11/27/18 9:58 AM, Roger Riggs wrote:
Hi Naoto,
Look ok.
java/util/ResourceBundle.java: 3187
The comment isn't strictly correct since the block applies to named
(and open) modules too.
Comment modified as suggested:
On Nov 27, 2018, at 9:49 AM, Brian Goetz wrote:
>
> Doug is right that there is an enormous potential list of sort methods, and
> we can't include them all. But I do miss the ability to extract indexes
> instead of sorting the array itself.
Or, slightly more generally, sorting an int[] or
Hello Volker.
OK, I follow your decision.
Anyway, I'd like to show you one more workaround.
$ hg di src/java.base/share/native/libjimage/osSupport.hpp
src/java.base/share/native/libjimage/NativeImageBuffer.cpp
$ sh NativeImageBuffer.o.cmdline
Hi Naoto,
Look ok.
java/util/ResourceBundle.java: 3187
The comment isn't strictly correct since the block applies to named
(and open) modules too.
[I think I would complete the conversion of the test to java to know
that it was working and not wait for 8213127].
Thanks, Roger
On
Doug is right that there is an enormous potential list of sort methods,
and we can't include them all. But I do miss the ability to extract
indexes instead of sorting the array itself.
On 11/14/2018 3:01 AM, Laurent Bourgès wrote:
Hi,
I am a scientist and the author of the Marlin renderer,
Hi Adam, Ichiroh,
this is actually exactly what I wanted to propose in the mail I was
just writing :)
You may have noticed that I've renamed the bug to "8214063: [AIX]
Disable symbol visibility flags". For the next step which will enable
symbol visibility on AIX we already have the following
Hi Nishit,
On 11/26/18 11:11 PM, Nishit Jain wrote:
Hi Naoto,
On 26-11-2018 21:01, naoto.s...@oracle.com wrote:
Hi Nishit,
On 11/26/18 12:41 AM, Nishit Jain wrote:
Hi Naoto,
To add to my previous mail comment, the DecimalFormat spec also says
that
/*"DecimalFormat can be instructed to
Hi Ichiroh and Volker.
Short version:
I propose we exclude the -qvisibility option to conclude this bug, and
raise a new bug to cover adding -qvisibility into the build, complete with
the attendant supporting changes.
Long Version:
Based on this bug, I feel confident saying that anyone
On 27/11/2018 13:28, Magnus Ihse Bursie wrote:
26 nov. 2018 kl. 13:27 skrev Alan Bateman :
On 26/11/2018 09:08, Nick Gasson wrote:
Hi Alan,
I've done this here:
http://cr.openjdk.java.net/~njian/8214077/webrev.3/
This looks good and I think means we no longer have any stat usages in
> 26 nov. 2018 kl. 13:27 skrev Alan Bateman :
>
>> On 26/11/2018 09:08, Nick Gasson wrote:
>> Hi Alan,
>>
>> I've done this here:
>>
>> http://cr.openjdk.java.net/~njian/8214077/webrev.3/
> This looks good and I think means we no longer have any stat usages in
> libjava.
Do we have stat
Hello Volker.
Sorry for your confusion.
I want to keep visibility feature on AIX platform for future OpenJDK.
If I can apply workaround for AIX platform...
XLC++ 13.1 is confused destructor order for ~SimpleCriticalSectionLock()
on src/java.base/share/native/libjimage/osSupport.hpp, if
Hello Volker.
Sorry for your confusion.
I want to keep visibility feature on AIX platform for future OpenJDK.
If I can apply workaround for AIX platform...
XLC++ 13.1 is confused destructor order for ~SimpleCriticalSectionLock()
on src/java.base/share/native/libjimage/osSupport.hpp, if
Priya,
On 27/11/2018 08:46, Priya Lakshmi Muthuswamy wrote:
Hi,
Kindly review the fix for https://bugs.openjdk.java.net/browse/JDK-8213921
webrev : http://cr.openjdk.java.net/~pmuthuswamy/8213921/webrev.00/
I think this is a good change. I built your proposed patch and was
pleasantly
Hi Volker,
I've attached a new webrev to the bug (link below) that includes the
blanket
removal of the three locations that we mess with -qvisibility in the event
of "xlC != 12.1" on AIX.
https://bugs.openjdk.java.net/browse/JDK-8214063
Let me know if this works for you.
Best Regards
Adam
Hi,
The Japanese Era starts from May 1st, 2019 and I see the fix is already part of
JDK 11 and also the following defect opened to back-port it to JDK 8.
https://bugs.openjdk.java.net/browse/JDK-8207338
What would be the expected time frame for JDK-8207338 to land in JDK 8?
Thanks &
Hi nio-dev team,
Gentle reminder for review of below fix.
Regards,
Deepak
From: Deepak Kejriwal
Sent: Thursday, November 8, 2018 12:17 AM
To: 'nio-...@openjdk.java.net'
Subject: RFR: JDK-8197398 (zipfs) OutOfMemoryError when talking contents of
empty JAR file
Hi all,
No worries Martin, I realize what you're saying about AIX, I shall put out
feelers for another sponsor.
Thanks
Andrew
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com
From: Martin
Hi,
Kindly review the fix for https://bugs.openjdk.java.net/browse/JDK-8213921
webrev : http://cr.openjdk.java.net/~pmuthuswamy/8213921/webrev.00/
Thanks,
Priya
40 matches
Mail list logo
