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 pattern
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
https:/
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 10:1
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 incorr
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 assertion
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 1
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 15/11/
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 w
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: https://bugs.openjd
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
+++
b/src/java.xml/share/classes/com
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:
http://cr.openjdk.java.net/~lancea/821045
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,
> ==
> ---
> old/src
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" {
> __attribute__(
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 scientifi
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 u
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 representati
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
Java_jdk_internal_jimage_NativeIm
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:
http://cr.openjdk.java.net/~nji
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
charact
25 matches
Mail list logo