Re: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20

[Martin Buchholz]

On Mon, Feb 26, 2018 at 4:31 PM, joe darcy  wrote:

> PS JDK 11 b02 bits now available for download:
>
> http://jdk.java.net/11/


Thanks, I am enjoying my jdk-11-ea+02 binaries.

Consistent with the new model of a repo always at head (which is awesome)
how about simply continuously putting out a new build every week?  No need
for hiatus due to release N-1 schedule concerns.

And could someone provide api javadoc at a stable location so that I can
link to it in a way that won't become dangling?
https://download.java.net/java/early_access/jdk11/docs/api/overview-summary.html
is nice but is too ephemeral.

Re: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20

[joe darcy]

PS JDK 11 b02 bits now available for download:

    http://jdk.java.net/11/

Cheers,

-Joe

On 2/21/2018 5:47 PM, joe darcy wrote:

On 2/21/2018 12:54 PM, Martin Buchholz wrote:

On Tue, Feb 20, 2018 at 11:09 PM, Abhijit Saha  
wrote:


It's a retroactive review request. Fix has been integrated after 
reviewed

internally.

jdk11+1 (first build of jdk11) was promoted with incorrect Release 
Date.
Need to be updated with correct GA date as per internal release 
roadmap.



Where are my shiny jdk11+1 binaries for download ?!

It would be nice if version information was always correct, which would
mean part of the checklist of creating a release repo would be 
setting the

release date of jdk/jdk/ 6 months later and marking it "ea" and updating
the version to self-identify as java N+1.  jdk binaries built from 
jdk/jdk

have been misidentifying themselves since the jdk 10 repo was created.


Certainly it would be preferable if the version update occurred sooner.

However, binaries build from jdk/jdk have been correctly identifying 
themselves as "JDK 11" since David Holmes pushed the fix for 8173401: 
"Update VERSION_FEATURE for JDK 11" on February 6, 2018.


There are about half a dozen distinct changes that need to occur for a 
full conceptual version update going from JDK N to JDK (N+1). Besides 
the actual version update, there are -source/-target changes to javac, 
minor API changes, etc.


