Re: Optimized version of CopiesList.hashCode()

[Zheka Kozlov]

I think we should choose Tagir's version so you don't need my OCA.

сб, 1 дек. 2018 г. в 06:38, Stuart Marks :

>
>
> On 11/30/18 8:52 AM, Martin Buchholz wrote:
> > On Thu, Nov 29, 2018 at 8:02 PM, Tagir Valeev  wrote:
> >
> >> I can file an issue and create a webrev, but I still need a sponsor
> >> and review for such change. Martin, can you help with this?
> >
> > As usual, I'm only half paying attention, but I can be your shepherd.
>
> (I'm still digging out from my backlog. Perhaps Martin and I are competing
> for
> who has less time)
>
> A quick process check: are the proper OCAs in place? [1]
>
> If Zheka is authoring, he'll need to have signed the OCA. (Or he'll need
> to be
> doing this work on behalf of a company or organization that has signed the
> OCA.)
>
> If Tagir is authoring, he's good, since he's already signed the OCA.
>
> Zheka, even if you're not authoring this changeset, if you intend to
> contribute
> to OpenJDK in the future, you might want to work on an OCA. It's not a
> gigantic
> bit of bureaucracy, but it does take a few days, and you'll probably want
> to
> avoid lack of an OCA blocking a future contribution.
>
> Otherwise, thanks and carry on.
>
> s'marks
>
>
>
>
> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>

Re: Optimized version of CopiesList.hashCode()

[Stuart Marks]

On 11/30/18 8:52 AM, Martin Buchholz wrote:

On Thu, Nov 29, 2018 at 8:02 PM, Tagir Valeev  wrote:


I can file an issue and create a webrev, but I still need a sponsor
and review for such change. Martin, can you help with this?


As usual, I'm only half paying attention, but I can be your shepherd.


(I'm still digging out from my backlog. Perhaps Martin and I are competing for 
who has less time)


A quick process check: are the proper OCAs in place? [1]

If Zheka is authoring, he'll need to have signed the OCA. (Or he'll need to be 
doing this work on behalf of a company or organization that has signed the OCA.)


If Tagir is authoring, he's good, since he's already signed the OCA.

Zheka, even if you're not authoring this changeset, if you intend to contribute 
to OpenJDK in the future, you might want to work on an OCA. It's not a gigantic 
bit of bureaucracy, but it does take a few days, and you'll probably want to 
avoid lack of an OCA blocking a future contribution.


Otherwise, thanks and carry on.

s'marks




[1] https://www.oracle.com/technetwork/community/oca-486395.html

Re: RFR: 8212703: Remove sun.java2d.fontpath property from java launcher code

[Roger Riggs]

Hi Phil,

That looks fine.

Too bad it introduces a new shell test, we're trying to get rid of them.
The other alternative would have the test program needed to set the 
environment

and launch a java program.

Thanks, Roger


On 11/30/2018 05:56 PM, Phil Race wrote:

Bug : https://bugs.openjdk.java.net/browse/JDK-8212703
Webrev : http://cr.openjdk.java.net/~prr/8212703/

This removes the code in the launcher that sets the 
sun.java2d.fontpath property

from the JAVA2D_FONTPATH environment variable.

We can still set the system property directly when using for debugging 
but

that is all now internal to the java.desktop module.

-phil.

RFR: 8212703: Remove sun.java2d.fontpath property from java launcher code

[Phil Race]

Bug : https://bugs.openjdk.java.net/browse/JDK-8212703
Webrev : http://cr.openjdk.java.net/~prr/8212703/

This removes the code in the launcher that sets the sun.java2d.fontpath 
property

from the JAVA2D_FONTPATH environment variable.

We can still set the system property directly when using for debugging but
that is all now internal to the java.desktop module.

-phil.

Re: RFR - JDK-8203442 String::transform (Code Review)

[Remi Forax]

I fully agree with Stephen.

Rémi

- Mail original -
> De: "Stephen Colebourne" 
> À: "core-libs-dev" 
> Envoyé: Vendredi 30 Novembre 2018 12:06:23
> Objet: Re: RFR - JDK-8203442 String::transform (Code Review)

> I see from Twitter (!!!) that this has been pushed. This appears to have
> happened without this thread coming to a clear conclusion, particularly wrt
> criticism of transform() as a suitable method name in the broader context.
> 
> I also do not think that the code review was completed correctly and in
> public, which I find concerning.
> 
> The two public threads are:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056574.html
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056592.html
> 
> The last webrev had the name map() and no further webrev was published that
> I can see. I can see no explicit public approvals of the change from
> reviewers. And plenty of concern about the method name, especially map()
> but also transform().
> 
> While I'm well aware of the danger of public bikeshedding, I also think
> that adding methods to `String` deserves more care than this has been
> shown. In my view the change should be reverted, and retargetted to Java 13
> to allow for a proper conclusion to the discussion.
> 
> For info, AWS SDK v2 has chosen applyMutation() for a similar concept:
> https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/utils/builder/SdkBuilder.html#applyMutation-java.util.function.Consumer-
> 
> Stephen
> 
> 
> On Wed, 14 Nov 2018, 14:18 Stephen Colebourne  
>> On Tue, 13 Nov 2018 at 15:44, Brian Goetz  wrote:
>> > Yes, we know :)  But we don’t have any current plans to do that, nor
>> use-site extension methods, nor does it seem likely to come to the top of
>> the language priority list very soon.  So its not a choice between |> and
>> .transform(); it’s a choice between transform() and nothing.  Picking
>> transform() seems pretty good here.
>> >
>> > Stephen raised the issue of a “broader context”; indeed, the intention
>> of adding a transform() method here was that it would be feasible to add to
>> other types for which it was suitable.  String is an obvious candidate for
>> “do it first”, but this is within a broader context.
>>
>> I'd be more comforted if there was a commitment to add the method to
>> Stream and Optional in Java 12 or 13.
>>
>> I also agree with Remi that `transform()` is a poor name for Stream,
>> and thus it is a poor name for String. I doubt there is a perfect
>> name, process() or apply() seem like good candidates.
>>
>> Stephen

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

[Henry Jen]

Thanks for the review, Alan and Magnus.

Cheers,
Henry

> On Nov 30, 2018, at 7:20 AM, Alan Bateman  wrote:
> 
> 
> 
> On 28/11/2018 22:49, Henry Jen wrote:
>> Since there is no header file in JDK provides the function prototypes, I 
>> don’t think this is considered public(supported) APIs.
>> 
>> Anyway, in case a tools is build with launcher code, and shipped separately 
>> from JDK, that would be impacted by this bug. So I added a test call 
>> JLI_Launch as well. Please review the updated webrev[1].
>> 
>> Note that, JLI_Launch should not be used directly as it does’t handle the 
>> argument processing which is done in launcher/main.c.
>> 
>> Cheers,
>> Henry
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/jdk12/8213362.1/webrev/
>> 
> Updated webrev looks okay. I do find the exeXXX convention for the launchers 
> created in the test make files very strange but this is something we can 
> chase up with another issue.
> 
> -Alan

Re: CSR for posix_spawn on JDK 12

[Roger Riggs]

Hi Thomas,

On 11/30/2018 02:06 PM, Thomas Stüfe wrote:

