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 format and parse scientific
notation only via a
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
Another dull jsr166 integration (last one for jdk12?)
8212899: java/util/concurrent/tck/JSR166TestCase.java -
testMissedSignal_8187947(SubmissionPublisherTest): timed out waiting for
CountDownLatch for 40 sec
Sorry, I'm sympathetic but I can't help push this through.
These days, all computers should have a default charset of UTF-8 or perhaps
one of the other "Standard" charsets. Other charsets should be regarded as
legacy. Surely AIX has UTF-8 variants of all the locales?
On Sun, Nov 25, 2018 at
I agree!
(but don't have time ...)
On Sun, Nov 25, 2018 at 9:01 PM, Zheka Kozlov wrote:
> Currently, CopiesList.hashCode() is inherited from AbstractList which:
>
>- calls hashCode() for each element,
>- creates a new Iterator every time.
>
> However, for Collections.nCopies():
>
>
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8214170
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8214170/webrev.00/
The existing logic to determine if there is a pubic constructor for the
ResourceBundle class is
Hi,
On 11/19/18 3:37 PM, Roger Riggs wrote:
Raw::xxx_NDX are initialized to 1 + previous_NDX. It's a general
good approach to increment the index but I find it error-prone and
hard to catch mistake since the (adjacent) variable names look
so alike. Perhaps some form of verification or
The CSR looks fine,
On 11/26/2018 04:20 PM, Phil Race wrote:
Can someone review the CSR :
https://bugs.openjdk.java.net/browse/JDK-8214322 ?
Also my email below pointed to the webrev twice .. the bug id for this
issue is here :
https://bugs.openjdk.java.net/browse/JDK-8130264
-phil.
On
Can someone review the CSR :
https://bugs.openjdk.java.net/browse/JDK-8214322 ?
Also my email below pointed to the webrev twice .. the bug id for this
issue is here :
https://bugs.openjdk.java.net/browse/JDK-8130264
-phil.
On 11/16/18 1:36 PM, Sergey Bylokhov wrote:
Looks fine.
On
Hi Nishit,
Thanks for all the updates. The tests looks ok.
On 11/26/2018 02:56 AM, Nishit Jain wrote:
Hi Roger,
Please find my comments belowand check the updated webrev.
http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.02/
Regards,
Nishit Jain
On 22-11-2018 00:04, Roger Riggs
Thanks Lance. I added noreg-trivial. All existing tests (including the
XSLT ones) passed.
-Joe
On 11/26/18, 12:08 PM, Lance Andersen wrote:
Hi Joe,
Looks OK. Is there an existing test for this? if so you will want to
update your labels in the bug.
On Nov 26, 2018, at 2:59 PM, Joe Wang
Hi Joe,
Looks OK. Is there an existing test for this? if so you will want to update
your labels in the bug.
> On Nov 26, 2018, at 2:59 PM, Joe Wang wrote:
>
> Hi,
>
> Please review a quick fix that compares the String with the QName's string
> representation.
>
> JBS:
Hi,
Please review a quick fix that compares the String with the QName's
string representation.
JBS: https://bugs.openjdk.java.net/browse/JDK-8177286
Diff:
---
a/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java
+++
Hi,
Thanks for updating this proposal. Some comments on the javadoc/spec.
The class name Hex isn't very evocative of its function.
HexFormat would convey a more complete idea as to its function and be
similar to
to the existing DecimalFormat and NumberFormat classes though they do
not share
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 found at:
On Mon, Nov 26, 2018 at 6:52 PM Ichiroh Takiguchi
wrote:
>
> Hello Volker.
>
> I posted same kind of fix before:
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-June/003551.html
>
> I could not find out brace handling issue on XLC++ 13.1.
>
> For workaround,
> ==
> ---
>
Hello Volker.
I posted same kind of fix before:
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-June/003551.html
I could not find out brace handling issue on XLC++ 13.1.
For workaround,
==
---
old/src/java.base/share/native/libjimage/NativeImageBuffer.cpp 2018-06-07
21:06:09
On Mon, Nov 26, 2018 at 2:16 PM Adam Farley8 wrote:
>
> Hi Volker,
>
> Apologies for the delay.
>
> I ran the contents of the file as requested (neat tip, thanks!) and I
> discovered something:
>
> If jdk_internal_jimage_NativeImageBuffer.h contains this:
>
> -
> extern "C" {
>
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 format and parse scientific
notation only via a pattern; there is currently no factory method that
creates a
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 will need to have an equivalent on Windows.
>
...Or we could simply remove the -qvisibility bit from the .mk file,
as Marcus mentioned.
https://bugs.openjdk.java.net/browse/JDK-8214063
Might be less technically correct, but it wouldn't make OpenJDK on
AIX more technically incorrect than it already is, with the added
bonus that it allows
The API link should be
http://cr.openjdk.java.net/~vinnie/8170769/javadoc.06/api/java.base/java/util/Hex.htm
--Sean
On 11/23/18 9:51 AM, Vincent Ryan wrote:
Hello,
Please review this proposal for a new API to conveniently generate and
display binary data using hexadecimal string
Hi Volker,
Apologies for the delay.
I ran the contents of the file as requested (neat tip, thanks!) and I
discovered something:
If jdk_internal_jimage_NativeImageBuffer.h contains this:
-
extern "C" {
__attribute__((visibility("default"))) jobject JNICALL
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.
-Alan
> If you can then it would be great, if only to save others from looking
> at it and wondering if it should also be changed. Maybe for another
> issue but there are several other usages in the java launcher that
> should be looked at.
Hi Alan,
I've done this here:
Hi Naoto,
To add to my previous mail comment, the DecimalFormat spec also says that
/*"DecimalFormat can be instructed to format and parse scientific
notation only via a pattern; there is currently no factory method that
creates a scientific notation format. In a pattern, the exponent
25 matches
Mail list logo
