Hi Naoto-san,
Thank you to introduce the workarounds!
It's surprising that SimpleDateFormat have supportted Gannen :)
2019年1月30日(水) 1:22 Naoto Sato :
> Hi Kishida-san,
>
> Currently we don't have a plan to support Gannen in java.time for
> formatting/parsing Japanese calendar dates. Here are a
This is a nice patch as I found the same problem back to December. Privately I
was using "(size + s > threshold)" condition for my cases, and found Michal's
early comment that this would lead to "unwanted space allocation" caused by
duplicate keys, thanks.
Looking forward to having this in
On 1/29/19 4:28 PM, Pavel Rappo wrote:
Alan, Lance,
I have created a webrev with the change:
http://cr.openjdk.java.net/~prappo/8218022/webrev.00/
Looks fine.
Mandy
Looks good Pavel :-)
> On Jan 29, 2019, at 7:28 PM, Pavel Rappo wrote:
>
> Alan, Lance,
>
> I have created a webrev with the change:
>
>http://cr.openjdk.java.net/~prappo/8218022/webrev.00/
>
> I added bonus fixes and updated the copyright years. If everybody is fine with
> this change,
Alan, Lance,
I have created a webrev with the change:
http://cr.openjdk.java.net/~prappo/8218022/webrev.00/
I added bonus fixes and updated the copyright years. If everybody is fine with
this change, I'm pushing it.
List of locations of additional fixes added to Andrey's patch:
I don’t think that is correct.
There are issues with whether and how file names are normalized when stored in
a directory, and the answers are file system dependent.
File system lookups are described as normalization-insensitive.
I’m not an expert, though, and it is hard to find decent
In case you missed my previous message, there is a use case for file paths
using macOS APIs.
Hm, Martin had mentioned that macOS uses something more restrictive than UTF-8.
It seems to me that a filesystem-specific encoding is called for here.
If you search the JDK repo for
On 1/29/2019 5:11 PM, Alexander Matveev wrote:
Hi Andy,
http://cr.openjdk.java.net/~herrick/8217792/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java.frames.html
Line 419 - Log.info() logs always. I think it is better to use
Log.verbose() or just
No attachment received.
David
On 30/01/2019 8:02 am, Andrey Turbanov wrote:
Could you please re-generate your patch? The reason I'm asking is that the
current patch contains extra line breaks.
Hm. There wasn't any extra line breaks in sent email. Regenerated
patch attached.
Andre Turbanov
Hi Andy,
http://cr.openjdk.java.net/~herrick/8217792/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java.frames.html
Line 419 - Log.info() logs always. I think it is better to use
Log.verbose() or just remove it.
Otherwise looks good.
Thanks,
Alexander
On
>Could you please re-generate your patch? The reason I'm asking is that the
>current patch contains extra line breaks.
Hm. There wasn't any extra line breaks in sent email. Regenerated
patch attached.
Andre Turbanov
Please review the jpackage fix for bugs [1] and [2] at [3].
These two fixes are for the JDK-8200758-branch branch of the open
sandbox repository (jpackage).
JDK-8217793 addresses what modules are included in the runtime of an
application or jre image
JDK-8217792 fixes the use of modular
How is this different from Collectors.collectingAndThen?
On 1/29/2019 3:30 PM, Peter Levart wrote:
Hi,
I wonder if there's any interest in adding a convenience factory
method for a Collector to the standard repertoire which would look
like the following:
/**
* Convert given {@link
Hi,
I wonder if there's any interest in adding a convenience factory method
for a Collector to the standard repertoire which would look like the
following:
/**
* Convert given {@link Collector} so that it applies an additional
finisher function that
* converts the result of
I figured out for the time being how I can programmatically handle setting
security that might be cross-platform for my application.
Past that it doesn’t seem to be finding resources off the class loader that it
should be…
With this…
ClassLoader cl =
Hi Kishida-san,
Currently we don't have a plan to support Gannen in java.time for
formatting/parsing Japanese calendar dates. Here are a couple of
workarounds:
1. Use java.text APIs to format/parse dates, e.g.,
jshell> new SimpleDateFormat("年",
+1
On 01/29/2019 06:04 AM, Nishit Jain wrote:
Hi Naoto,
Look good to me.
Regards,
Nishit Jain
On 26-01-2019 01:29, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8217609
The proposed changeset is located at:
fyi, mailers have a bad habit of wrapping patches at the wrong point.
Attaching it as a text (.txt) file works too.
On 01/29/2019 08:42 AM, Pavel Rappo wrote:
On 28 Jan 2019, at 22:23, Andrey Turbanov wrote:
Thanks to review. Patch updated. I'm not really sure what to do next.
I should find
> On 28 Jan 2019, at 22:23, Andrey Turbanov wrote:
>
> Thanks to review. Patch updated. I'm not really sure what to do next.
> I should find someone who can create issue and commit my patch to
> repository, right?
Andrey,
Could you please re-generate your patch? The reason I'm asking is that
As you know, Japanese government have a plan to change the era on May.
It will be the first year of the new era.
In practice, we describe the first year as "元年" not as "1年"
Now DateTimeFormatter with `G` output the era.
`DateTimeFormatter.ofPattern("Gy年").format(JapaneseDate.of(2019, 5, 2))`
On 29/01/2019 10:16 pm, Pavel Rappo wrote:
On 29 Jan 2019, at 08:50, David Holmes wrote:
Hi Pavel,
I don't think this kind of trivial change needs the OCA to be signed.
"A Participant may post messages to a list, submit simple patches, and make other
kinds of small contributions." [1]
Hi
> On 29 Jan 2019, at 08:50, David Holmes wrote:
>
> Hi Pavel,
>
> I don't think this kind of trivial change needs the OCA to be signed.
>
> "A Participant may post messages to a list, submit simple patches, and make
> other kinds of small contributions." [1]
Hi David,
That is true. However,
To reviewers,
Thank you for reviewing in a short time.
Best regards,
Ichiroh Takiguchi
On 2019-01-29 20:20, Lindenmaier, Goetz wrote:
Pushed.
Best regards,
Goetz
-Original Message-
From: Ichiroh Takiguchi
Sent: Dienstag, 29. Januar 2019 11:30
To: Lindenmaier, Goetz
Cc: build-dev
Pushed.
Best regards,
Goetz
> -Original Message-
> From: Ichiroh Takiguchi
> Sent: Dienstag, 29. Januar 2019 11:30
> To: Lindenmaier, Goetz
> Cc: build-dev ; ppc-aix-port-dev d...@openjdk.java.net>; core-libs-dev@openjdk.java.net; Baesken, Matthias
>
> Subject: RE: JDK-8217880 AIX
Looks good to me . The patch fixed the AIX build.
Best regards, Matthias
> -Original Message-
> From: Ichiroh Takiguchi
> Sent: Dienstag, 29. Januar 2019 11:30
> To: Lindenmaier, Goetz
> Cc: build-dev ; ppc-aix-port-dev port-...@openjdk.java.net>; core-libs-dev@openjdk.java.net;
> 29 jan. 2019 kl. 02:21 skrev Ichiroh Takiguchi :
>
> Hello.
>
> Sorry about build issue for JDK-8214533.
>
> EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix.
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8217880
> Change:
Hi Naoto,
Look good to me.
Regards,
Nishit Jain
On 26-01-2019 01:29, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8217609
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8217609/webrev.00/
Hello Goetz.
Thank you for build testing.
Yes, I need a sponsor.
If possible, could you handle it ?
Thanks,
Ichiroh Takiguchi
On 2019-01-29 19:17, Lindenmaier, Goetz wrote:
Hi,
this looks good, the build works with this patch.
Do you need a sponsor?
Best regards,
Goetz.
-Original
Hi,
this looks good, the build works with this patch.
Do you need a sponsor?
Best regards,
Goetz.
> -Original Message-
> From: Ichiroh Takiguchi
> Sent: Dienstag, 29. Januar 2019 02:21
> To: Lindenmaier, Goetz
> Cc: build-dev ; ppc-aix-port-dev d...@openjdk.java.net>;
Hi Martin,
I'd like to finish this review. Are you still willing to sponsor this?
Thanks!
On 1/9/19 11:39 AM, Michal Vala wrote:
ping
On 1/3/19 9:31 PM, Michal Vala wrote:
Hi Martin,
can we please finish this review?
On 12/19/18 6:32 PM, Michal Vala wrote:
On 12/19/18 4:15 PM, Martin
Done: http://hg.openjdk.java.net/jdk/jdk/rev/4cfa5f51eafa
From: Steve Groeger
Sent: Montag, 28. Januar 2019 17:25
To: Langer, Christoph
Cc: core-libs-dev@openjdk.java.net; Roger Riggs
Subject: RE: JDK-821 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java
passes even when test should fail
Hi Matthias,
> > New webrev :
> >
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/
>
> This is the one. Looks good ( and clean ).
I agree, this version would be ok for me to be pushed. It would be good
,though, if there was a test for this (long paths on Windows).
I also like
Hi Pavel,
On 29/01/2019 11:54 am, Pavel Rappo wrote:
On 28 Jan 2019, at 22:23, Andrey Turbanov wrote:
Thanks to review. Patch updated. I'm not really sure what to do next.
I should find someone who can create issue and commit my patch to
repository, right?
Have you signed the OCA [1]? The
Hi Chris,
this is fine, too.
Best regards, Goetz.
> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 28. Januar 2019 23:28
> To: Lindenmaier, Goetz
> Cc: core-libs-dev@openjdk.java.net
> Subject: RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE
> when the
34 matches
Mail list logo