Hi Roger,

I updated the CSR according to your feedback. I'm a bit at a loss
about the specification though. How should I specify the behavior of
the API without describing the implementation?

What you wrote is fine. It does need to mention posix_spawn by name,
as that is the OS function being used.

The notes about the behavior of libc, fit better as an explanation
in the description of the Solution than in the Specification section.



Also, since this patch only extends an existing implementation to
Linux, I would have thought there are there technical notes in place
describing POSIX_SPAWN on other platforms, which I would have just
refered to. I searched but could not really find anything.

Nope, that's why it was a debugging tool for Martin,
not a documented implementation feature.

I'm not sure what the proper plural of Unix's is but Unices looks odd.
Perhaps avoid the issue and just say Unix platforms.

Thanks, Roger



Thanks, Thomas


On Fri, Nov 30, 2018 at 3:50 PM Roger Riggs  wrote:

Hi Thomas,

Looks pretty good.

Usually 'we' avoid the first person writing in the jira.
It makes them more readable in the long term, when there is no context for 'we'.

- Describing it as 'experimental' gives the wrong impression
and has some magnified implications as that term is being used for
other major changes.

- The compatibility risk should be corrected:

Supplying an unknown value on the command line produces a java.lang.Error.

% java -Djdk.lang.Process.launchMechanism=POSIX_SPAWN ...

java.lang.Error: POSIX_SPAWN is not a supported process launch mechanism on 
this platform.

- Since CSRs should be self contained, the specification section should 
explicitly
specify the behavior from the API point of view. CSRs should avoid describing
the implementation (though in this case, its not entirely possible).
The webrev of the impl is not relevant.

Thanks, Roger


On 11/30/2018 03:32 AM, Thomas Stüfe wrote:

CSR for jdk12: https://bugs.openjdk.java.net/browse/JDK-8214511

..Thomas

Re: RFR: 8214552: Resolve clash between 4947890 and 8130266

[Phil Race]

On 11/30/18 11:54 AM, Roger Riggs wrote:

Hi Phil,

The patch looks fine.


Ok, thanks.



Where does it die?  SystemProps should skip null values in putIfAbsent().


You are right it checks and that explains why I didn't see it when I tested.
I saw the NPE only after I noticed the code and it seems was just from 
my debugging I

quickly added since System.out is likely not defined at this point ...

Anyway we still need this fix.

Thanks,

-phil.



Sorry for the turbulence.

Roger



On 11/30/2018 02:43 PM, Phil Race wrote:

Roger,

I just pushed 8130266 which had the CSR approved a couple of days ago 
only
to find that it clashed badly with the change you made in 4947890 to 
reduce

the cost of system property initialisation.
It appears that the new code there is not happy if there is no value 
for the

system property.

I think java.awt.printerjob just needs to be removed from the new code :

If this looks right to you I need to push ASAP :

Bug: https://bugs.openjdk.java.net/browse/JDK-8214552
Webrev: http://cr.openjdk.java.net/~prr/8214552/

Separately I think the SystemProps code ought to consider whether
it ought to error out the launcher if a property is not defined ..

-phil.

Re: RFR: 8214552: Resolve clash between 4947890 and 8130266

[Mandy Chung]

On 11/30/18 11:56 AM, Phil Race wrote:

Sorry, but its actually  8130264 that I meant

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



I see it now.  System.c has been updated.

Your patch looks good.


Separately I think the SystemProps code ought to consider whether
it ought to error out the launcher if a property is not defined ..


If not set, it should not set the system property.

Mandy

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

[Brian Burkhalter]

Loathe though I am to resurrect this thread, one problem arose after testing 
with assertions enabled which I had neglected previously to do. A few small 
changes to test/jdk/java/io/InputStream/Skip.java are required. A delta versus 
webrev.08 (link at bottom) is at

http://cr.openjdk.java.net/~bpb/6516099/webrev.08-delta/

The changes are as follows (line numbers in the new version):

1. L154

 in.setState(-1, 100);
-dotestExact(in, pos, streamLength, n, true, false);
+dotestExact(in, pos, streamLength, -1, true, false);

Pass “-1” as the number to skip instead of “n.”

2. L159

 in.setState(n + 1, 100);
 dotestExact(in, pos, streamLength, n, true, false);
+pos += n + 1;

Update the test-tracked position according to the number actually skipped, 
which is “n + 1” although only “n” bytes were requested. This sub-test causes 
the internal call to “skip()” to be “skip(n+1)” which will return “n+1” which 
intentionally provokes an IOException and leaves the stream in an inconsistent 
state as documented. The call to “skip(n+1)” does however really skip “n+1” 
bytes so the test-tracked position must be updated accordingly.

3. L214

-public long position() { return readctr == endoffile ? EOF : readctr; }
+public long position() { return readctr; }

The position should be returning the actual offset which for EOF is the length 
of the stream, not -1.

With the foregoing changes the test passes.

Thanks,

Brian

> On Nov 28, 2018, at 9:51 AM, Daniel Fuchs  wrote:
> 
> Looks good to me Brian.
> 
> I never knew whether positive meant >= 0 or > 0 anyway ;-)
> 
> best regards,
> 
> -- daniel
> 
> On 28/11/2018 17:38, Brian Burkhalter wrote:
>> 
>> http://cr.openjdk.java.net/~bpb/6516099/webrev.08/

Re: RFR: 8214552: Resolve clash between 4947890 and 8130266

[Phil Race]

Sorry, but its actually  8130264 that I meant

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

-phil.

On 11/30/18 11:54 AM, Mandy Chung wrote:



On 11/30/18 11:43 AM, Phil Race wrote:

Roger,

I just pushed 8130266 which had the CSR approved a couple of days ago 
only
to find that it clashed badly with the change you made in 4947890 to 
reduce

the cost of system property initialisation.
It appears that the new code there is not happy if there is no value 
for the

system property.



Is JDK-8214322 the JBS issue but not JDK-8130266?


I think java.awt.printerjob just needs to be removed from the new code :

If this looks right to you I need to push ASAP :

Bug: https://bugs.openjdk.java.net/browse/JDK-8214552
Webrev: http://cr.openjdk.java.net/~prr/8214552/



src/java.base/share/native/libjava/System.c also needs to be updated.

Mandy


Separately I think the SystemProps code ought to consider whether
it ought to error out the launcher if a property is not defined ..

-phil.

Re: RFR: 8214552: Resolve clash between 4947890 and 8130266

[Roger Riggs]

Hi Phil,

The patch looks fine.

Where does it die?  SystemProps should skip null values in putIfAbsent().

Sorry for the turbulence.

Roger



On 11/30/2018 02:43 PM, Phil Race wrote:

Roger,

I just pushed 8130266 which had the CSR approved a couple of days ago 
only
to find that it clashed badly with the change you made in 4947890 to 
reduce

the cost of system property initialisation.
It appears that the new code there is not happy if there is no value 
for the

system property.

I think java.awt.printerjob just needs to be removed from the new code :

If this looks right to you I need to push ASAP :

Bug: https://bugs.openjdk.java.net/browse/JDK-8214552
Webrev: http://cr.openjdk.java.net/~prr/8214552/

Separately I think the SystemProps code ought to consider whether
it ought to error out the launcher if a property is not defined ..