Some of the changes made in JDK 11 b01 were done specifically to ease 
future version updates. This included hardening various tests against 
version updates. Since the version updates are happening more often 
now, there is more motivation to streamline the process 
(https://xkcd.com/1205/).


-Joe

RFR: JDK-8198724 Refactor FLAGS handling in configure

[Magnus Ihse Bursie]

The current way we're handling FLAGS (CFLAGS/CXXFLAGS, LDFLAGS, etc) is 
laden with technical debt. It's a sorry mess, hard to do anything 
constructive about.


This is the first step towards a better solution. The main goal is to 
have a set of more specific flags, more like how the SYSROOT flags work 
today, that can be individually included, instead of a huge CFLAGS_JDKLIB.


To make such a change manageable, this first step will (almost) only 
refactor the autoconf code, but will output the same flags in the spec.gmk.


To minimize special cases, I have accepted the following differences:
* On linux/gcc, we will get a -m, e.g. -m64 always (as on 
aix/solaris).
* On macosx/clang, we will get a -m, e.g. -m64 always (as on 
aix/solaris).
* On macosx/clang, we will now "hardcode" the max/min version number 
without dots.
* On macosx/clang, the JVM_CFLAGS for the build toolchain will now also 
get an -fPIC (this was mysteriously missing before).
* On windows/microsoft, the build toolchain will now get -nologo added 
as well, and also -homeparams for debug builds.
* On solaris/solstudio, the JDKEXE flags will now include -errfmt, and 
CFLAGS_JDKEXE will include -errtags=yes. The duplication of -errtags=yes 
in CXXFLAGS_JDKLIB is removed.
* On solaris/solstudio, we now always use -KPIC as pic flag. 
(Previously, we used -xcode=pic32 on sparc, but this is equivalent to 
-KPIC, so there's no reason for a special case.)
* On solaris/solstudio, we now use e.g. "-Wc,-Qrm-s" instead of 
"-Qoption cg -Qrm-s" for C++ as well as for C code. The two formats are 
equivalent (for passing options to a certain compilation phase), and 
there was no reason to use different ones for C and C++.


And for clarity, I have also renamed some exported flags to clearly show 
that they are consumed by LIBJSIG and ADLC. I have also renamed "/STACK" 
on the Microsoft linker to "-stack", to match how we write options 
elsewhere.


I believe none of these should have any real effect, but if anything, 
they could probably be considered bug fixes.


I have considered whitespace and ordering differences as irrelevant.

I have manually verified that the generated spec.gmk and 
buildjdk-spec.gmk matches this (no changes apart from the one listed 
above) for linux/x64/gcc, solaris/sparcv9/solstudio, 
windows/x64/microsoft and macosx/x64/clang, for release and fastdebug.


I am also currently running a test job using the COMPARE_BUILD 
functionality on our internal build system.


I would appreciate if comments are more in the form of "think of this 
for subsequent updates to the flag handling" rather than requests to 
change this patch, at least for requests that are just not small fixes. 
(I've been juggling this for a while, trying to get it right...)


Bug: https://bugs.openjdk.java.net/browse/JDK-8198724
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8198724-refactor-flags-step-1/webrev.01


/Magnus

Re: RFR(S) 8197453 : Add support of extra problem list

[Jonathan Gibbons]

Igor,

I think this is more a style issue than an issue we want to enforce. I 
think it is good style to use a platform specifier, including 
generic-all for "all platforms", so that people will realize they can 
put some more restrictive alternative.


-- Jon

On 02/26/2018 03:07 PM, Igor Ignatyev wrote:

Hi Jon,

yes, they are. we will  generic-all to each line.

do you think it makes sense to file an RFE for jtreg to report a missed 
platform specifier as an error?

Thanks,
-- Igor


On Feb 26, 2018, at 12:02 PM, Jonathan Gibbons  
wrote:

If these new problem-list files are destined for use by jtreg, I would encourage adding a 
platform specifier on each line, after the bug number. If you want to mark the test as 
excluded on all platforms, the convention is to use "generic-all".

-- Jon


On 2/26/18 11:47 AM, Igor Ignatyev wrote:

adding build-dev alias

-- Igor


On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova  
wrote:

Hi all,

ProblemList.txt files used by makefiles for jtreg testing allow to specify list 
of tests to be excluded
from execution on all or specific platforms. However to test such features like 
Graal we want to be able
to specify list of failed tests which fail in particular JVM mode only.
Please review this change which adds support of extra problem list and 
introduces 2 Graal specific problem list files.
- test/hotspot/jtreg/ProblemList-graal.txt
- test/jdk/ProblemList-graal.txt


 JBS: https://bugs.openjdk.java.net/browse/JDK-8197453
  webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/
testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS.
  testing in Graal mode with EXTRA_PROBLEM_LISTS=ProblemList-graal.txt

thanks,
-katya

p.s.
Igor Ignatyev volunteered to sponsor this change.

Re: RFR(S) 8197453 : Add support of extra problem list

[Igor Ignatyev]

Hi Jon,

yes, they are. we will  generic-all to each line.

do you think it makes sense to file an RFE for jtreg to report a missed 
platform specifier as an error?

Thanks,
-- Igor 

> On Feb 26, 2018, at 12:02 PM, Jonathan Gibbons  
> wrote:
> 
> If these new problem-list files are destined for use by jtreg, I would 
> encourage adding a platform specifier on each line, after the bug number. If 
> you want to mark the test as excluded on all platforms, the convention is to 
> use "generic-all".
> 
> -- Jon
> 
> 
> On 2/26/18 11:47 AM, Igor Ignatyev wrote:
>> adding build-dev alias
>> 
>> -- Igor
>> 
>>> On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> ProblemList.txt files used by makefiles for jtreg testing allow to specify 
>>> list of tests to be excluded
>>> from execution on all or specific platforms. However to test such features 
>>> like Graal we want to be able
>>> to specify list of failed tests which fail in particular JVM mode only.
>>> Please review this change which adds support of extra problem list and 
>>> introduces 2 Graal specific problem list files.
>>> - test/hotspot/jtreg/ProblemList-graal.txt
>>> - test/jdk/ProblemList-graal.txt
>>> 
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8197453
>>>  webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/
>>> testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS.
>>>  testing in Graal mode with 
>>> EXTRA_PROBLEM_LISTS=ProblemList-graal.txt
>>> 
>>> thanks,
>>> -katya
>>> 
>>> p.s.
>>> Igor Ignatyev volunteered to sponsor this change.
> 

Re: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs

[Tim Bell]

Magnus:


It was recently discovered that some URLs in JDK 10 still pointed to the
"javase9" URL base.

I intend to push this to jdk10/master, given suffient approval.


Acting as leader of the build group, I decorated the bug report and 
applied a 'jdk10-fix-yes' label.



Bug: https://bugs.openjdk.java.net/browse/JDK-8198658
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01


Looks good.

Tim

Re: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs

[Magnus Ihse Bursie]

On 2018-02-26 21:57, joe darcy wrote:

Hi Magnus,

Looks okay for now, but longer term should the version be queried from 
the environment some way?


We'll have to look into the best way to solve this in a more robust way. 
I opened https://bugs.openjdk.java.net/browse/JDK-8198718 for that.


/Magnus



Thanks,

-Joe


On 2/26/2018 12:38 PM, Magnus Ihse Bursie wrote:
It was recently discovered that some URLs in JDK 10 still pointed to 
the "javase9" URL base.


I intend to push this to jdk10/master, given suffient approval.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198658
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01


/Magnus

Re: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs

[Martin Buchholz]

http://www.oracle.com/pls/topic/lookup?ctx=javase10 currently takes you to
java 9 docs

On Mon, Feb 26, 2018 at 12:38 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> It was recently discovered that some URLs in JDK 10 still pointed to the
> "javase9" URL base.
>
> I intend to push this to jdk10/master, given suffient approval.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198658
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-lin
> ks-to-javase10/webrev.01
>
> /Magnus
>
>

Re: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs

[joe darcy]

Hi Magnus,

Looks okay for now, but longer term should the version be queried from 
the environment some way?


Thanks,

-Joe


On 2/26/2018 12:38 PM, Magnus Ihse Bursie wrote:
It was recently discovered that some URLs in JDK 10 still pointed to 
the "javase9" URL base.


I intend to push this to jdk10/master, given suffient approval.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198658
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01


/Magnus

[urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs

[Magnus Ihse Bursie]

It was recently discovered that some URLs in JDK 10 still pointed to the 
"javase9" URL base.


I intend to push this to jdk10/master, given suffient approval.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198658
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8198658-update-docs-links-to-javase10/webrev.01


/Magnus

Re: RFR(S) 8197453 : Add support of extra problem list

[Jonathan Gibbons]

If these new problem-list files are destined for use by jtreg, I would 
encourage adding a platform specifier on each line, after the bug 
number. If you want to mark the test as excluded on all platforms, the 
convention is to use "generic-all".


-- Jon


On 2/26/18 11:47 AM, Igor Ignatyev wrote:

adding build-dev alias

-- Igor


On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova  
wrote:

Hi all,

ProblemList.txt files used by makefiles for jtreg testing allow to specify list 
of tests to be excluded
from execution on all or specific platforms. However to test such features like 
Graal we want to be able
to specify list of failed tests which fail in particular JVM mode only.
Please review this change which adds support of extra problem list and 
introduces 2 Graal specific problem list files.
- test/hotspot/jtreg/ProblemList-graal.txt
- test/jdk/ProblemList-graal.txt


 JBS: https://bugs.openjdk.java.net/browse/JDK-8197453
  webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/
testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS.
  testing in Graal mode with EXTRA_PROBLEM_LISTS=ProblemList-graal.txt

thanks,
-katya

p.s.
Igor Ignatyev volunteered to sponsor this change.

Re: RFR(S) 8197453 : Add support of extra problem list

[Igor Ignatyev]

adding build-dev alias

-- Igor

> On Feb 8, 2018, at 3:08 PM, Ekaterina Pavlova  
> wrote:
> 
> Hi all,
> 
> ProblemList.txt files used by makefiles for jtreg testing allow to specify 
> list of tests to be excluded
> from execution on all or specific platforms. However to test such features 
> like Graal we want to be able
> to specify list of failed tests which fail in particular JVM mode only.
> Please review this change which adds support of extra problem list and 
> introduces 2 Graal specific problem list files.
> - test/hotspot/jtreg/ProblemList-graal.txt
> - test/jdk/ProblemList-graal.txt
> 
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8197453
>  webrev: http://cr.openjdk.java.net/~epavlova//8197453/webrev.00/
> testing: precheckin, tier1 and tier2 with empty EXTRA_PROBLEM_LISTS.
>  testing in Graal mode with EXTRA_PROBLEM_LISTS=ProblemList-graal.txt
> 
> thanks,
> -katya
> 
> p.s.
> Igor Ignatyev volunteered to sponsor this change.

Re: RFR: JDK-8198627 JDK-8198318 broke readlink testing

[Magnus Ihse Bursie]

I apologize for the extra work my mistake caused you. :(

/Magnus

> 23 feb. 2018 kl. 16:19 skrev Volker Simonis :
> 
> Good patch, Magnus!
> 
> We've been affected by this as well but instead of digging deeper into
> the problem we've installed "readlink" on our AIX build machines,
> where it wasn't available until now. Good to know that "readlink" is
> still not a mandatory requirement for the build :)
> 
> 
> On Fri, Feb 23, 2018 at 2:24 PM, Magnus Ihse Bursie
>  wrote:
>> The if line introduced in JDK-8198318 is missing a "test".
>> Thanks to Jon and Erik for discovering the problem and the solution.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198627
>> Patch inline:
>> 
>> diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4
>> --- a/make/autoconf/basics.m4
>> +++ b/make/autoconf/basics.m4
>> @@ -263,7 +263,7 @@
>>   READLINK_TESTED=yes
>> fi
>> 
>> -if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then
>> +if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then
>>   $1=`$READLINK -f [$]$1`
>> else
>>   # Save the current directory for restoring afterwards
>> 
>> /Magnus