Re: Will we have any option to format 2019 as 元号元年?

[kishida naoki]

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 couple of
> workarounds:
>
> 1. Use java.text APIs to format/parse dates, e.g.,
>
> jshell> new SimpleDateFormat("年",
> Locale.forLanguageTag("ja-JP-u-ca-japanese")).format(new
> Calendar.Builder().setDate(2019, Calendar.MAY, 1).build().getTime())
> $3 ==> "元号元年"
>
> 2. For java.time API, use
> DateTimeFormatterBuilder.appendText(TemporalField, Map) to
> map the 1 to "元". Following issue demonstrates how to do it:
>
> https://bugs.openjdk.java.net/browse/JDK-8042131
>
> HTH,
> Naoto
>
> On 1/29/19 4:21 AM, kishida naoki wrote:
> > 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))`
> > output `元号1年`
> >
> > Do you have any plan to have a option to format it as `元号元年` or already
> > implemented?
> >
>


-- 
きしだ なおき

RE: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

[Patrick Zhang]

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 jdk/jdk trunk.

Regards
Patrick

-Original Message-
From: core-libs-dev  On Behalf Of 
Michal Vala
Sent: Tuesday, January 29, 2019 6:00 PM
To: Martin Buchholz 
Cc: core-libs-dev 
Subject: Re: JDK-8210280 - Unnecessary reallocation when invoking 
HashMap.putAll()

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 Buchholz wrote:
 On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs  wrote:

> Hi Martin,
>
> It is also useful and conventional to print the seed of the random 
> so that if necessary it can be reproduced.
>

 For many years, we've been using ThreadLocalRandom for testing, and 
 that does not allow setting a seed.

 I remain unconvinced that saving a seed has value in the real 
 world.  When a randomized test fails, running it with sufficient 
 iterations has always worked for me.

>>>
>>> What's the reason behind using ThreadLocalRandom?
>>>
>>> In my opinion, reproducing the issue is key. One failure of 
>>> randomized test run might be caused by one issue, second run due to 
>>> another issue. How we reproduce then and how we know even how many 
>>> issues we have? When we're running random tests until it pass, it might 
>>> even hide the issue.
>>>
>>> They sure have good value on reveal the issue, but then we have to 
>>> know how to reproduce and what we're searching for.
>>>
>>> If this case would not require ThreadLocalRandom and Random is 
>>> enough, I'd like to use that because of benefits I've mentioned.
>>>
>>
> 

--
Michal Vala
OpenJDK QE
Red Hat Czech

Re: RFR [13] 8218022: Repeated words typos in java.base

[Mandy Chung]

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

Re: RFR [13] 8218022: Repeated words typos in java.base (was: Duplicate words typos in comments/javadoc/strings)

[Lance Andersen]

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, I'm pushing it.
> 
> List of locations of additional fixes added to Andrey's patch:
> 
>sun.net.www.http.HttpClient#HttpClient(java.net.URL, java.lang.String, int)
>jdk.internal.module.ServicesCatalog#create
>jdk.internal.platform.Metrics#getCpuSetMemoryPressure
>java.lang.invoke.MethodHandleNatives#linkMethod
>
> java.lang.LiveStackFrame#getStackWalker(java.util.Set)
> 
> -Pavel
> 
> P.S. 
> 
> I also added a missing '*' to the sun.security.util.ConstraintsParameters top
> level doc and removed the "on" preposition from the second sentence. The words
> seemed to be out of order: "on passed" instead of "passed on".
> 
> It might look even better if we remove this preposition completely:
> 
> ...
> * This is currently passed between PKIX, AlgorithmChecker,
> * and DisabledAlgorithmConstraints.
> */
> public class ConstraintsParameters {
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

RFR [13] 8218022: Repeated words typos in java.base (was: Duplicate words typos in comments/javadoc/strings)

[Pavel Rappo]

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:
 
sun.net.www.http.HttpClient#HttpClient(java.net.URL, java.lang.String, int)
jdk.internal.module.ServicesCatalog#create
jdk.internal.platform.Metrics#getCpuSetMemoryPressure
java.lang.invoke.MethodHandleNatives#linkMethod

java.lang.LiveStackFrame#getStackWalker(java.util.Set)

-Pavel

P.S. 

I also added a missing '*' to the sun.security.util.ConstraintsParameters top
level doc and removed the "on" preposition from the second sentence. The words
seemed to be out of order: "on passed" instead of "passed on".

It might look even better if we remove this preposition completely:

...
 * This is currently passed between PKIX, AlgorithmChecker,
 * and DisabledAlgorithmConstraints.
 */
public class ConstraintsParameters {

Re: possible problem with JNI GetStringUTFChars

[Alan Snyder]

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 up-to-date 
documentation on this matter.



> On Jan 29, 2019, at 3:24 PM, Stuart Marks  wrote:
> 
> 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.

Re: possible problem with JNI GetStringUTFChars

[Stuart Marks]

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 GetStringUTFChars, you will find several uses 
that do not appear to involve serialization or data input/output.


To clarify, I was talking about uses of modified UTF-8 from *Java* code. The 
only places modified UTF-8 should appear in Java code are (I think) in 
serialization and in Data*Stream.


Native code needs to use modified UTF-8 because it's required for various JVM 
interfaces.



It is not obvious whether these uses are correct or not.

Consider test/jdk/java/nio/channels/FileChannel/directio/libDirectIO.c

where GetStringUTFChars is used to convert a file path to pass to open().

At the very least, anyone using GetStringUTFChars as a short cut for true UTF-8 
conversion should document why this short cut is correct, as is done in 
awt_InputMethod, for example.


Correct. If there are places that use GetStringUTFChars is used where real UTF-8 
is required, then that's quite possibly a bug.


The use in libDirectIO.c is certainly suspicious. Note that this is test code, 
and the only strings that are passed to it are temp file names from 
Files.createTempFile(). It seems likely that such strings contain non-null BMP 
characters, for which modified UTF-8 and real UTF-8 are the same, so this is 
unlikely to be a problem in practice.


Still, you're right, if there are places where the JDK uses GetStringUTFChars 
where real UTF-8 is required, those would be bugs.


**

Anyway, I think it's unfortunate, but in the JNI world we're saddled with 
modified UTF-8. If you need real UTF-8, I recommend you do the conversion in 
Java before you get down to native. The reason is that there are some edge cases 
with codeset conversion (e.g., malformed sequences such as unpaired surrogates) 
that would require a bunch of additional facilities that aren't readily 
available from native code, as far as I know.


s'marks




   Alan



On Jan 28, 2019, at 2:10 PM, Stuart Marks > wrote:


(From Java code, the Charset encoders/decoders handle real UTF-8, which seems 
to cover most cases. Modified UTF-8 occurs only within serialization and 
Data{Input,Output}Stream.)

Re: RFR: JKDK-8217331, JDK-8217792

[Andy Herrick]

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 remove it.


Actually, I had created a webrev.02 - but failed to post it - this 
section will be removed, including the Log statement.
There was some other feedback on this topic (what modules to include in 
a jre image) that I need to process - and may wind up with a different 
approach, so consider this RFR on hold till sometime tomorrow.

/Andy


Otherwise looks good.

Thanks,
Alexander


On 1/29/2019 12:57 PM, Andy Herrick wrote:

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 jars

[1] https://bugs.openjdk.java.net/browse/JDK-8217793

[2] https://bugs.openjdk.java.net/browse/JDK-8217792

[3] http://cr.openjdk.java.net/~herrick/8217792/webrev.01/

/Andy

Re: Duplicate words typos in comments/javadoc/strings

[David Holmes]

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

Re: RFR: JKDK-8217331, JDK-8217792

[Alexander Matveev]

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 1/29/2019 12:57 PM, Andy Herrick wrote:

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 jars

[1] https://bugs.openjdk.java.net/browse/JDK-8217793

[2] https://bugs.openjdk.java.net/browse/JDK-8217792

[3] http://cr.openjdk.java.net/~herrick/8217792/webrev.01/

/Andy

Re: Duplicate words typos in comments/javadoc/strings

[Andrey Turbanov]

>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

RFR: JKDK-8217331, JDK-8217792

[Andy Herrick]

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 jars

[1] https://bugs.openjdk.java.net/browse/JDK-8217793

[2] https://bugs.openjdk.java.net/browse/JDK-8217792

[3] http://cr.openjdk.java.net/~herrick/8217792/webrev.01/

/Andy

Re: Collectors.converting

[Brian Goetz]

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 Collector} so that it applies an 
additional finisher function that
 * converts the result of given collector. The characteristics of 
returned collector is

 * the same as that of the given inner collector but without any
 * {@link 
java.util.stream.Collector.Characteristics#IDENTITY_FINISH}.

 *
 * @param collector   the inner collector to delegate 
collection to

 * @param resultConverter the additional result finisher function
 * @param  the type of input stream elements
 * @param  the type of intermediate aggregation
 * @param  the type of result of inner collector
 * @param     the type of final result
 * @return the converted collector
 */
    public static  Collector converting(
    Collector collector,
    Function resultConverter
    ) {
    return new Collector() {
    @Override
    public Supplier supplier() { return 
collector.supplier(); }


    @Override
    public BiConsumer accumulator() { return 
collector.accumulator(); }


    @Override
    public BinaryOperator combiner() { return 
collector.combiner(); }


    @Override
    public Function finisher() { return 
resultConverter.compose(collector.finisher()); }


    @Override
    public Set characteristics() {
    EnumSet characteristics = 
EnumSet.noneOf(Characteristics.class);

characteristics.addAll(collector.characteristics());
characteristics.remove(Characteristics.IDENTITY_FINISH);
    return Collections.unmodifiableSet(characteristics);
    }
    };
    }


The rationale is as follows... Composability of collectors allows 
doing things like:


    interface Measurement {
    long value();
    String type();
    }

    Stream measurements = 

    Map statsByType =
    measurements
    .collect(
    groupingBy(
    Measurement::type,
    summarizingLong(Measurement::value)
    )
    );

...but say I wanted the final result to be a map of avarage values by 
type and the values to be BigDecimal objects calculated with scale of 
19. I can create an intermediate map like above and then transform it 
to new map, like this:


    static BigDecimal toBDAverage(LongSummaryStatistics stats) {
    return BigDecimal.valueOf(stats.getSum())
 .divide(
BigDecimal.valueOf(stats.getCount()),
 20, RoundingMode.HALF_EVEN);
    }

    Map averageByType =
    statsByType
    .entrySet()
    .stream()
    .collect(toMap(Map.Entry::getKey, e -> 
toBDAverage(e.getValue(;


...this is ugly as it requires intermediate result to be materialized 
as a HashMap. Wouldn't it be possible to collect the original stream 
to final result in one go?


With the above Collectors.converting factory method, it would:

    Map averageByType =
    measurements
    .collect(
    groupingBy(
    Measurement::type,
    converting(
    summarizingLong(Measurement::value),
    stats -> toBDAverage(stats)
    )
    )
    );

We already have Collectors.mapping(Function, Collector) method that 
constructs Collector that maps elements to be collected by inner 
collector. Collectors.converting(Collectors, Function) would be a twin 
brother that constructs Collector that converts the collection result 
of the inner collector. Both are useful in compositions like above, 
but we only have the 1st...


What do you think?

Regards, Peter

Collectors.converting

[Peter Levart]

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 given collector. The characteristics of 
returned collector is

 * the same as that of the given inner collector but without any
 * {@link java.util.stream.Collector.Characteristics#IDENTITY_FINISH}.
 *
 * @param collector   the inner collector to delegate collection to
 * @param resultConverter the additional result finisher function
 * @param  the type of input stream elements
 * @param  the type of intermediate aggregation
 * @param  the type of result of inner collector
 * @param     the type of final result
 * @return the converted collector
 */
    public static  Collector converting(
    Collector collector,
    Function resultConverter
    ) {
    return new Collector() {
    @Override
    public Supplier supplier() { return collector.supplier(); }

    @Override
    public BiConsumer accumulator() { return 
collector.accumulator(); }


    @Override
    public BinaryOperator combiner() { return 
collector.combiner(); }


    @Override
    public Function finisher() { return 
resultConverter.compose(collector.finisher()); }


    @Override
    public Set characteristics() {
    EnumSet characteristics = 
EnumSet.noneOf(Characteristics.class);

    characteristics.addAll(collector.characteristics());
characteristics.remove(Characteristics.IDENTITY_FINISH);
    return Collections.unmodifiableSet(characteristics);
    }
    };
    }


The rationale is as follows... Composability of collectors allows doing 
things like:


    interface Measurement {
    long value();
    String type();
    }

    Stream measurements = 

    Map statsByType =
    measurements
    .collect(
    groupingBy(
    Measurement::type,
    summarizingLong(Measurement::value)
    )
    );

...but say I wanted the final result to be a map of avarage values by 
type and the values to be BigDecimal objects calculated with scale of 
19. I can create an intermediate map like above and then transform it to 
new map, like this:


    static BigDecimal toBDAverage(LongSummaryStatistics stats) {
    return BigDecimal.valueOf(stats.getSum())
 .divide(
BigDecimal.valueOf(stats.getCount()),
 20, RoundingMode.HALF_EVEN);
    }

    Map averageByType =
    statsByType
    .entrySet()
    .stream()
    .collect(toMap(Map.Entry::getKey, e -> 
toBDAverage(e.getValue(;


...this is ugly as it requires intermediate result to be materialized as 
a HashMap. Wouldn't it be possible to collect the original stream to 
final result in one go?


With the above Collectors.converting factory method, it would:

    Map averageByType =
    measurements
    .collect(
    groupingBy(
    Measurement::type,
    converting(
    summarizingLong(Measurement::value),
    stats -> toBDAverage(stats)
    )
    )
    );

We already have Collectors.mapping(Function, Collector) method that 
constructs Collector that maps elements to be collected by inner 
collector. Collectors.converting(Collectors, Function) would be a twin 
brother that constructs Collector that converts the collection result of 
the inner collector. Both are useful in compositions like above, but we 
only have the 1st...


What do you think?

Regards, Peter

jpackage OS X classpath

[Michael Hall]

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 = Thread.currentThread().getContextClassLoader();
syslog.println("cl is " + cl + "\nuser.dir " + 
System.getProperty("user.dir") + "\nCP> " + 
System.getProperty("java.class.path"));  

I get this…

cl is jdk.internal.loader.ClassLoaders$AppClassLoader@55054057
user.dir /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java
CP> 
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java/halfpipe.jar:RserveEngine.jar:quartz-jobs-2.2.2.jar:commons-logging-1.1.1.jar:httpcore-4.4.10.jar:groovy-all-2.6.0-alpha-1.jar:
…
:resource.jar
...
…and so on...

Only the first path in java.class.path is absolute - to the main jar. Would 
this break if the application is moved? The other paths are relative. I notice 
user.dir is now default set directly to the Java directory within the app. I 
assume this is how relative is supposed to work. This is again a change from 
legacy OS X java app’s. Prior to the OS X port I think Apple set this to the 
parent directory of the application itself. With AppBundler set up during the 
port it was set to the user home directory. I think for security concerns? 
(App’s should usually be in the Application directory, this should not be 
written to by the application). So this is another change that legacy app’s 
could have issues with. 

It might be a thought to document some of the differences to legacy java 
applications somewhere? 

Anyhow, I put the resources that I am currently not finding in the resource.jar 
shown above. I thought some testing with non-jpackage apps showed this would 
work. These used to be in the “Classes” directory as mentioned in an earlier 
post. A rather obscure feature probably not many app’s took advantage of. But I 
am now not finding them in the jpackage resource.jar for some reason still to 
be determined. 

Like…

BufferedReader rdr = new 
BufferedReader(new 
InputStreamReader(cl.getResourceAsStream("Scripts/loader.js")));

 
org.mozilla.javascript.EvaluatorException: Couldn't open file "Scripts/mm.js". 
(unnamed script#1)
at 
org.mozilla.javascript.DefaultErrorReporter.runtimeError(DefaultErrorReporter.java:77)
at 
org.mozilla.javascript.DefaultErrorReporter.error(DefaultErrorReporter.java:64)
at org.mozilla.javascript.Context.reportError(Context.java:956)

Actually what it says it’s not finding isn’t loader.js but a script that 
loader.js should load? So maybe again this is some difference in how a nested 
load works? Again, it would be different application behavior somehow if so.

Re: Will we have any option to format 2019 as 元号元年?

[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 couple of 
workarounds:


1. Use java.text APIs to format/parse dates, e.g.,

jshell> new SimpleDateFormat("年", 
Locale.forLanguageTag("ja-JP-u-ca-japanese")).format(new 
Calendar.Builder().setDate(2019, Calendar.MAY, 1).build().getTime())

$3 ==> "元号元年"

2. For java.time API, use 
DateTimeFormatterBuilder.appendText(TemporalField, Map) to 
map the 1 to "元". Following issue demonstrates how to do it:


https://bugs.openjdk.java.net/browse/JDK-8042131

HTH,
Naoto

On 1/29/19 4:21 AM, kishida naoki wrote:

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))`
output `元号1年`