-phil.

Re: RFR: 8214552: Resolve clash between 4947890 and 8130266

[Mandy Chung]

On 11/30/18 11:43 AM, Phil Race wrote:

Roger,

I just pushed 8130266 which had the CSR approved a couple of days ago 
only
to find that it clashed badly with the change you made in 4947890 to 
reduce

the cost of system property initialisation.
It appears that the new code there is not happy if there is no value 
for the

system property.



Is JDK-8214322 the JBS issue but not JDK-8130266?


I think java.awt.printerjob just needs to be removed from the new code :

If this looks right to you I need to push ASAP :

Bug: https://bugs.openjdk.java.net/browse/JDK-8214552
Webrev: http://cr.openjdk.java.net/~prr/8214552/



src/java.base/share/native/libjava/System.c also needs to be updated.

Mandy


Separately I think the SystemProps code ought to consider whether
it ought to error out the launcher if a property is not defined ..

-phil.

Re: RFR - JDK-8210717 String::detab, String::entab (Code Review)

[Dan Smith]

> On Sep 18, 2018, at 11:52 AM, Jim Laskey  wrote:
> 
> Please review the code for String::detab and String::entab. Used to expand 
> tabs into spaces, and spaces back to tabs.
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8210717/webrev/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8210717
> csr: https://bugs.openjdk.java.net/browse/JDK-8210718 
> 

For detab: here's an attempt at a brief formal description of the behavior, if 
it's useful.

"Replace each tab code point (U+0009) in the string with one or more space code 
points (U+0020). The number of spaces that replace a tab varies between 1 and 
{@code tabWidth}, whatever is necessary so that the last replacement space is 
the nth code point of the {@link #lines() line}, where {@code n % 
tabWidth == 0}."

---

For entab: I noticed that something like the following doesn't behave how you'd 
probably expect.

"int x = 23;".entab(4)
--> "\tint\tx =\t23;"

For other strings, the intent is ambiguous (are the first and last name two 
fields, or only one?):

"Dan Smith   daniel.smith".entab(4)
--> "Dan\tSmith\tdaniel.smith"

Seems like there are multiple possible approaches:
- Entab all spaces that align with a tab stop (current behavior)
- Only entab sequences of 2 or more spaces (implies 'tabWidth >= 2')
- Only entab prefix spaces

We can support all of these via different overloads or parameters, or we can 
choose the best one for most use cases. But I don't know that we really have 
pressing use cases—detab is the one that's easy to envision using. It might be 
best to just drop the method unless/until compelling use cases arise.

RFR: 8214552: Resolve clash between 4947890 and 8130266

[Phil Race]

Roger,

I just pushed 8130266 which had the CSR approved a couple of days ago only
to find that it clashed badly with the change you made in 4947890 to reduce
the cost of system property initialisation.
It appears that the new code there is not happy if there is no value for the
system property.

I think java.awt.printerjob just needs to be removed from the new code :

If this looks right to you I need to push ASAP :

Bug: https://bugs.openjdk.java.net/browse/JDK-8214552
Webrev: http://cr.openjdk.java.net/~prr/8214552/

Separately I think the SystemProps code ought to consider whether
it ought to error out the launcher if a property is not defined ..

-phil.

Re: RFR 8177552: Compact Number Formatting support

[Roger Riggs]

Hi Nishit,

Some comments, a couple of possible bugs and several  performance 
related issues

could be deferred. Both formatting and parsing seem to be quite heavyweight
due to looping and combinatorics.


CompactNumberFormat.java


661, 727, 1507: Is there a reason to convert the divisor to a string and 
then re-parse it to create a new BigDecimal?
    (IntelliJ observes that divide is called without a rounding 
argument.)
    Given that the divisors are all powers of 10 and the digit list 
is a base 10 set of digits
    it seems more efficient to just move the decimal point then to 
do the math.
    BTW, the divisor.toString() is preferred over concat with "".  
(looks like a hack).


    It would be more efficient to write two methods that would pass 
the Number
    and return a BigInteger or BigDecimal by dispatching on the 
concrete type and

    using the appropriate constructor.

781:  @param prefix - the parameter name is suffix

804: move the int start = inside the if.

826:  expandAffix can be more efficient if tests the pattern for the 
presence of QUOTE
    and returns the pattern if the QUOTE is not present.  That 
would be the most common case.


914: Reduce the number of compares by reordering to:
    if number > currentValue; multiply and continue
    if number < currentValue break;
    else ==; assign matched index and break;

    In the normal case, there will be only one compare in the loop 
until it is to exit.


1109:  IntelliJ observes that within the case QUOTE, the if (ch == 
QUOTE) is always true

  so the if is redundant.

1205:  It looks odd to prepend two characters '- to the prefix.  Is the 
single quote correct?

  Where's the closing quote if so.

1394: matchedPosPrefix.length() is compared to negativePrefix.length().
  That's an unusual mixing of positive and negative! Please re-check.

1363:  Can there be an early exit from this loop if one of the prefixes 
is identified?
  The pattern of comparing for a prefix/suffix and the length might 
warrant

  creating a private method to reduce the repetitive parts of the code.

1593: extra space between "- ("; should be the same style as 1591

1627, 1363: Is an early exit from this loop possible?
   or a quick comparison to avoid the regionMatches.
   Do the regionMatches *only if* the prefix/suffix is longer than 
the suffix already compared?


1721:  IntelliJ observes that if (gotNeg) is redundant since 1708 rules 
out them being both true or both false.


Thanks, Roger



On 11/28/18 3:46 AM, Nishit Jain wrote:

Thanks Naoto,

Updated.

http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.04/

Re: CSR for posix_spawn on JDK 12

[Thomas Stüfe]

Hi Roger,

I updated the CSR according to your feedback. I'm a bit at a loss
about the specification though. How should I specify the behavior of
the API without describing the implementation?

Also, since this patch only extends an existing implementation to
Linux, I would have thought there are there technical notes in place
describing POSIX_SPAWN on other platforms, which I would have just
refered to. I searched but could not really find anything.

Thanks, Thomas


On Fri, Nov 30, 2018 at 3:50 PM Roger Riggs  wrote:
>
> Hi Thomas,
>
> Looks pretty good.
>
> Usually 'we' avoid the first person writing in the jira.
> It makes them more readable in the long term, when there is no context for 
> 'we'.
>
> - Describing it as 'experimental' gives the wrong impression
> and has some magnified implications as that term is being used for
> other major changes.
>
> - The compatibility risk should be corrected:
>
> Supplying an unknown value on the command line produces a java.lang.Error.
>
> % java -Djdk.lang.Process.launchMechanism=POSIX_SPAWN ...
>
> java.lang.Error: POSIX_SPAWN is not a supported process launch mechanism on 
> this platform.
>
> - Since CSRs should be self contained, the specification section should 
> explicitly
> specify the behavior from the API point of view. CSRs should avoid describing
> the implementation (though in this case, its not entirely possible).
> The webrev of the impl is not relevant.
>
> Thanks, Roger
>
>
> On 11/30/2018 03:32 AM, Thomas Stüfe wrote:
>
> CSR for jdk12: https://bugs.openjdk.java.net/browse/JDK-8214511
>
> ..Thomas
>
>

Re: Optimized version of CopiesList.hashCode()

[Martin Buchholz]

On Thu, Nov 29, 2018 at 8:02 PM, Tagir Valeev  wrote:

>
> I can file an issue and create a webrev, but I still need a sponsor
> and review for such change. Martin, can you help with this?
>

As usual, I'm only half paying attention, but I can be your shepherd.

You're optimizing hashCode to be O(log(N)) instead of O(N)?

Re: 8207404: MulticastSocket tests failing on Aix

[Volker Simonis]

On Fri, Nov 30, 2018 at 12:20 PM Steve Groeger  wrote:
>
> Hi Goetz,
>
> I disabled IPv6 on my xLinux box and the MulticastSocket tests pass, as
> they detected that IPv6 is not enabled and then didnt try and set the IPv6
> options.

Not being a network expert either, I think there's two things to
consider here. It seems that IPv6 can be disabled globally (e.g. in
the Linux kernel) or IPv6 can be enabled globally, but not all network
devices supporting it. A quick search revealed that it seems to be
fairly easy to disable IPv6 on a single interface on Linux while still
having IPv6 globally enabled (see
https://superuser.com/questions/575684/how-to-disable-ipv6-on-a-specific-interface-in-linux).
@Steve Groeger  can you please check if the test still succeeds on
Linux if you only disable IPv6 on the specific interface used by the
test? If it still succeeds, there's probably something to fix on AIX.
If it fails on Linux as well, there may be something to fix in the
test (i.e. to detect that the corresponding interface doesn't support
IPv6) or even in the Java network implementation (i.e. to handle both,
IPv6 and IPv4-only interfaces on an IPv6 enabled system correctly).

Thank you and best regards,
Volker

> I am currently unable to disable IPv6 on my AIX box to test this but would
> assume it would also work as the code checks to see whether IPv6 is
> enabled and doesnt try and set the IPV6 options.
> It seems the issue with the tests failing seems to be, if IPv6 is enabled
> but the interface doesn't have an IPv6 address associated with it, as in
> your case here:
>
> bash-4.3$ ifconfig -a
> en0:
> flags=1e084863,480
> inet 10.xx.xxx.xxx netmask 0xfe00 broadcast 10.xx.xxx.xxx
>  tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
> lo0:
> flags=e08084b,c0
> inet 127.x.x.x netmask 0xff00 broadcast 127.xxx.xxx.xxx
> inet6 ::1%1/0
>  tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
>
> where you can see that the en0 interface has an inet address associated
> but doesnt have an inet6 address associated.
> I can see that IPv6 is enabled as the lo0 interface has an inet6 address
> (pointing to localhost)
>
> As I stated below, my AIX system was configured in a similar way to yours
> and the tests failed. When I was able to add an inet6 address to en0,
> everything works correctly.
> NOTE: Not sure this was correct but I ran 'sudo autoconf6' which seemed to
> add the inet6 address to my en0 interface. After that all tests worked.
>
> So I think the tests are working as expected, but the AIX system is not
> configured correctly, but I would like someone else to confirm this.
>
> 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:   "Lindenmaier, Goetz" 
> To: Steve Groeger , ppc-aix-port-dev
> 
> Date:   30/11/2018 10:18
> Subject:RE: 8207404: MulticastSocket tests failing on Aix
>
>
>
> i Steve,
>
> thanks for looking at this issue.
>
> > Should these tests work without having IPV6 configured on the interface?
> In general, tests should not show errors if a system does not meet
> the requirements for the test. In such cases the test should
> be skipped somehow. Maybe only a test fix is needed.
>
> Can you check on a non-aix machine without ipv6 whether the test
> passes?
>
> > Goetz, do you have IPV6 configured on the machine you were running these
> > tests on?
> This is our test machine:
>
> bash-4.3$ ifconfig -a
> en0:
> flags=1e084863,480
> inet 10.xx.xxx.xxx netmask 0xfe00 broadcast 10.xx.xxx.xxx
>  tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
> lo0:
> flags=e08084b,c0
> inet 127.x.x.x netmask 0xff00 broadcast 127.xxx.xxx.xxx
> inet6 ::1%1/0
>  tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
>
> I think this message should be posted to core-libs-dev, too. That's also
> the list where a potential fix needs to be reviewed.
>
> Best regards,
>   Goetz.
>
>
> > -Original Message-
> > From: Steve Groeger 
> > Sent: Donnerstag, 29. November 2018 17:07
> > To: ppc-aix-port-dev 
> > Cc: Lindenmaier, Goetz 
> > Subject: 8207404: MulticastSocket tests failing on Aix
> >
> > Hi All,
> >
> > I have been having a look at this issue:
> >
> https://bugs.openjdk.java.net/browse/JDK-8207404
>
> > <
> https://bugs.openjdk.java.net/browse/JDK-8207404
> >
> > which was raised by  Goetz Lindenmaier.
> >
> > When I ran the tests on my AIX system I got the same results as Goetz
> listed
> > in the issue.
> >
> > Looking at the failure I noticed that it was failing on a setsockopt
> call in the
> > native code in
> > the 

Re: [12] RFR 8213294: Upgrade IANA LSR data

[naoto . sato]

Looks good. Please add noreg-* keyword to the issue.

Naoto

On 11/29/18 10:14 PM, Nishit Jain wrote:

Hi,

Please review the fix for 8213294, which upgrades the IANA LSR data to 
the latest available version.


Bug: https://bugs.openjdk.java.net/browse/JDK-8213294
Webrev: http://cr.openjdk.java.net/~nishjain/8213294/webrev.00


Regards,
Nishit Jain

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

[Alan Bateman]

On 28/11/2018 22:49, Henry Jen wrote:

Since there is no header file in JDK provides the function prototypes, I don’t 
think this is considered public(supported) APIs.

Anyway, in case a tools is build with launcher code, and shipped separately 
from JDK, that would be impacted by this bug. So I added a test call JLI_Launch 
as well. Please review the updated webrev[1].

Note that, JLI_Launch should not be used directly as it does’t handle the 
argument processing which is done in launcher/main.c.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk12/8213362.1/webrev/

Updated webrev looks okay. I do find the exeXXX convention for the 
launchers created in the test make files very strange but this is 
something we can chase up with another issue.


-Alan

Re: RFR: 8212794 IBM-964 is required for AIX default charset

[Magnus Ihse Bursie]

On 2018-11-30 10:49, Ichiroh Takiguchi wrote:

Hello.

Could you review the fix again ?

Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/

I think it looks good but please let someone from core-libs review it too.

/Magnus


I just fixed only IBM964 for JDK-8212794.
(IBM29626C fix is not included)

On non AIX platform (Linux),
ibm-euctw alias is added for IBM964.

Without fix
$ jshell
|  Welcome to JShell -- Version 12-ea
|  For an introduction type: /help intro

jshell> var cs = java.nio.charset.Charset.forName("IBM964")
cs ==> x-IBM964

jshell> cs.getClass().getName()
$2 ==> "sun.nio.cs.ext.IBM964"

jshell> System.out.println(String.join("\n", cs.aliases()))
ibm-964
cp964
ibm964
964

jshell> /exit
|  Goodbye
$
==

With fix
==
$ jshell
|  Welcome to JShell -- Version 12-internal
|  For an introduction type: /help intro

jshell> var cs = java.nio.charset.Charset.forName("IBM964")
cs ==> x-IBM964

jshell> cs.getClass().getName()
$2 ==> "sun.nio.cs.ext.IBM964"

jshell> System.out.println(String.join("\n", cs.aliases()))
ibm-964
cp964
ibm-euctw
ibm964
964

jshell> /exit
|  Goodbye
$
==

On AIX platform
IBM964 is moved to java.base module from jdk.charset module.

==
$ LANG=zh_TW jshell
|  Welcome to JShell -- Version 12-internal
|  For an introduction type: /help intro

jshell> var cs = java.nio.charset.Charset.defaultCharset()
cs ==> x-IBM964

jshell> cs.getClass().getName()
$2 ==> "sun.nio.cs.IBM964"

jshell> System.out.println(String.join("\n", cs.aliases()))
ibm-964
cp964
ibm-euctw
ibm964
964

jshell> /exit
|  Goodbye
$
==

I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-11-29 22:39, Ichiroh Takiguchi wrote:

Hello Alan & Magnus.

Sorry for you confusion.
I did many copy actions and rename actions.
So you may see, I added unexpected code into non AIX platform.

I think I should not put 2 kind of modification.

For this bug id, I'll handle IBM964 and IBM33722.
(also SimpleEUCEncoder.java is required)

I'll submit code review again.

Additionally, I'll touch
make/data/charsetmapping/charsets
make/data/charsetmapping/stdcs-aix

I'll not touch
make/jdk/src/classes/build/tools/charsetmapping/Main.java
make/jdk/src/classes/build/tools/charsetmapping/SRC.java

My build machine is not so fast, after test is done.
I'll post new code.

Thanks,
Ichiroh Takiguchi

On 2018-11-28 19:10, Magnus Ihse Bursie wrote:

On 2018-11-28 10:36, Alan Bateman wrote:

On 28/11/2018 09:28, Magnus Ihse Bursie wrote:
I'm quite unsatisfied with the current handling of character sets 
in the build in general. :-( I'd really like to modernize it. I 
have a, slightly fuzzy, laundry list of things I want to fix from 
a build perspective, but I'm not sure of what "external" 
requirements are coming from AIX and the general core-libs agenda 
regarding character sets in general.


I think there is a good opportunity to solve many problems at the 
same time here, as long as everyone agrees on what is the 
preferred outcome.
The support in the build to configure the charsets to include in 
java.base on each platform has been working well. Charsets that 
aren't in java.base go into the jdk.charsets service provider 
module and that has been working well too. From the result point of 
view, perhaps, but definitely not from the build perspective. ;-) 
But yes, I understand this is functionality that should be kept.
One thing that we lack is some way to add charsets for specific 
platforms and this comes up with the IBM patches where they are 
looking to adding several additional IBM charsets. One starting 
point that we've touched on in several threads here is dropping the 
EBCDIC charsets from the main stream builds. Going there will need 
build support.

So build support for trivially adding specific charsets to specific
platforms? Both to java.base (for AIX) and jdk.charsets, I presume,
then?

Can you expand on the issue of dropping ebcdic? What's the problem
that needs build support?

/Magnus



-Alan

Re: RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM

[Magnus Ihse Bursie]

On 2018-11-28 23:49, Henry Jen wrote:


Since there is no header file in JDK provides the function prototypes, I don’t 
think this is considered public(supported) APIs.

Anyway, in case a tools is build with launcher code, and shipped separately 
from JDK, that would be impacted by this bug. So I added a test call JLI_Launch 
as well. Please review the updated webrev[1].

Note that, JLI_Launch should not be used directly as it does’t handle the 
argument processing which is done in launcher/main.c.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk12/8213362.1/webrev/
The build changes look good, as is the original fix for the problem. As 
far as I can tell, the tests seem reasonable. At the very least, this is 
a much better situation than we had before. So I say, ship it!


/Magnus




On Nov 28, 2018, at 5:28 AM, Kevin Rushforth  wrote:



On 11/28/2018 5:19 AM, Alan Bateman wrote:

On 28/11/2018 13:13, Kevin Rushforth wrote:

The jpackage tool calls JLI_Launch.

I remember that from Andy's webrev but it's not integrated yet. Does the JavaFX 
packager tool do the same?

Yes, the javapackager tool (delivered via JavaFX) in JDK 8/9/10 calls 
JLI_Launch.

-- Kevin

Re: CSR for posix_spawn on JDK 12

[Roger Riggs]

Hi Thomas,

Looks pretty good.

Usually 'we' avoid the first person writing in the jira.
It makes them more readable in the long term, when there is no context 
for 'we'.


- Describing it as 'experimental' gives the wrong impression
and has some magnified implications as that term is being used for
other major changes.

- The compatibility risk should be corrected:

Supplying an unknown value on the command line produces a java.lang.Error.

% java -Djdk.lang.Process.launchMechanism=POSIX_SPAWN ...

java.lang.Error: POSIX_SPAWN is not a supported process launch mechanism 
on this platform.


- Since CSRs should be self contained, the specification section should 
explicitly
specify the behavior from the API point of view. CSRs should avoid 
describing

the implementation (though in this case, its not entirely possible).
The webrev of the impl is not relevant.

Thanks, Roger


On 11/30/2018 03:32 AM, Thomas Stüfe wrote:

CSR for jdk12: https://bugs.openjdk.java.net/browse/JDK-8214511

..Thomas

Re: Downport JDK-8212828 (posix_spawn on Linux as non-default) to 11u

[Roger Riggs]

Hi Thomas,

The updates to the release note look fine.
Usually they are brief, containing just enough information to quickly
recognize the function and feature that has changed.
The complete information can be found in the original Jira issue.

Sorry about the lack of an external release note guide, one is needed.
Release notes use Markdown making them a bit more readable.
Looking at release notes from any prior release [1] will give you a good 
idea

as to the typical scope and wording.

Closing the release note as "Delivered" marks it ready for an
editorial pass made before the release notes are published
with the GA release.

Thanks, Roger

[1] 
https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html



On 11/30/2018 01:23 AM, Thomas Stüfe wrote:

Hi all,

I updated the Release note, please have a look.

Note that the linked style guide under [3] was not accessible to me
outside Oracle. So I did my best by mimicking the release notes Iris
send me.

Especially, it was not clear to me if we should clearly mark
experimental features as such.

Cheers, Thomas
On Thu, Nov 29, 2018 at 8:54 PM Roger Riggs  wrote:

Hi Thomas,

We'll also need a retroactive CSR for JDK 12 to change its status in JDK 12 to 
be documented.
Can you take a swing at that?
On the Jira issue[2] there is a "More" menu  with a 'Create CSR' button.
It comes pre-filled with a template that should be pretty straightforward to 
fill out.

A CSR will also be needed for JDK 11 (pretty much a copy).
In the compatibility section, point out that it does not change the default.

I created a draft release note for JDK 12 [1].
Please review and comment or edit it directly with suggestions.

Thanks, Roger

[1] https://bugs.openjdk.java.net/browse/JDK-8214454
[2] https://bugs.openjdk.java.net/browse/JDK-8212828


On 11/28/2018 11:56 AM, Thomas Stüfe wrote:

On Wed, Nov 28, 2018 at 5:39 PM Alan Bateman  wrote:

On 28/11/2018 15:36, Thomas Stüfe wrote:

Hi all,

I would like to have this patch in 11u too, so I just did a 11u
downport request.

Our agreement was that launchMechanism=POSIX_SPAWN would stay as
optional non-default value for jdk12, and at the start of JDK13
development we would switch the default to posix_spawn.

I would like to see this non-default-but-possible-to-set option in 11u
too, just to broaden the test surface. We'd get more testers that way.

What do you think, does that make sense?

It would be nice to have gotten feedback from people trying it out with
JDK 12 EA builds but I don't know if that is possible.

If it is backported then a CSR will be required as it will be adding a
new supported value. A release note or other documentation updates might
be needed too.

Oh, you are right. Do we have a release note/documentation for jdk12?

..Thomas

-Alan

RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

[Patrick Zhang]

Thanks Florian, the "-isystem /usr/include" is helpful to my case, I see 
gcc.gnu.org says that "it gets the same special treatment that is applied to 
the standard system directories". As such the issue gets hidden (error 
suppressed).