Do you have any plan to have a option to format it as `元号元年` or already
implemented?

Re: [13] RFR: 8217609: New era placeholder not recognized by java.text.SimpleDateFormat

[Roger Riggs]

+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:

http://cr.openjdk.java.net/~naoto/8217609/webrev.00/

Although the behavior described in the issue is the expected one 
(i.e., CLDR currently does not provide names for the new era), 
supplementing the name in the CLDR data is desirable from the user's 
point of view.


Naoto

Re: Duplicate words typos in comments/javadoc/strings

[Roger Riggs]

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 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 the
current patch contains extra line breaks.

Please paste the exact diff output into your message. Do not apply any
additional formatting on top of it.

Thank you.

Re: Duplicate words typos in comments/javadoc/strings

[Pavel Rappo]

> 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 the
current patch contains extra line breaks.

Please paste the exact diff output into your message. Do not apply any
additional formatting on top of it.

Thank you.

Will we have any option to format 2019 as 元号元年?

[kishida naoki]

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))`
output `元号1年`

Do you have any plan to have a option to format it as `元号元年` or already
implemented?

-- 
Naoki Kishida

Re: Duplicate words typos in comments/javadoc/strings

[David Holmes]

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 David,

That is true. However, I'm not sure how to distinguish between a trivial patch
and a not so trivial.


True for code changes, but duplicate word removal seems about as trivial 
as you can get!


David

Re: Duplicate words typos in comments/javadoc/strings

[Pavel Rappo]

> 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, I'm not sure how to distinguish between a trivial patch
and a not so trivial.

RE: JDK-8217880 AIX build issue about JDK-8214533

[Ichiroh Takiguchi]

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 ; ppc-aix-port-dev 
d...@openjdk.java.net>; core-libs-dev@openjdk.java.net; Baesken, 
Matthias


Subject: RE: JDK-8217880 AIX build issue about JDK-8214533

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 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>; core-libs-dev@openjdk.java.net; Baesken,
>> Matthias
>> 
>> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533
>>
>> 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: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/
>>
>> Could you review the fix ?
>>
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>>
>> On 2019-01-28 22:49, Ichiroh Takiguchi wrote:
>> > Hello Goetz.
>> >
>> > Thank you for your suggestion.
>> > I just open JDK-8217880 [1].
>> >
>> > I just restart clean build.
>> >
>> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open.
>> >
>> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880
>> >
>> > Thanks,
>> > Ichiroh Takiguchi
>> >
>> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote:
>> >> Hi Ichiroh,
>> >>
>> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for
>> >> it.
>> >> I assume the fix is quite trivial so we can review it quick.
>> >>
>> >> Best regards,
>> >>   Goetz.
>> >>
>> >>> -Original Message-
>> >>> From: ppc-aix-port-dev 
On
>> >>> Behalf Of Ichiroh Takiguchi
>> >>> Sent: Montag, 28. Januar 2019 14:13
>> >>> To: Baesken, Matthias 
>> >>> Cc: build-dev ; ppc-aix-port-dev
>> >>> > >>> d...@openjdk.java.net>; core-libs-dev@openjdk.java.net; Alan Bateman
>> >>> 
>> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default
>> >>> charset
>> >>>
>> >>> Hello.
>> >>>
>> >>> I'm very sorry. It's my fault.
>> >>> EUC_JP class was moved to java.base module.
>> >>> (sun.nio.cs.EUC_JP).
>> >>>
>> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and
>> >>> EUC_JP_Open.
>> >>>
>> >>> Could you suggest me how I should provide new webrev files ?
>> >>>
>> >>> Thanks,
>> >>> Ichiroh Takiguchi
>> >>>
>> >>>
>> >>> On 2019-01-28 17:03, Baesken, Matthias wrote:
>> >>> > Hello,   seems  8214533   got pushed  recently  into  jdk/jdk.   Now
>> >>> > we see build errors on AIX  ,  are they related to  this change ?
>> >>> >
>> >>> >
>> >>> > /nb/rs6000_64/nightly/output-jdk-
>> >>>
test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
>> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
>> >>> > outside package
>> >>> > private static class Decoder extends EUC_JP.Decoder {
>> >>> >^
>> >>> > /nb/rs6000_64/nightly/output-jdk-
>> >>>
test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69:
>> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
>> >>> > outside package
>> >>> > private static class Encoder extends EUC_JP.Encoder {
>> >>> >^
>> >>> > /nb/rs6000_64/nightly/output-jdk-
>> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65:
>> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
>> >>> > outside package
>> >>> > private static class Decoder extends EUC_JP.Decoder {
>> >>> >^
>> >>> > /nb/rs6000_64/nightly/output-jdk-
>> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85:
>> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
>> >>> > outside package
>> >>> > private static class Encoder extends EUC_JP.Encoder {
>> >>> >
>> >>> > Best regards, Matthias
>> >>> >
>> >>> >
>> >>> >
>> >>> >> -Original Message-
>> >>> >> From: ppc-aix-port-dev 
>> On
>> >>> >> Behalf Of Ichiroh Takiguchi
>> >>> >> Sent: Dienstag, 15. Januar 2019 01:51
>> >>> >> To: Alan Bateman 
>> >>> >> Cc: build-dev ; ppc-aix-port-dev > >>> >> port-...@openjdk.java.net>; core-libs-dev@openjdk.java.net
>> >>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default
>> >>> >> charset
>> >>> >>
>> >>> >> Hello Alan.
>> >>> >>
>> >>> >> Could you review the fix again ?
>> >>> >>
>> >>> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8214533
>> >>> >

RE: JDK-8217880 AIX build issue about JDK-8214533

[Lindenmaier, Goetz]

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 build issue about JDK-8214533
> 
> 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 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>; core-libs-dev@openjdk.java.net; Baesken,
> >> Matthias
> >> 
> >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533
> >>
> >> 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: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/
> >>
> >> Could you review the fix ?
> >>
> >> Thanks,
> >> Ichiroh Takiguchi
> >> IBM Japan, Ltd.
> >>
> >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote:
> >> > Hello Goetz.
> >> >
> >> > Thank you for your suggestion.
> >> > I just open JDK-8217880 [1].
> >> >
> >> > I just restart clean build.
> >> >
> >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open.
> >> >
> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880
> >> >
> >> > Thanks,
> >> > Ichiroh Takiguchi
> >> >
> >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote:
> >> >> Hi Ichiroh,
> >> >>
> >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for
> >> >> it.
> >> >> I assume the fix is quite trivial so we can review it quick.
> >> >>
> >> >> Best regards,
> >> >>   Goetz.
> >> >>
> >> >>> -Original Message-
> >> >>> From: ppc-aix-port-dev 
> On
> >> >>> Behalf Of Ichiroh Takiguchi
> >> >>> Sent: Montag, 28. Januar 2019 14:13
> >> >>> To: Baesken, Matthias 
> >> >>> Cc: build-dev ; ppc-aix-port-dev
> >> >>>  >> >>> d...@openjdk.java.net>; core-libs-dev@openjdk.java.net; Alan Bateman
> >> >>> 
> >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default
> >> >>> charset
> >> >>>
> >> >>> Hello.
> >> >>>
> >> >>> I'm very sorry. It's my fault.
> >> >>> EUC_JP class was moved to java.base module.
> >> >>> (sun.nio.cs.EUC_JP).
> >> >>>
> >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and
> >> >>> EUC_JP_Open.
> >> >>>
> >> >>> Could you suggest me how I should provide new webrev files ?
> >> >>>
> >> >>> Thanks,
> >> >>> Ichiroh Takiguchi
> >> >>>
> >> >>>
> >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote:
> >> >>> > Hello,   seems  8214533   got pushed  recently  into  jdk/jdk.   Now
> >> >>> > we see build errors on AIX  ,  are they related to  this change ?
> >> >>> >
> >> >>> >
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>>
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
> >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
> >> >>> > outside package
> >> >>> > private static class Decoder extends EUC_JP.Decoder {
> >> >>> >^
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>>
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69:
> >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
> >> >>> > outside package
> >> >>> > private static class Encoder extends EUC_JP.Encoder {
> >> >>> >^
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65:
> >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
> >> >>> > outside package
> >> >>> > private static class Decoder extends EUC_JP.Decoder {
> >> >>> >^
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85:
> >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
> >> >>> > outside package
> >> >>> > private static class Encoder extends EUC_JP.Encoder {
> >> >>> >
> >> >>> > Best regards, Matthias
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >> -Original Message-
> >> >>> >> From: ppc-aix-port-dev  boun...@openjdk.java.net>
> >> On
> >> >>> >> Behalf Of Ichiroh Takiguchi
> >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51
> >> >>> >> To: Alan Bateman 
> >> >>> >> Cc: build-dev ; ppc-aix-port-dev  aix-
> >> >>> >> port-...@openjdk.java.net>; core-libs-dev@openjdk.java.net
> >> >>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX defa

RE: JDK-8217880 AIX build issue about JDK-8214533

[Baesken, Matthias]

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; Baesken,
> Matthias 
> Subject: RE: JDK-8217880 AIX build issue about JDK-8214533
> 
> 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 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>; core-libs-dev@openjdk.java.net; Baesken,
> >> Matthias
> >> 
> >> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533
> >>
> >> 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: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/
> >>
> >> Could you review the fix ?
> >>
> >> Thanks,
> >> Ichiroh Takiguchi
> >> IBM Japan, Ltd.
> >>
> >> On 2019-01-28 22:49, Ichiroh Takiguchi wrote:
> >> > Hello Goetz.
> >> >
> >> > Thank you for your suggestion.
> >> > I just open JDK-8217880 [1].
> >> >
> >> > I just restart clean build.
> >> >
> >> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open.
> >> >
> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880
> >> >
> >> > Thanks,
> >> > Ichiroh Takiguchi
> >> >
> >> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote:
> >> >> Hi Ichiroh,
> >> >>
> >> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for
> >> >> it.
> >> >> I assume the fix is quite trivial so we can review it quick.
> >> >>
> >> >> Best regards,
> >> >>   Goetz.
> >> >>
> >> >>> -Original Message-
> >> >>> From: ppc-aix-port-dev  boun...@openjdk.java.net> On
> >> >>> Behalf Of Ichiroh Takiguchi
> >> >>> Sent: Montag, 28. Januar 2019 14:13
> >> >>> To: Baesken, Matthias 
> >> >>> Cc: build-dev ; ppc-aix-port-dev
> >> >>>  >> >>> d...@openjdk.java.net>; core-libs-dev@openjdk.java.net; Alan
> Bateman
> >> >>> 
> >> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default
> >> >>> charset
> >> >>>
> >> >>> Hello.
> >> >>>
> >> >>> I'm very sorry. It's my fault.
> >> >>> EUC_JP class was moved to java.base module.
> >> >>> (sun.nio.cs.EUC_JP).
> >> >>>
> >> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX
> and
> >> >>> EUC_JP_Open.
> >> >>>
> >> >>> Could you suggest me how I should provide new webrev files ?
> >> >>>
> >> >>> Thanks,
> >> >>> Ichiroh Takiguchi
> >> >>>
> >> >>>
> >> >>> On 2019-01-28 17:03, Baesken, Matthias wrote:
> >> >>> > Hello,   seems  8214533   got pushed  recently  into  jdk/jdk.   Now
> >> >>> > we see build errors on AIX  ,  are they related to  this change ?
> >> >>> >
> >> >>> >
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>>
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
> >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
> >> >>> > outside package
> >> >>> > private static class Decoder extends EUC_JP.Decoder {
> >> >>> >^
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>>
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69:
> >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
> >> >>> > outside package
> >> >>> > private static class Encoder extends EUC_JP.Encoder {
> >> >>> >^
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>>
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65:
> >> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
> >> >>> > outside package
> >> >>> > private static class Decoder extends EUC_JP.Decoder {
> >> >>> >^
> >> >>> > /nb/rs6000_64/nightly/output-jdk-
> >> >>>
> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85:
> >> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
> >> >>> > outside package
> >> >>> > private static class Encoder extends EUC_JP.Encoder {
> >> >>> >
> >> >>> > Best regards, Matthias
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >> -Original Message-
> >> >>> >> From: ppc-aix-port-dev  boun...@openjdk.java.net>
> >> On
> >> >>> >> Behalf Of Ichiroh Takiguchi
> >> >>> >> Sent: Dienstag, 15. Januar 2019 01:51
> >> >>> >> To: Alan Bateman 
> >> >>> >> Cc: build-dev ; ppc-aix-port-dev
>  >> >>> >> port-...@openjdk.java.net>; core-libs-dev@openjdk.java.ne

Re: RFR: JDK-8217880 AIX build issue about JDK-8214533

[Magnus Ihse Bursie]

> 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: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/

LGTM. 

/Magnus

> 
> Could you review the fix ?
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
>> On 2019-01-28 22:49, Ichiroh Takiguchi wrote:
>> Hello Goetz.
>> Thank you for your suggestion.
>> I just open JDK-8217880 [1].
>> I just restart clean build.
>> I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open.
>> [1] https://bugs.openjdk.java.net/browse/JDK-8217880
>> Thanks,
>> Ichiroh Takiguchi
>>> On 2019-01-28 22:11, Lindenmaier, Goetz wrote:
>>> Hi Ichiroh,
>>> just open a bug, like "Fix aix build after 8214533" and post a RFR for it.
>>> I assume the fix is quite trivial so we can review it quick.
>>> Best regards,
>>>  Goetz.
 -Original Message-
 From: ppc-aix-port-dev  On
 Behalf Of Ichiroh Takiguchi
 Sent: Montag, 28. Januar 2019 14:13
 To: Baesken, Matthias 
 Cc: build-dev ; ppc-aix-port-dev >>> d...@openjdk.java.net>; core-libs-dev@openjdk.java.net; Alan Bateman
 
 Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default charset
 Hello.
 I'm very sorry. It's my fault.
 EUC_JP class was moved to java.base module.
 (sun.nio.cs.EUC_JP).
 make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and
 EUC_JP_Open.
 Could you suggest me how I should provide new webrev files ?
 Thanks,
 Ichiroh Takiguchi
 On 2019-01-28 17:03, Baesken, Matthias wrote:
 > Hello,   seems  8214533   got pushed  recently  into  jdk/jdk.   Now
 > we see build errors on AIX  ,  are they related to  this change ?
 >
 >
 > /nb/rs6000_64/nightly/output-jdk-
 test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
 > error: Decoder is not public in EUC_JP; cannot be accessed from
 > outside package
 > private static class Decoder extends EUC_JP.Decoder {
 >^
 > /nb/rs6000_64/nightly/output-jdk-
 test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69:
 > error: Encoder is not public in EUC_JP; cannot be accessed from
 > outside package
 > private static class Encoder extends EUC_JP.Encoder {
 >^
 > /nb/rs6000_64/nightly/output-jdk-
 test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65:
 > error: Decoder is not public in EUC_JP; cannot be accessed from
 > outside package
 > private static class Decoder extends EUC_JP.Decoder {
 >^
 > /nb/rs6000_64/nightly/output-jdk-
 test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85:
 > error: Encoder is not public in EUC_JP; cannot be accessed from
 > outside package
 > private static class Encoder extends EUC_JP.Encoder {
 >
 > Best regards, Matthias
 >
 >
 >
 >> -Original Message-
 >> From: ppc-aix-port-dev  On
 >> Behalf Of Ichiroh Takiguchi
 >> Sent: Dienstag, 15. Januar 2019 01:51
 >> To: Alan Bateman 
 >> Cc: build-dev ; ppc-aix-port-dev >>> >> port-...@openjdk.java.net>; core-libs-dev@openjdk.java.net
 >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default
 >> charset
 >>
 >> Hello Alan.
 >>
 >> Could you review the fix again ?
 >>
 >> Bug:https://bugs.openjdk.java.net/browse/JDK-8214533
 >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/
 >>
 >> I added IBM29626C charset as standard way.
 >> Please give any suggestion and question.
 >>
 >> Thanks,
 >> Ichiroh Takiguchi
 >> IBM Japan, Ltd.
 >>
 >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote:
 >> > Hello Alan.
 >> >
 >> > I opened JDK-8215333 for Charset filtering issue [1].
 >> > I cannot wait until JDK-8215333 is closed.
 >> > Is it possible to put IBM-29626C charset with standard way ?
 >> >
 >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333
 >> >
 >> > Thanks,
 >> > Ichiroh Takiguchi
 >> >
 >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote:
 >> >> Hello Roger, Magnus and Alan.
 >> >> I may need to put alias information into charsets file.
 >> >> stdcs-xxx cannot handle this information...
 >> >>
 >> >> Still AIX needs IBM-29626C charset for default encoding...
 >> >>
 >> >> I appreciate if you give me further suggestions.
 >> >>
 >> >> Thanks,
 >> >> Ichiroh Takiguchi
 >> >>
 >> >> On 2018-12-10 20:50, Alan Bateman wrote:
 >> >>> On 10/12/2018 11:01, Magnus Ihse Bursie wrote:
 >>  On 2018-12-07 21:20, Roger Riggs wrote:
>>>

Re: [13] RFR: 8217609: New era placeholder not recognized by java.text.SimpleDateFormat

[Nishit Jain]

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/

Although the behavior described in the issue is the expected one 
(i.e., CLDR currently does not provide names for the new era), 
supplementing the name in the CLDR data is desirable from the user's 
point of view.


Naoto

RE: JDK-8217880 AIX build issue about JDK-8214533

[Ichiroh Takiguchi]

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 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>; core-libs-dev@openjdk.java.net; Baesken, 
Matthias


Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533

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: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/

Could you review the fix ?

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2019-01-28 22:49, Ichiroh Takiguchi wrote:
> Hello Goetz.
>
> Thank you for your suggestion.
> I just open JDK-8217880 [1].
>
> I just restart clean build.
>
> I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8217880
>
> Thanks,
> Ichiroh Takiguchi
>
> On 2019-01-28 22:11, Lindenmaier, Goetz wrote:
>> Hi Ichiroh,
>>
>> just open a bug, like "Fix aix build after 8214533" and post a RFR for
>> it.
>> I assume the fix is quite trivial so we can review it quick.
>>
>> Best regards,
>>   Goetz.
>>
>>> -Original Message-
>>> From: ppc-aix-port-dev  On
>>> Behalf Of Ichiroh Takiguchi
>>> Sent: Montag, 28. Januar 2019 14:13
>>> To: Baesken, Matthias 
>>> Cc: build-dev ; ppc-aix-port-dev
>>> >> d...@openjdk.java.net>; core-libs-dev@openjdk.java.net; Alan Bateman
>>> 
>>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default
>>> charset
>>>
>>> Hello.
>>>
>>> I'm very sorry. It's my fault.
>>> EUC_JP class was moved to java.base module.
>>> (sun.nio.cs.EUC_JP).
>>>
>>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and
>>> EUC_JP_Open.
>>>
>>> Could you suggest me how I should provide new webrev files ?
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>>
>>>
>>> On 2019-01-28 17:03, Baesken, Matthias wrote:
>>> > Hello,   seems  8214533   got pushed  recently  into  jdk/jdk.   Now
>>> > we see build errors on AIX  ,  are they related to  this change ?
>>> >
>>> >
>>> > /nb/rs6000_64/nightly/output-jdk-
>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
>>> > error: Decoder is not public in EUC_JP; cannot be accessed from
>>> > outside package
>>> > private static class Decoder extends EUC_JP.Decoder {
>>> >^
>>> > /nb/rs6000_64/nightly/output-jdk-
>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69:
>>> > error: Encoder is not public in EUC_JP; cannot be accessed from
>>> > outside package
>>> > private static class Encoder extends EUC_JP.Encoder {
>>> >^
>>> > /nb/rs6000_64/nightly/output-jdk-
>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65:
>>> > error: Decoder is not public in EUC_JP; cannot be accessed from
>>> > outside package
>>> > private static class Decoder extends EUC_JP.Decoder {
>>> >^
>>> > /nb/rs6000_64/nightly/output-jdk-
>>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85:
>>> > error: Encoder is not public in EUC_JP; cannot be accessed from
>>> > outside package
>>> > private static class Encoder extends EUC_JP.Encoder {
>>> >
>>> > Best regards, Matthias
>>> >
>>> >
>>> >
>>> >> -Original Message-
>>> >> From: ppc-aix-port-dev 
On
>>> >> Behalf Of Ichiroh Takiguchi
>>> >> Sent: Dienstag, 15. Januar 2019 01:51
>>> >> To: Alan Bateman 
>>> >> Cc: build-dev ; ppc-aix-port-dev >> >> port-...@openjdk.java.net>; core-libs-dev@openjdk.java.net
>>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default
>>> >> charset
>>> >>
>>> >> Hello Alan.
>>> >>
>>> >> Could you review the fix again ?
>>> >>
>>> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8214533
>>> >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/
>>> >>
>>> >> I added IBM29626C charset as standard way.
>>> >> Please give any suggestion and question.
>>> >>
>>> >> Thanks,
>>> >> Ichiroh Takiguchi
>>> >> IBM Japan, Ltd.
>>> >>
>>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote:
>>> >> > Hello Alan.
>>> >> >
>>> >> > I opened JDK-8215333 for Charset filtering issue [1].
>>> >> > I cannot wait until JDK-8215333 is closed.
>>> >> > Is it possible to put IBM-29626C charset with standard way ?
>>> >> >
>>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333
>>> >> >
>>> >> > Thanks,
>>> >> > Ichiroh Takiguchi
>>> >> >
>>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote:
>>> >> >> Hello Roger, Magnus and Alan.
>>> >> >> I may need to put alias information into charsets file.
>>> >> >> stdcs-xxx cannot

RE: JDK-8217880 AIX build issue about JDK-8214533

[Lindenmaier, Goetz]

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>; core-libs-dev@openjdk.java.net; Baesken, Matthias
> 
> Subject: RFR: JDK-8217880 AIX build issue about JDK-8214533
> 
> 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: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/
> 
> Could you review the fix ?
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2019-01-28 22:49, Ichiroh Takiguchi wrote:
> > Hello Goetz.
> >
> > Thank you for your suggestion.
> > I just open JDK-8217880 [1].
> >
> > I just restart clean build.
> >
> > I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open.
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8217880
> >
> > Thanks,
> > Ichiroh Takiguchi
> >
> > On 2019-01-28 22:11, Lindenmaier, Goetz wrote:
> >> Hi Ichiroh,
> >>
> >> just open a bug, like "Fix aix build after 8214533" and post a RFR for
> >> it.
> >> I assume the fix is quite trivial so we can review it quick.
> >>
> >> Best regards,
> >>   Goetz.
> >>
> >>> -Original Message-
> >>> From: ppc-aix-port-dev  On
> >>> Behalf Of Ichiroh Takiguchi
> >>> Sent: Montag, 28. Januar 2019 14:13
> >>> To: Baesken, Matthias 
> >>> Cc: build-dev ; ppc-aix-port-dev
> >>>  >>> d...@openjdk.java.net>; core-libs-dev@openjdk.java.net; Alan Bateman
> >>> 
> >>> Subject: RE: RFR: 8214533 IBM-29626C is required for AIX default
> >>> charset
> >>>
> >>> Hello.
> >>>
> >>> I'm very sorry. It's my fault.
> >>> EUC_JP class was moved to java.base module.
> >>> (sun.nio.cs.EUC_JP).
> >>>
> >>> make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and
> >>> EUC_JP_Open.
> >>>
> >>> Could you suggest me how I should provide new webrev files ?
> >>>
> >>> Thanks,
> >>> Ichiroh Takiguchi
> >>>
> >>>
> >>> On 2019-01-28 17:03, Baesken, Matthias wrote:
> >>> > Hello,   seems  8214533   got pushed  recently  into  jdk/jdk.   Now
> >>> > we see build errors on AIX  ,  are they related to  this change ?
> >>> >
> >>> >
> >>> > /nb/rs6000_64/nightly/output-jdk-
> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63:
> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
> >>> > outside package
> >>> > private static class Decoder extends EUC_JP.Decoder {
> >>> >^
> >>> > /nb/rs6000_64/nightly/output-jdk-
> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:69:
> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
> >>> > outside package
> >>> > private static class Encoder extends EUC_JP.Encoder {
> >>> >^
> >>> > /nb/rs6000_64/nightly/output-jdk-
> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:65:
> >>> > error: Decoder is not public in EUC_JP; cannot be accessed from
> >>> > outside package
> >>> > private static class Decoder extends EUC_JP.Decoder {
> >>> >^
> >>> > /nb/rs6000_64/nightly/output-jdk-
> >>> test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_Open.java:85:
> >>> > error: Encoder is not public in EUC_JP; cannot be accessed from
> >>> > outside package
> >>> > private static class Encoder extends EUC_JP.Encoder {
> >>> >
> >>> > Best regards, Matthias
> >>> >
> >>> >
> >>> >
> >>> >> -Original Message-
> >>> >> From: ppc-aix-port-dev 
> On
> >>> >> Behalf Of Ichiroh Takiguchi
> >>> >> Sent: Dienstag, 15. Januar 2019 01:51
> >>> >> To: Alan Bateman 
> >>> >> Cc: build-dev ; ppc-aix-port-dev  >>> >> port-...@openjdk.java.net>; core-libs-dev@openjdk.java.net
> >>> >> Subject: Re: RFR: 8214533 IBM-29626C is required for AIX default
> >>> >> charset
> >>> >>
> >>> >> Hello Alan.
> >>> >>
> >>> >> Could you review the fix again ?
> >>> >>
> >>> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8214533
> >>> >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/
> >>> >>
> >>> >> I added IBM29626C charset as standard way.
> >>> >> Please give any suggestion and question.
> >>> >>
> >>> >> Thanks,
> >>> >> Ichiroh Takiguchi
> >>> >> IBM Japan, Ltd.
> >>> >>
> >>> >> On 2018-12-14 18:58, Ichiroh Takiguchi wrote:
> >>> >> > Hello Alan.
> >>> >> >
> >>> >> > I opened JDK-8215333 for Charset filtering issue [1].
> >>> >> > I cannot wait until JDK-8215333 is closed.
> >>> >> > Is it possible to put IBM-29626C charset with standard way ?
> >>> >> >
> >>> >> > [1] https://bugs.openjdk.java.net/browse/JDK-8215333
> >>> >> >
> >>> >> > Thanks,
> >>> >> > Ichiroh Takiguchi
> >>> >> >
> >>> >> > On 2018-12-10 21:21, Ichiroh Takiguchi wrote:
> >>> >> >> Hello Roge

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

[Michal Vala]

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 Buchholz wrote:

On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs  wrote:


Hi Martin,

It is also useful and conventional to print the seed of the random
so that if necessary it can be reproduced.



For many years, we've been using ThreadLocalRandom for testing, and that
does not allow setting a seed.

I remain unconvinced that saving a seed has value in the real world.  When
a randomized test fails, running it with sufficient iterations has always
worked for me.



What's the reason behind using ThreadLocalRandom?

In my opinion, reproducing the issue is key. One failure of randomized test 
run might be caused by one issue, second run due to another issue. How we 
reproduce then and how we know even how many issues we have? When we're 
running random tests until it pass, it might even hide the issue.


They sure have good value on reveal the issue, but then we have to know how 
to reproduce and what we're searching for.


If this case would not require ThreadLocalRandom and Random is enough, I'd 
like to use that because of benefits I've mentioned.








--
Michal Vala
OpenJDK QE
Red Hat Czech

RE: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

[Langer, Christoph]

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 Christoph,

Additional changes look OK to me. Happy for for you to push.

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groe...@uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From:"Langer, Christoph" 
mailto:christoph.lan...@sap.com>>
To:Steve Groeger mailto:groe...@uk.ibm.com>>, Roger 
Riggs mailto:roger.ri...@oracle.com>>
Cc:
"core-libs-dev@openjdk.java.net" 
mailto:core-libs-dev@openjdk.java.net>>
Date:28/01/2019 15:49
Subject:RE: JDK-821 TEST_BUG: 
jdk/java/util/prefs/ExportSubtree.java passes even when test should fail




Hi Steve, Roger,

I made some additional cleanups in the test (Declare constants final, 
formatting, nice up error output...)

This is what ran through our test system without issues: 
http://cr.openjdk.java.net/~clanger/webrevs/821.0/

In case there was an error in the output, it would read like this:

--System.out:(39/1030)--
Preferences::exportSubtree did not yield the expected result.
Actual:

http://java.sun.com/dtd/preferences.dtd";>

 
   
   
 
   
 
 
   
 
   
 
   
 


Expected:

http://java.sun.com/dtd/preferences.dtd";>

 
   
   
 
   
 
 
   
 
   
 
   
 
d

Are you all ok with that? Then I'd push it...

Thanks
Christoph


> -Original Message-
> From: core-libs-dev 
> mailto:core-libs-dev-boun...@openjdk.java.net>>
>  On Behalf
> Of Roger Riggs
> Sent: Freitag, 25. Januar 2019 17:52
> To: Steve Groeger mailto:groe...@uk.ibm.com>>
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: JDK-821 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java
> passes even when test should fail
>
> +1,
>
> Thanks, Roger
>
>
> On 01/25/2019 11:21 AM, Steve Groeger wrote:
> > Hi Roger,
> >
> > Thanks. Have included the bug number to the @bug line and have
> > included the expected and actual output when there is an error.
> >
> > Have generated a new webrev here:
> > http://cr.openjdk.java.net/~sgroeger/821/webrev.01/
> > 
> >
> > Hope this is now OK.
> >
> > Thanks
> > Steve Groeger
> > IBM Runtime Technologies
> > Hursley, Winchester
> > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> > Fax (44) 1962 816800
> > Lotus Notes: Steve Groeger/UK/IBM
> > Internet: groe...@uk.ibm.com
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU
> >
> >
> >
> > From: Roger Riggs mailto:roger.ri...@oracle.com>>
> > To: core-libs-dev@openjdk.java.net
> > Date: 25/01/2019 15:30
> > Subject: Re: JDK-821 TEST_BUG:
> > jdk/java/util/prefs/ExportSubtree.java passes even when test should fail
> > Sent by: "core-libs-dev" 
> > mailto:core-libs-dev-boun...@openjdk.java.net>>
> > 
> >
> >
> >
> > Hi Steve,
> >
> > Add 821 to the @bug line; it helps track and run tests that fixed
> > bugs  (jtreg -bug:821)
> >
> > +1 printing the expected and actual (when a failure occurs).
> >
> > Looks fine overall.
> >
> > Thanks, Roger
> >
> >
> >
> > On 01/25/2019 09:57 AM, Steve Groeger wrote:
> > > Hi Christoph,
> > >
> > > Thanks for looking at this.
> > >
> > > These lines
> > >
> > > 43   //System.out.print(baos.toString());
> > > 44   //System.out.print(expectedResult);
> > >
> > > were commented out in the current code but if you think displaying this
> > > info would be good then I can un-comment them.
> > >
> > > I think only fixing this in the jdk (JDK13) branch is OK.
> > > If it is later determined that this is really needed in jdk12 or
> > jdk11u ,
> > > then I can always request a backport.
> > >
> > > Thanks
> > > Steve Groeger
> > > IBM Runtime Technologies
> > > Hursley, Winchester
> > > Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> > > Fax (44) 1962 816800
> > > Lotus Notes: Steve Groeger/UK/IBM
> > > Internet: groe...@uk.ibm.com
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - R

RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

[Langer, Christoph]

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 Alan's suggestion to open a follow up bug to explore using 
CreateFile on Windows right away rather than trying open. Looking at 
libjava/libnet/libnio, it's all CreateFileW on Windows...

Best regards
Christoph

Re: Duplicate words typos in comments/javadoc/strings

[David Holmes]

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 full process is described here [2].
If you have signed the OCA, I can sponsor that change for you.


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]


Cheers,
David
-

[1] http://openjdk.java.net/bylaws#participant


P.S. While we are here. I had a script once that was looking for the same
pattern of typos, namely repeated words. Usually it happens just after the line
break. As if people loose a visual context after hitting the Enter key. Would
you mind accepting additional typos into your patch?


[1] https://www.oracle.com/technetwork/oca-405177.pdf
[2] https://openjdk.java.net/contribute/

RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system

[Lindenmaier, Goetz]

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 zip file is located in a custom file system
> 
> Hi Goetz,
> 
> > Patching the file myself really helped to see there are no real changes.
> >
> > For the missing patch of the constructor I understand it was only an 
> > arbitrary
> > reordering of arguments you omitted. Thus the whole chunk disappeared.
> > This makes sense, and in case someone downports the other change he
> > should be able to cope with that.
> 
> Well, there were actually 3 failing hunks:
> 
> --- ZipFileSystem.java
> +++ ZipFileSystem.java
> @@ -316,8 +326,8 @@
>  IndexNode inode = getInode(path);
>  if (inode == null)
>  return null;
> -e = new Entry(inode.name, inode.isdir);  // pseudo directory
> -e.method = METHOD_STORED;// STORED for dir
> +// pseudo directory, uses METHOD_STORED
> +e = new Entry(inode.name, inode.isdir, METHOD_STORED);
>  e.mtime = e.atime = e.ctime = zfsDefaultTimeStamp;
>  }
>  } finally {
> 
> This one just had to find its place -> it is included in my change (line 329 
> of new
> file).
> 
> @@ -1087,8 +1061,9 @@
>  if (pos + CENHDR + nlen > limit) {
>  zerror("invalid CEN header (bad header size)");
>  }
> -IndexNode inode = new IndexNode(cen, nlen, pos);
> +IndexNode inode = new IndexNode(cen, pos, nlen);
>  inodes.put(inode, inode);
> +
>  // skip ext and comment
>  pos += (CENHDR + nlen + elen + clen);
>  }
> 
> This one was the reordering of arguments when calling the "IndexNode"
> constructor itself.
> 
> @@ -1806,7 +1777,7 @@
>  }
> 
>  // constructor for cenInit() (1) remove tailing '/' (2) pad leading 
> '/'
> -IndexNode(byte[] cen, int nlen, int pos) {
> +IndexNode(byte[] cen, int pos, int nlen) {
>  int noff = pos + CENHDR;
>  if (cen[noff + nlen - 1] == '/') {
>  isdir = true;
> 
> This one was the reordering of arguments of the "IndexNode" constructor
> itself.
> 
> I think it's better to also take over the reordering of arguments of the
> constructor. Here's an updated webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8034802.11u.1/
> 
> The updates are in line 1054 and 1770 of the new ZipFileSystem.java.
> 
> Best regards
> Christoh