Hi David,
Thanks for your suggestion. My intention was to limit the influence range as 
far as I could since I don't have other systems except CentOS/Fedora to verify 
(even just smoke test) all paths.
In addition, if we make below update, does it mean the macro " _REENTRANT " can 
be removed too? This is probably the only place where _REENTRANT gets used 
AFAIK.
#ifdef _MSC_VER // Windows
#define gmtime_r(t, s) gmtime(t)
#endif

Regards
Patrick

-Original Message-
From: Florian Weimer  
Sent: Thursday, November 29, 2018 8:02 PM
To: David Holmes 
Cc: Patrick Zhang ; jdk-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net
Subject: Re: OpenJDK fails to build with GCC when the #include inside 
zip.cpp comes from a non-sysroot path

* David Holmes:

> This should really be being discussed on core-libs-dev.

Okay, moving the conversation.

>> diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp
>> --- a/src/share/native/com/sun/java/util/jar/pack/zip.cppTue Oct 09 
>> 08:33:33 2018 +0100
>> +++ b/src/share/native/com/sun/java/util/jar/pack/zip.cppWed Nov 28 
>> 22:13:12 2018 -0500
>> @@ -415,9 +415,7 @@
>>   ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1);
>>   }
>>   -#ifdef _REENTRANT // solaris
>> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else
>> +#if !defined(_REENTRANT) // linux
>>   #define gmtime_r(t, s) gmtime(t)
>>   #endif
>>   /*
>
> Under the theme "two wrongs don't make a right" the use of _REENTRANT 
> here is totally inappropriate AFAICS. It seems to be a misguided 
> attempt at determining whether we need the thread-safe gmtime_r or not
> - and the answer to that should always be yes IMHO.
>
> We define _REENTRANT for:
> - linux
> - gcc
> - xlc
>
> So the original code will define:
>
> extern "C" struct tm *gmtime_r(const time_t *, struct tm *);
>
> for linux (and AIX with xlc?) but not Solaris, OS X or Windows.
>
> But Solaris has gmtime_r anyway. So the existing code seems a really 
> convoluted hack. AFAICS we have gmtime_r everywhere but Windows (where 
> gmtime is already thread-safe). So it seems to me that all we should 
> need here is:
>
> -#ifdef _REENTRANT // solaris
> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else
> +#ifdef _MSC_VER // Windows
>  #define gmtime_r(t, s) gmtime(t)
>  #endif

That looks much cleaner.

Thanks,
Florian

RE: 8207404: MulticastSocket tests failing on Aix

[Lindenmaier, Goetz]

Hi Steve, 

I'm not that familiar with the network coding. 
But if the VM thinks that IPv6 is enabled, but later 
on something fails, shouldn't the check for IPv6
be improved?
Especially, if my and your box have been configured
the same, this is probably the default on aix boxes.
And I guess the VM should work on the default system
configuration?

Or do you think that this should be fixed in the
default system configuration?  

Best regards,
  Goetz.



> -Original Message-
> From: Steve Groeger 
> Sent: Freitag, 30. November 2018 12:20
> To: Lindenmaier, Goetz 
> Cc: ppc-aix-port-dev ; core-libs-
> d...@openjdk.java.net
> Subject: RE: 8207404: MulticastSocket tests failing on Aix
> 
> Hi Goetz,
> 
> I disabled IPv6 on my xLinux box and the MulticastSocket tests pass, as they
> detected that IPv6 is not enabled and then didnt try and set the IPv6 options.
> I am currently unable to disable IPv6 on my AIX box to test this but would
> assume it would also work as the code checks to see whether IPv6 is enabled
> and doesnt try and set the IPV6 options.
> It seems the issue with the tests failing seems to be, if IPv6 is enabled but 
> the
> interface doesn't have an IPv6 address associated with it, as in your case
> here:
> 
> bash-4.3$ ifconfig -a
> en0:
> flags=1e084863,480 CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
>inet 10.xx.xxx.xxx netmask 0xfe00 broadcast 10.xx.xxx.xxx
> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
> lo0:
> flags=e08084b,c0 ,GROUPRT,64BIT,LARGESEND,CHAIN>
>inet 127.x.x.x netmask 0xff00 broadcast 127.xxx.xxx.xxx
>inet6 ::1%1/0
> tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
> 
> where you can see that the en0 interface has an inet address associated but
> doesnt have an inet6 address associated.
> I can see that IPv6 is enabled as the lo0 interface has an inet6 address
> (pointing to localhost)
> 
> As I stated below, my AIX system was configured in a similar way to yours
> and the tests failed. When I was able to add an inet6 address to en0,
> everything works correctly.
> NOTE: Not sure this was correct but I ran 'sudo autoconf6' which seemed to
> add the inet6 address to my en0 interface. After that all tests worked.
> 
> So I think the tests are working as expected, but the AIX system is not
> configured correctly, but I would like someone else to confirm this.
> 
> 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:"Lindenmaier, Goetz" 
> To:Steve Groeger , ppc-aix-port-dev  port-...@openjdk.java.net>
> Date:30/11/2018 10:18
> Subject:RE: 8207404: MulticastSocket tests failing on Aix
> 
> 
> 
> 
> 
> 
> i Steve,
> 
> thanks for looking at this issue.
> 
> > Should these tests work without having IPV6 configured on the interface?
> In general, tests should not show errors if a system does not meet
> the requirements for the test. In such cases the test should
> be skipped somehow. Maybe only a test fix is needed.
> 
> Can you check on a non-aix machine without ipv6 whether the test
> passes?
> 
> > Goetz, do you have IPV6 configured on the machine you were running
> these
> > tests on?
> This is our test machine:
> 
> bash-4.3$ ifconfig -a
> en0:
> flags=1e084863,480 CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
>inet 10.xx.xxx.xxx netmask 0xfe00 broadcast 10.xx.xxx.xxx
> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
> lo0:
> flags=e08084b,c0 ,GROUPRT,64BIT,LARGESEND,CHAIN>
>inet 127.x.x.x netmask 0xff00 broadcast 127.xxx.xxx.xxx
>inet6 ::1%1/0
> tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
> 
> I think this message should be posted to core-libs-dev, too. That's also
> the list where a potential fix needs to be reviewed.
> 
> Best regards,
>  Goetz.
> 
> 
> > -Original Message-
> > From: Steve Groeger 
> > Sent: Donnerstag, 29. November 2018 17:07
> > To: ppc-aix-port-dev 
> > Cc: Lindenmaier, Goetz 
> > Subject: 8207404: MulticastSocket tests failing on Aix
> >
> > Hi All,
> >
> > I have been having a look at this issue:
> > https://bugs.openjdk.java.net/browse/JDK-8207404
> 
> >   >
> > which was raised by  Goetz Lindenmaier.
> >
> > When I ran the tests on my AIX system I got the same results as Goetz listed
> > in the issue.
> >
> > Looking at the failure I noticed that it was failing on a setsockopt call 
> > in the
> > native code in
> 

RE: 8207404: MulticastSocket tests failing on Aix

[Steve Groeger]

Hi Goetz, 

I disabled IPv6 on my xLinux box and the MulticastSocket tests pass, as 
they detected that IPv6 is not enabled and then didnt try and set the IPv6 
options.
I am currently unable to disable IPv6 on my AIX box to test this but would 
assume it would also work as the code checks to see whether IPv6 is 
enabled and doesnt try and set the IPV6 options.
It seems the issue with the tests failing seems to be, if IPv6 is enabled 
but the interface doesn't have an IPv6 address associated with it, as in 
your case here:

bash-4.3$ ifconfig -a
en0: 
flags=1e084863,480
inet 10.xx.xxx.xxx netmask 0xfe00 broadcast 10.xx.xxx.xxx
 tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
lo0: 
flags=e08084b,c0
inet 127.x.x.x netmask 0xff00 broadcast 127.xxx.xxx.xxx
inet6 ::1%1/0
 tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

where you can see that the en0 interface has an inet address associated 
but doesnt have an inet6 address associated. 
I can see that IPv6 is enabled as the lo0 interface has an inet6 address 
(pointing to localhost)

As I stated below, my AIX system was configured in a similar way to yours 
and the tests failed. When I was able to add an inet6 address to en0, 
everything works correctly.
NOTE: Not sure this was correct but I ran 'sudo autoconf6' which seemed to 
add the inet6 address to my en0 interface. After that all tests worked.

So I think the tests are working as expected, but the AIX system is not 
configured correctly, but I would like someone else to confirm this.

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:   "Lindenmaier, Goetz" 
To: Steve Groeger , ppc-aix-port-dev 

Date:   30/11/2018 10:18
Subject:RE: 8207404: MulticastSocket tests failing on Aix



i Steve, 

thanks for looking at this issue.

> Should these tests work without having IPV6 configured on the interface?
In general, tests should not show errors if a system does not meet
the requirements for the test. In such cases the test should 
be skipped somehow. Maybe only a test fix is needed.

Can you check on a non-aix machine without ipv6 whether the test
passes?

> Goetz, do you have IPV6 configured on the machine you were running these
> tests on?
This is our test machine:

bash-4.3$ ifconfig -a
en0: 
flags=1e084863,480
inet 10.xx.xxx.xxx netmask 0xfe00 broadcast 10.xx.xxx.xxx
 tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
lo0: 
flags=e08084b,c0
inet 127.x.x.x netmask 0xff00 broadcast 127.xxx.xxx.xxx
inet6 ::1%1/0
 tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

I think this message should be posted to core-libs-dev, too. That's also
the list where a potential fix needs to be reviewed.

Best regards,
  Goetz.


> -Original Message-
> From: Steve Groeger 
> Sent: Donnerstag, 29. November 2018 17:07
> To: ppc-aix-port-dev 
> Cc: Lindenmaier, Goetz 
> Subject: 8207404: MulticastSocket tests failing on Aix
> 
> Hi All,
> 
> I have been having a look at this issue:
> 
https://bugs.openjdk.java.net/browse/JDK-8207404

> <
https://bugs.openjdk.java.net/browse/JDK-8207404
>
> which was raised by  Goetz Lindenmaier.
> 
> When I ran the tests on my AIX system I got the same results as Goetz 
listed
> in the issue.
> 
> Looking at the failure I noticed that it was failing on a setsockopt 
call in the
> native code in
> the PlainDatagramSocketImpl.c file which returned a EADDRNOTAVAIL (Can't
> assign requested address)
> 
> Looking at my network configuration using "ifconfig -a", I noticed that 
my
> interface "en0" which the test
> was trying to use did not have an inet6 address configured (see below - 
some
> addresses have been obfuscated with x's).
> 
> en0:
> flags=1e084863,14c0 CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
> inet 9.20.xx.xx netmask 0xff00 broadcast 9.20.xx.xxx
>  tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
> 
> configuring the IPV6 on my AIX box I then had a inet6 address configured 
for
> en0
> 
> en0:
> flags=1e084863,14c0 CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
> inet 9.20.xx.xx netmask 0xff00 broadcast 9.20.xx.xxx
> inet6 fe80:::::/64
>  tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
> 
> with this configured the MulticastSocket tests all passed.
> 
> Should these tests work without having IPV6 configured on the interface?
> 
> Goetz, do you have IPV6 configured on the machine you were running these
> tests on?
> 
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, UK
> Tel: (44) 1962 816911  

Re: RFR - JDK-8203442 String::transform (Code Review)

[Stephen Colebourne]

I see from Twitter (!!!) that this has been pushed. This appears to have
happened without this thread coming to a clear conclusion, particularly wrt
criticism of transform() as a suitable method name in the broader context.

I also do not think that the code review was completed correctly and in
public, which I find concerning.

The two public threads are:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056574.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056592.html

The last webrev had the name map() and no further webrev was published that
I can see. I can see no explicit public approvals of the change from
reviewers. And plenty of concern about the method name, especially map()
but also transform().

While I'm well aware of the danger of public bikeshedding, I also think
that adding methods to `String` deserves more care than this has been
shown. In my view the change should be reverted, and retargetted to Java 13
to allow for a proper conclusion to the discussion.

For info, AWS SDK v2 has chosen applyMutation() for a similar concept:
https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/utils/builder/SdkBuilder.html#applyMutation-java.util.function.Consumer-

Stephen


On Wed, 14 Nov 2018, 14:18 Stephen Colebourne  On Tue, 13 Nov 2018 at 15:44, Brian Goetz  wrote:
> > Yes, we know :)  But we don’t have any current plans to do that, nor
> use-site extension methods, nor does it seem likely to come to the top of
> the language priority list very soon.  So its not a choice between |> and
> .transform(); it’s a choice between transform() and nothing.  Picking
> transform() seems pretty good here.
> >
> > Stephen raised the issue of a “broader context”; indeed, the intention
> of adding a transform() method here was that it would be feasible to add to
> other types for which it was suitable.  String is an obvious candidate for
> “do it first”, but this is within a broader context.
>
> I'd be more comforted if there was a commitment to add the method to
> Stream and Optional in Java 12 or 13.
>
> I also agree with Remi that `transform()` is a poor name for Stream,
> and thus it is a poor name for String. I doubt there is a perfect
> name, process() or apply() seem like good candidates.
>
> Stephen
>

Re: RFR: 8212794 IBM-964 is required for AIX default charset

[Ichiroh Takiguchi]

Hello.

Could you review the fix again ?

Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/

I just fixed only IBM964 for JDK-8212794.
(IBM29626C fix is not included)

On non AIX platform (Linux),
ibm-euctw alias is added for IBM964.

Without fix
$ jshell
|  Welcome to JShell -- Version 12-ea
|  For an introduction type: /help intro

jshell> var cs = java.nio.charset.Charset.forName("IBM964")
cs ==> x-IBM964

jshell> cs.getClass().getName()
$2 ==> "sun.nio.cs.ext.IBM964"

jshell> System.out.println(String.join("\n", cs.aliases()))
ibm-964
cp964
ibm964
964

jshell> /exit
|  Goodbye
$
==

With fix
==
$ jshell
|  Welcome to JShell -- Version 12-internal
|  For an introduction type: /help intro

jshell> var cs = java.nio.charset.Charset.forName("IBM964")
cs ==> x-IBM964

jshell> cs.getClass().getName()
$2 ==> "sun.nio.cs.ext.IBM964"

jshell> System.out.println(String.join("\n", cs.aliases()))
ibm-964
cp964
ibm-euctw
ibm964
964

jshell> /exit
|  Goodbye
$
==

On AIX platform
IBM964 is moved to java.base module from jdk.charset module.

==
$ LANG=zh_TW jshell
|  Welcome to JShell -- Version 12-internal
|  For an introduction type: /help intro

jshell> var cs = java.nio.charset.Charset.defaultCharset()
cs ==> x-IBM964

jshell> cs.getClass().getName()
$2 ==> "sun.nio.cs.IBM964"

jshell> System.out.println(String.join("\n", cs.aliases()))
ibm-964
cp964
ibm-euctw
ibm964
964

jshell> /exit
|  Goodbye
$
==

I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-11-29 22:39, Ichiroh Takiguchi wrote:

Hello Alan & Magnus.

Sorry for you confusion.
I did many copy actions and rename actions.
So you may see, I added unexpected code into non AIX platform.

I think I should not put 2 kind of modification.

For this bug id, I'll handle IBM964 and IBM33722.
(also SimpleEUCEncoder.java is required)

I'll submit code review again.

Additionally, I'll touch
make/data/charsetmapping/charsets
make/data/charsetmapping/stdcs-aix

I'll not touch
make/jdk/src/classes/build/tools/charsetmapping/Main.java
make/jdk/src/classes/build/tools/charsetmapping/SRC.java

My build machine is not so fast, after test is done.
I'll post new code.

Thanks,
Ichiroh Takiguchi

On 2018-11-28 19:10, Magnus Ihse Bursie wrote:

On 2018-11-28 10:36, Alan Bateman wrote:

On 28/11/2018 09:28, Magnus Ihse Bursie wrote:
I'm quite unsatisfied with the current handling of character sets in 
the build in general. :-( I'd really like to modernize it. I have a, 
slightly fuzzy, laundry list of things I want to fix from a build 
perspective, but I'm not sure of what "external" requirements are 
coming from AIX and the general core-libs agenda regarding character 
sets in general.


I think there is a good opportunity to solve many problems at the 
same time here, as long as everyone agrees on what is the preferred 
outcome.
The support in the build to configure the charsets to include in 
java.base on each platform has been working well. Charsets that 
aren't in java.base go into the jdk.charsets service provider module 
and that has been working well too. From the result point of view, 
perhaps, but definitely not from the build perspective. ;-) But yes, 
I understand this is functionality that should be kept.
One thing that we lack is some way to add charsets for specific 
platforms and this comes up with the IBM patches where they are 
looking to adding several additional IBM charsets. One starting point 
that we've touched on in several threads here is dropping the EBCDIC 
charsets from the main stream builds. Going there will need build 
support.

So build support for trivially adding specific charsets to specific
platforms? Both to java.base (for AIX) and jdk.charsets, I presume,
then?

Can you expand on the issue of dropping ebcdic? What's the problem
that needs build support?

/Magnus



-Alan

DataTruncation has static message

[Bernd Eckenfels]

Hello,

The java.sql.DataTruncation Exception/warning has a few detail members, 
especially the index of the field in question. Yet it will not be reflected in 
getMessage/toString. I wonder if the message should be dynamic to at least 
include the index (if known).

http://hg.openjdk.java.net/jdk/jdk/file/7d3391e9df19/src/java.sql/share/classes/java/sql/DataTruncation.java

Gruss
Bernd
--
http://bernd.eckenfels.net

Re: Downport JDK-8212828 (posix_spawn on Linux as non-default) to 11u

[Thomas Stüfe]

CSR for jdk12: https://bugs.openjdk.java.net/browse/JDK-8214511

..Thomas
On Fri, Nov 30, 2018 at 7:23 AM Thomas Stüfe  wrote:
>
> Hi all,
>
> I updated the Release note, please have a look.
>
> Note that the linked style guide under [3] was not accessible to me
> outside Oracle. So I did my best by mimicking the release notes Iris
> send me.
>
> Especially, it was not clear to me if we should clearly mark
> experimental features as such.
>
> Cheers, Thomas
> On Thu, Nov 29, 2018 at 8:54 PM Roger Riggs  wrote:
> >
> > Hi Thomas,
> >
> > We'll also need a retroactive CSR for JDK 12 to change its status in JDK 12 
> > to be documented.
> > Can you take a swing at that?
> > On the Jira issue[2] there is a "More" menu  with a 'Create CSR' button.
> > It comes pre-filled with a template that should be pretty straightforward 
> > to fill out.
> >
> > A CSR will also be needed for JDK 11 (pretty much a copy).
> > In the compatibility section, point out that it does not change the default.
> >
> > I created a draft release note for JDK 12 [1].
> > Please review and comment or edit it directly with suggestions.
> > There is a release note style guide for reference [3].
> >
> > Thanks, Roger
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8214454
> > [2] https://bugs.openjdk.java.net/browse/JDK-8212828
> > [3[ https://wiki.se.oracle.com/display/JPG/OpenJDK+Release+Note+Style+Guide
> >
> > On 11/28/2018 11:56 AM, Thomas Stüfe wrote:
> >
> > On Wed, Nov 28, 2018 at 5:39 PM Alan Bateman  
> > wrote:
> >
> > On 28/11/2018 15:36, Thomas Stüfe wrote:
> >
> > Hi all,
> >
> > I would like to have this patch in 11u too, so I just did a 11u
> > downport request.
> >
> > Our agreement was that launchMechanism=POSIX_SPAWN would stay as
> > optional non-default value for jdk12, and at the start of JDK13
> > development we would switch the default to posix_spawn.
> >
> > I would like to see this non-default-but-possible-to-set option in 11u
> > too, just to broaden the test surface. We'd get more testers that way.
> >
> > What do you think, does that make sense?
> >
> > It would be nice to have gotten feedback from people trying it out with
> > JDK 12 EA builds but I don't know if that is possible.
> >
> > If it is backported then a CSR will be required as it will be adding a
> > new supported value. A release note or other documentation updates might
> > be needed too.
> >
> > Oh, you are right. Do we have a release note/documentation for jdk12?
> >
> > ..Thomas
> >
> > -Alan
> >
> >