JDK 9 RFR of JDK-8075771: Enable "missing" doclint check in build of the java.desktop module

[joe darcy]

Hello,

Changes to fix all the "missing" doclint warnings in the client 
libraries are out for review (see subtasks of JDK-8071630: "Fix 
remaining doclint warnings in the jdk repo").


Looking ahead to the happy day when all the changes are pushed and 
propagated to jdk9 / dev, please review the patch below to address


JDK-8075771: Enable "missing" doclint check in build of the 
java.desktop module


diff -r 8f03e7bb692b make/CompileJavaModules.gmk
--- a/make/CompileJavaModules.gmkMon Apr 06 10:35:43 2015 -0700
+++ b/make/CompileJavaModules.gmkWed Apr 08 14:49:01 2015 -0700
@@ -99,7 +99,7 @@

 


-java.desktop_ADD_JAVAC_FLAGS := 
-Xdoclint:all/protected,-missing,-reference 
'-Xdoclint/package:java.*,javax.*'
+java.desktop_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference 
'-Xdoclint/package:java.*,javax.*'

 java.desktop_COPY := .gif .png .wav .txt .xml .css .pf
 java.desktop_CLEAN := iio-plugin.properties cursors.properties

Thanks,

-Joe

Re: We REALLY nead a NON-PCH build in JPRT NOW!

[Magnus Ihse Bursie]

On 2015-04-03 00:36, Kim Barrett wrote:

On Apr 2, 2015, at 12:06 PM, Volker Simonis  wrote:

while precompiled headers (PCH) are a nice and effective way of
improving hotspot build times

Are we sure about that?


No, we're not. :-)

We in the build team, mainly Erik, have done testing on several 
occasions for the two major special tricks for enhancing build 
performance: PCH and ccache. Erik can probably quote you some numbers, 
but what I remember as the bottom line is that it is very much YMMV. 
There are many different scenarios:

* occasionally doing full builds from scratch
* incremental rebuilds
* repeatingly building full builds from scrach (which benefits ccache)

There are also different versions of compilers and ccache, and different 
operating systems with different file caching policies, and different 
hardware profiles (is your CPU or disk the bottleneck, etc).


Also, it is worth noting that ccache and PCH genereally do not play very 
well together. Sometimes enabling both will result in worse performance 
than just enabling one of them.


So there is no golden answer, the one thing that is most efficient in 
all circumstances.


We try to provide a reasonable default which works well in most cases 
(this currently means ccache off by default and PCH on, for hotspot). If 
you care about performance, the best thing you can do is to measure with 
and without PCH and ccache on your typical work case.


Regarding PCH and JPRT, there seem to be agreement that it typically 
improves compilation performance, at least on some platforms.


/Magnus

Re: RfR JDK-8076552 nightly build break fix

[David Holmes]

Hi Pete,

Sorry all this was happening in the wee hours for me :)

On 9/04/2015 3:55 AM, Pete Brunet wrote:

How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03


Seems like a good temporary fix.

To answer your earlier question to my comment, the $60K question is 
whether this stuff is indeed all platforms or not. If it is then of 
course the files should be relocated and the issue will disappear.


Thanks,
David


On 4/8/15 12:47 PM, Mandy Chung wrote:

I agree with Phil's suggestion and file a bug to follow up the javadoc
build issue.

You can verify the result from make docs that there is no javadoc
generated for this package on windows build.

Mandy

On 4/8/2015 10:29 AM, Phil Race wrote:

Isn't it sufficient to comment out this one line ?

1215 ALL_OTHER_TARGETS += jaccessdocs

.. and add a comment as to why ?

-phil.


On 04/08/2015 10:25 AM, Pete Brunet wrote:

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:

Please review/approve the following patch.

http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

The recent push for JDK-8076182 caused a build break, i.e. a
problem for
the creation of the Javadoc in the environment used by the nightly
build.  This was because a newly opened package
com.sun.java.accessibility.util was mistakenly located in a windows
directory.  This patch moves the package's files from
jdk/src/windows/classes to jdk/src/share/classes and this should
resolve
the build break for the jdk8u-dev nightly.

JPRT builds run OK on solaris, mac, and linux.  As of this writing the
Win jobs haven't started yet but the 64 bit build completed OK on my
local machine.

This patch also had to include the fix for JDK-8051297 "Remove
com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That file
is dead code and its existence in jdk/src/share/classes causes a
compilation failure, access of a non-existent enum, the reason the
file
was planned to be removed.

Thanks, Pete

Re: RfR JDK-8076552 nightly build break fix

[Pete Brunet]

Thanks Sean,

On 4/8/15 1:39 PM, Seán Coffey wrote:
> Pete,
>
> http://openjdk.java.net/projects/jdk8u/groundrules.html
> Rule 1. What are your plans for JDK 9 ? Is that family affected ? If
> not - add '9-na' label to bug report.
There have been no issues with 9 so I added 9-na.
>
> Rule 4. Approval requests should be carried out on jdk8u-dev mailing
> list.
I did the RfA on jdk8u-dev (but am pending the start/run/success of the
7 JPRT builds).
>
> regards,
> Sean.
>
> On 08/04/2015 19:14, Pete Brunet wrote:
>> resending - too many on To:/Cc:
>>
>> On 4/8/15 1:08 PM, Pete Brunet wrote:
>>> I confirmed the javadoc is gone, and make docs did not fail.
>>>
>>> I have yet to submit the JPRT job.
>>>
>>> Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
>>> you approve the push?
>>>
>>> Phil will have to do the push; my committer status is pending.
>>>
>>> Pete
>>>
>>> On 4/8/15 1:00 PM, Phil Race wrote:
 That looks good to me.

 -phil.

 On 4/8/2015 10:55 AM, Pete Brunet wrote:
> How's this?
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>
> On 4/8/15 12:47 PM, Mandy Chung wrote:
>> I agree with Phil's suggestion and file a bug to follow up the
>> javadoc
>> build issue.
>>
>> You can verify the result from make docs that there is no javadoc
>> generated for this package on windows build.
>>
>> Mandy
>>
>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>> Isn't it sufficient to comment out this one line ?
>>>
>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>
>>> .. and add a comment as to why ?
>>>
>>> -phil.
>>>
>>>
>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
 Here is an updated patch.
 http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

 It simply removes the com.sun.java.accessibility.util part of the
 javadoc generation.

 How to better deal with the javadoc generation can be left to
 later.

 Please let me know if this patch meets with your approval.

 I have started a local Win build and will start JPRT builds on
 Linux,
 Windows, Solaris, and Mac shortly.

 Thanks,
 Pete

 On 4/8/15 12:51 AM, Pete Brunet wrote:
> Please review/approve the following patch.
>
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>
> The recent push for JDK-8076182 caused a build break, i.e. a
> problem for
> the creation of the Javadoc in the environment used by the
> nightly
> build.  This was because a newly opened package
> com.sun.java.accessibility.util was mistakenly located in a
> windows
> directory.  This patch moves the package's files from
> jdk/src/windows/classes to jdk/src/share/classes and this should
> resolve
> the build break for the jdk8u-dev nightly.
>
> JPRT builds run OK on solaris, mac, and linux.  As of this
> writing the
> Win jobs haven't started yet but the 64 bit build completed OK
> on my
> local machine.
>
> This patch also had to include the fix for JDK-8051297 "Remove
> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
> file
> is dead code and its existence in jdk/src/share/classes causes a
> compilation failure, access of a non-existent enum, the reason
> the
> file
> was planned to be removed.
>
> Thanks, Pete
>
>
>

Re: RfR JDK-8076552 nightly build break fix

[Lana Steuck]

Hi Pete,

Sean said 'your fix will go via 8u-dev' - is this the case?

Or are we planning on pushing your changes to 8u Master directly (after 
proper build/test)?


Do you have a forest on nfs? (from where I can pull/clone your fixes)?

- Lana


On 04/08/2015 11:08 AM, Pete Brunet wrote:

I confirmed the javadoc is gone, and make docs did not fail.

I have yet to submit the JPRT job.

Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
you approve the push?

Phil will have to do the push; my committer status is pending.

Pete

On 4/8/15 1:00 PM, Phil Race wrote:

That looks good to me.

-phil.

On 4/8/2015 10:55 AM, Pete Brunet wrote:

How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03

On 4/8/15 12:47 PM, Mandy Chung wrote:

I agree with Phil's suggestion and file a bug to follow up the javadoc
build issue.

You can verify the result from make docs that there is no javadoc
generated for this package on windows build.

Mandy

On 4/8/2015 10:29 AM, Phil Race wrote:

Isn't it sufficient to comment out this one line ?

1215 ALL_OTHER_TARGETS += jaccessdocs

.. and add a comment as to why ?

-phil.


On 04/08/2015 10:25 AM, Pete Brunet wrote:

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:

Please review/approve the following patch.

http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

The recent push for JDK-8076182 caused a build break, i.e. a
problem for
the creation of the Javadoc in the environment used by the nightly
build.  This was because a newly opened package
com.sun.java.accessibility.util was mistakenly located in a windows
directory.  This patch moves the package's files from
jdk/src/windows/classes to jdk/src/share/classes and this should
resolve
the build break for the jdk8u-dev nightly.

JPRT builds run OK on solaris, mac, and linux.  As of this
writing the
Win jobs haven't started yet but the 64 bit build completed OK on my
local machine.

This patch also had to include the fix for JDK-8051297 "Remove
com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
file
is dead code and its existence in jdk/src/share/classes causes a
compilation failure, access of a non-existent enum, the reason the
file
was planned to be removed.

Thanks, Pete

Re: RfR JDK-8076552 nightly build break fix

[Pete Brunet]

Phil will do the push.  I assume it needs to go to 8u-dev.

On 4/8/15 1:38 PM, Lana Steuck wrote:
> Hi Pete,
>
> Sean said 'your fix will go via 8u-dev' - is this the case?
>
> Or are we planning on pushing your changes to 8u Master directly
> (after proper build/test)?
>
> Do you have a forest on nfs? (from where I can pull/clone your fixes)?
>
> - Lana
>
>
> On 04/08/2015 11:08 AM, Pete Brunet wrote:
>> I confirmed the javadoc is gone, and make docs did not fail.
>>
>> I have yet to submit the JPRT job.
>>
>> Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
>> you approve the push?
>>
>> Phil will have to do the push; my committer status is pending.
>>
>> Pete
>>
>> On 4/8/15 1:00 PM, Phil Race wrote:
>>> That looks good to me.
>>>
>>> -phil.
>>>
>>> On 4/8/2015 10:55 AM, Pete Brunet wrote:
 How's this?
 http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03

 On 4/8/15 12:47 PM, Mandy Chung wrote:
> I agree with Phil's suggestion and file a bug to follow up the
> javadoc
> build issue.
>
> You can verify the result from make docs that there is no javadoc
> generated for this package on windows build.
>
> Mandy
>
> On 4/8/2015 10:29 AM, Phil Race wrote:
>> Isn't it sufficient to comment out this one line ?
>>
>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>
>> .. and add a comment as to why ?
>>
>> -phil.
>>
>>
>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>> Here is an updated patch.
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>
>>> It simply removes the com.sun.java.accessibility.util part of the
>>> javadoc generation.
>>>
>>> How to better deal with the javadoc generation can be left to
>>> later.
>>>
>>> Please let me know if this patch meets with your approval.
>>>
>>> I have started a local Win build and will start JPRT builds on
>>> Linux,
>>> Windows, Solaris, and Mac shortly.
>>>
>>> Thanks,
>>> Pete
>>>
>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
 Please review/approve the following patch.

 http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

 The recent push for JDK-8076182 caused a build break, i.e. a
 problem for
 the creation of the Javadoc in the environment used by the nightly
 build.  This was because a newly opened package
 com.sun.java.accessibility.util was mistakenly located in a
 windows
 directory.  This patch moves the package's files from
 jdk/src/windows/classes to jdk/src/share/classes and this should
 resolve
 the build break for the jdk8u-dev nightly.

 JPRT builds run OK on solaris, mac, and linux.  As of this
 writing the
 Win jobs haven't started yet but the 64 bit build completed OK
 on my
 local machine.

 This patch also had to include the fix for JDK-8051297 "Remove
 com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
 file
 is dead code and its existence in jdk/src/share/classes causes a
 compilation failure, access of a non-existent enum, the reason the
 file
 was planned to be removed.

 Thanks, Pete


>

Re: RfR JDK-8076552 nightly build break fix

[Seán Coffey]

Pete,

http://openjdk.java.net/projects/jdk8u/groundrules.html
Rule 1. What are your plans for JDK 9 ? Is that family affected ? If not 
- add '9-na' label to bug report.


Rule 4. Approval requests should be carried out on jdk8u-dev mailing list.

regards,
Sean.

On 08/04/2015 19:14, Pete Brunet wrote:

resending - too many on To:/Cc:

On 4/8/15 1:08 PM, Pete Brunet wrote:

I confirmed the javadoc is gone, and make docs did not fail.

I have yet to submit the JPRT job.

Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
you approve the push?

Phil will have to do the push; my committer status is pending.

Pete

On 4/8/15 1:00 PM, Phil Race wrote:

That looks good to me.

-phil.

On 4/8/2015 10:55 AM, Pete Brunet wrote:

How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03

On 4/8/15 12:47 PM, Mandy Chung wrote:

I agree with Phil's suggestion and file a bug to follow up the javadoc
build issue.

You can verify the result from make docs that there is no javadoc
generated for this package on windows build.

Mandy

On 4/8/2015 10:29 AM, Phil Race wrote:

Isn't it sufficient to comment out this one line ?

1215 ALL_OTHER_TARGETS += jaccessdocs

.. and add a comment as to why ?

-phil.


On 04/08/2015 10:25 AM, Pete Brunet wrote:

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:

Please review/approve the following patch.

http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

The recent push for JDK-8076182 caused a build break, i.e. a
problem for
the creation of the Javadoc in the environment used by the nightly
build.  This was because a newly opened package
com.sun.java.accessibility.util was mistakenly located in a windows
directory.  This patch moves the package's files from
jdk/src/windows/classes to jdk/src/share/classes and this should
resolve
the build break for the jdk8u-dev nightly.

JPRT builds run OK on solaris, mac, and linux.  As of this
writing the
Win jobs haven't started yet but the 64 bit build completed OK on my
local machine.

This patch also had to include the fix for JDK-8051297 "Remove
com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
file
is dead code and its existence in jdk/src/share/classes causes a
compilation failure, access of a non-existent enum, the reason the
file
was planned to be removed.

Thanks, Pete

Re: RfR JDK-8076552 nightly build break fix

[Pete Brunet]

I confirmed the javadoc is gone, and make docs did not fail.

I have yet to submit the JPRT job.

Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
you approve the push?

Phil will have to do the push; my committer status is pending.

Pete

On 4/8/15 1:00 PM, Phil Race wrote:
> That looks good to me.
>
> -phil.
>
> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>> How's this?
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>
>> On 4/8/15 12:47 PM, Mandy Chung wrote:
>>> I agree with Phil's suggestion and file a bug to follow up the javadoc
>>> build issue.
>>>
>>> You can verify the result from make docs that there is no javadoc
>>> generated for this package on windows build.
>>>
>>> Mandy
>>>
>>> On 4/8/2015 10:29 AM, Phil Race wrote:
 Isn't it sufficient to comment out this one line ?

 1215 ALL_OTHER_TARGETS += jaccessdocs

 .. and add a comment as to why ?

 -phil.


 On 04/08/2015 10:25 AM, Pete Brunet wrote:
> Here is an updated patch.
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>
> It simply removes the com.sun.java.accessibility.util part of the
> javadoc generation.
>
> How to better deal with the javadoc generation can be left to later.
>
> Please let me know if this patch meets with your approval.
>
> I have started a local Win build and will start JPRT builds on Linux,
> Windows, Solaris, and Mac shortly.
>
> Thanks,
> Pete
>
> On 4/8/15 12:51 AM, Pete Brunet wrote:
>> Please review/approve the following patch.
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>
>> The recent push for JDK-8076182 caused a build break, i.e. a
>> problem for
>> the creation of the Javadoc in the environment used by the nightly
>> build.  This was because a newly opened package
>> com.sun.java.accessibility.util was mistakenly located in a windows
>> directory.  This patch moves the package's files from
>> jdk/src/windows/classes to jdk/src/share/classes and this should
>> resolve
>> the build break for the jdk8u-dev nightly.
>>
>> JPRT builds run OK on solaris, mac, and linux.  As of this
>> writing the
>> Win jobs haven't started yet but the 64 bit build completed OK on my
>> local machine.
>>
>> This patch also had to include the fix for JDK-8051297 "Remove
>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
>> file
>> is dead code and its existence in jdk/src/share/classes causes a
>> compilation failure, access of a non-existent enum, the reason the
>> file
>> was planned to be removed.
>>
>> Thanks, Pete
>>
>>
>

Re: RfR JDK-8076552 nightly build break fix

[Mandy Chung]

+1

Mandy

On 4/8/2015 11:00 AM, Phil Race wrote:

That looks good to me.

-phil.

On 4/8/2015 10:55 AM, Pete Brunet wrote:

How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03

On 4/8/15 12:47 PM, Mandy Chung wrote:

I agree with Phil's suggestion and file a bug to follow up the javadoc
build issue.

You can verify the result from make docs that there is no javadoc
generated for this package on windows build.

Mandy

On 4/8/2015 10:29 AM, Phil Race wrote:

Isn't it sufficient to comment out this one line ?

1215 ALL_OTHER_TARGETS += jaccessdocs

.. and add a comment as to why ?

-phil.


On 04/08/2015 10:25 AM, Pete Brunet wrote:

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:

Please review/approve the following patch.

http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

The recent push for JDK-8076182 caused a build break, i.e. a
problem for
the creation of the Javadoc in the environment used by the nightly
build.  This was because a newly opened package
com.sun.java.accessibility.util was mistakenly located in a windows
directory.  This patch moves the package's files from
jdk/src/windows/classes to jdk/src/share/classes and this should
resolve
the build break for the jdk8u-dev nightly.

JPRT builds run OK on solaris, mac, and linux.  As of this 
writing the

Win jobs haven't started yet but the 64 bit build completed OK on my
local machine.

This patch also had to include the fix for JDK-8051297 "Remove
com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That 
file

is dead code and its existence in jdk/src/share/classes causes a
compilation failure, access of a non-existent enum, the reason the
file
was planned to be removed.

Thanks, Pete

Re: RfR JDK-8076552 nightly build break fix

[Pete Brunet]

resending - too many on To:/Cc:

On 4/8/15 1:08 PM, Pete Brunet wrote:
> I confirmed the javadoc is gone, and make docs did not fail.
>
> I have yet to submit the JPRT job.
>
> Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
> you approve the push?
>
> Phil will have to do the push; my committer status is pending.
>
> Pete
>
> On 4/8/15 1:00 PM, Phil Race wrote:
>> That looks good to me.
>>
>> -phil.
>>
>> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>>> How's this?
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>>
>>> On 4/8/15 12:47 PM, Mandy Chung wrote:
 I agree with Phil's suggestion and file a bug to follow up the javadoc
 build issue.

 You can verify the result from make docs that there is no javadoc
 generated for this package on windows build.

 Mandy

 On 4/8/2015 10:29 AM, Phil Race wrote:
> Isn't it sufficient to comment out this one line ?
>
> 1215 ALL_OTHER_TARGETS += jaccessdocs
>
> .. and add a comment as to why ?
>
> -phil.
>
>
> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>> Here is an updated patch.
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>
>> It simply removes the com.sun.java.accessibility.util part of the
>> javadoc generation.
>>
>> How to better deal with the javadoc generation can be left to later.
>>
>> Please let me know if this patch meets with your approval.
>>
>> I have started a local Win build and will start JPRT builds on Linux,
>> Windows, Solaris, and Mac shortly.
>>
>> Thanks,
>> Pete
>>
>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>> Please review/approve the following patch.
>>>
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>
>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>> problem for
>>> the creation of the Javadoc in the environment used by the nightly
>>> build.  This was because a newly opened package
>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>> directory.  This patch moves the package's files from
>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>> resolve
>>> the build break for the jdk8u-dev nightly.
>>>
>>> JPRT builds run OK on solaris, mac, and linux.  As of this
>>> writing the
>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>> local machine.
>>>
>>> This patch also had to include the fix for JDK-8051297 "Remove
>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
>>> file
>>> is dead code and its existence in jdk/src/share/classes causes a
>>> compilation failure, access of a non-existent enum, the reason the
>>> file
>>> was planned to be removed.
>>>
>>> Thanks, Pete
>>>
>>>

Re: RfR JDK-8076552 nightly build break fix

[Phil Race]

That looks good to me.

-phil.

On 4/8/2015 10:55 AM, Pete Brunet wrote:

How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03

On 4/8/15 12:47 PM, Mandy Chung wrote:

I agree with Phil's suggestion and file a bug to follow up the javadoc
build issue.

You can verify the result from make docs that there is no javadoc
generated for this package on windows build.

Mandy

On 4/8/2015 10:29 AM, Phil Race wrote:

Isn't it sufficient to comment out this one line ?

1215 ALL_OTHER_TARGETS += jaccessdocs

.. and add a comment as to why ?

-phil.


On 04/08/2015 10:25 AM, Pete Brunet wrote:

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:

Please review/approve the following patch.

http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

The recent push for JDK-8076182 caused a build break, i.e. a
problem for
the creation of the Javadoc in the environment used by the nightly
build.  This was because a newly opened package
com.sun.java.accessibility.util was mistakenly located in a windows
directory.  This patch moves the package's files from
jdk/src/windows/classes to jdk/src/share/classes and this should
resolve
the build break for the jdk8u-dev nightly.

JPRT builds run OK on solaris, mac, and linux.  As of this writing the
Win jobs haven't started yet but the 64 bit build completed OK on my
local machine.

This patch also had to include the fix for JDK-8051297 "Remove
com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That file
is dead code and its existence in jdk/src/share/classes causes a
compilation failure, access of a non-existent enum, the reason the
file
was planned to be removed.

Thanks, Pete

Re: RfR JDK-8076552 nightly build break fix

[Pete Brunet]

How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03

On 4/8/15 12:47 PM, Mandy Chung wrote:
> I agree with Phil's suggestion and file a bug to follow up the javadoc
> build issue.
>
> You can verify the result from make docs that there is no javadoc
> generated for this package on windows build.
>
> Mandy
>
> On 4/8/2015 10:29 AM, Phil Race wrote:
>> Isn't it sufficient to comment out this one line ?
>>
>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>
>> .. and add a comment as to why ?
>>
>> -phil.
>>
>>
>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>> Here is an updated patch.
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>
>>> It simply removes the com.sun.java.accessibility.util part of the
>>> javadoc generation.
>>>
>>> How to better deal with the javadoc generation can be left to later.
>>>
>>> Please let me know if this patch meets with your approval.
>>>
>>> I have started a local Win build and will start JPRT builds on Linux,
>>> Windows, Solaris, and Mac shortly.
>>>
>>> Thanks,
>>> Pete
>>>
>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
 Please review/approve the following patch.

 http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

 The recent push for JDK-8076182 caused a build break, i.e. a
 problem for
 the creation of the Javadoc in the environment used by the nightly
 build.  This was because a newly opened package
 com.sun.java.accessibility.util was mistakenly located in a windows
 directory.  This patch moves the package's files from
 jdk/src/windows/classes to jdk/src/share/classes and this should
 resolve
 the build break for the jdk8u-dev nightly.

 JPRT builds run OK on solaris, mac, and linux.  As of this writing the
 Win jobs haven't started yet but the 64 bit build completed OK on my
 local machine.

 This patch also had to include the fix for JDK-8051297 "Remove
 com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That file
 is dead code and its existence in jdk/src/share/classes causes a
 compilation failure, access of a non-existent enum, the reason the
 file
 was planned to be removed.

 Thanks, Pete


>>
>

Re: RfR JDK-8076552 nightly build break fix

[Mandy Chung]

I agree with Phil's suggestion and file a bug to follow up the javadoc 
build issue.


You can verify the result from make docs that there is no javadoc 
generated for this package on windows build.


Mandy

On 4/8/2015 10:29 AM, Phil Race wrote:

Isn't it sufficient to comment out this one line ?

1215 ALL_OTHER_TARGETS += jaccessdocs

.. and add a comment as to why ?

-phil.


On 04/08/2015 10:25 AM, Pete Brunet wrote:

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:

Please review/approve the following patch.

http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

The recent push for JDK-8076182 caused a build break, i.e. a problem 
for

the creation of the Javadoc in the environment used by the nightly
build.  This was because a newly opened package
com.sun.java.accessibility.util was mistakenly located in a windows
directory.  This patch moves the package's files from
jdk/src/windows/classes to jdk/src/share/classes and this should 
resolve

the build break for the jdk8u-dev nightly.

JPRT builds run OK on solaris, mac, and linux.  As of this writing the
Win jobs haven't started yet but the 64 bit build completed OK on my
local machine.

This patch also had to include the fix for JDK-8051297 "Remove
com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That file
is dead code and its existence in jdk/src/share/classes causes a
compilation failure, access of a non-existent enum, the reason the file
was planned to be removed.

Thanks, Pete

Re: RfR JDK-8076552 nightly build break fix

[Pete Brunet]

On 4/8/15 12:29 PM, Phil Race wrote:
> Isn't it sufficient to comment out this one line ?
>
> 1215 ALL_OTHER_TARGETS += jaccessdocs
>
> .. and add a comment as to why ?
I'm not familiar with this make file so I took the straightforward
approach.

If you are confident that will work I'll redo the patch.  Let me know.
>
> -phil.
>
>
> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>> Here is an updated patch.
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>
>> It simply removes the com.sun.java.accessibility.util part of the
>> javadoc generation.
>>
>> How to better deal with the javadoc generation can be left to later.
>>
>> Please let me know if this patch meets with your approval.
>>
>> I have started a local Win build and will start JPRT builds on Linux,
>> Windows, Solaris, and Mac shortly.
>>
>> Thanks,
>> Pete
>>
>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>> Please review/approve the following patch.
>>>
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>
>>> The recent push for JDK-8076182 caused a build break, i.e. a problem
>>> for
>>> the creation of the Javadoc in the environment used by the nightly
>>> build.  This was because a newly opened package
>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>> directory.  This patch moves the package's files from
>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>> resolve
>>> the build break for the jdk8u-dev nightly.
>>>
>>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>> local machine.
>>>
>>> This patch also had to include the fix for JDK-8051297 "Remove
>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
>>> is dead code and its existence in jdk/src/share/classes causes a
>>> compilation failure, access of a non-existent enum, the reason the file
>>> was planned to be removed.
>>>
>>> Thanks, Pete
>>>
>>>
>

Re: RfR JDK-8076552 nightly build break fix

[Phil Race]

Isn't it sufficient to comment out this one line ?

1215 ALL_OTHER_TARGETS += jaccessdocs

.. and add a comment as to why ?

-phil.


On 04/08/2015 10:25 AM, Pete Brunet wrote:

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:

Please review/approve the following patch.

http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

The recent push for JDK-8076182 caused a build break, i.e. a problem for
the creation of the Javadoc in the environment used by the nightly
build.  This was because a newly opened package
com.sun.java.accessibility.util was mistakenly located in a windows
directory.  This patch moves the package's files from
jdk/src/windows/classes to jdk/src/share/classes and this should resolve
the build break for the jdk8u-dev nightly.

JPRT builds run OK on solaris, mac, and linux.  As of this writing the
Win jobs haven't started yet but the 64 bit build completed OK on my
local machine.

This patch also had to include the fix for JDK-8051297 "Remove
com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
is dead code and its existence in jdk/src/share/classes causes a
compilation failure, access of a non-existent enum, the reason the file
was planned to be removed.

Thanks, Pete

Re: RfR JDK-8076552 nightly build break fix

[Pete Brunet]

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:
> Please review/approve the following patch.
>
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>
> The recent push for JDK-8076182 caused a build break, i.e. a problem for
> the creation of the Javadoc in the environment used by the nightly
> build.  This was because a newly opened package
> com.sun.java.accessibility.util was mistakenly located in a windows
> directory.  This patch moves the package's files from
> jdk/src/windows/classes to jdk/src/share/classes and this should resolve
> the build break for the jdk8u-dev nightly.
>
> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
> Win jobs haven't started yet but the 64 bit build completed OK on my
> local machine.
>
> This patch also had to include the fix for JDK-8051297 "Remove
> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
> is dead code and its existence in jdk/src/share/classes causes a
> compilation failure, access of a non-existent enum, the reason the file
> was planned to be removed.
>
> Thanks, Pete
>
>

Re: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9

[Mandy Chung]

On 4/8/2015 3:21 AM, Staffan Larsen wrote:

Please review these small changes to support an addition of closed code to the 
java.instrument module.

webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ 



The change looks fine.

Mandy

Re: RfR JDK-8076552 nightly build break fix

[Pete Brunet]

On 4/8/15 1:22 AM, David Holmes wrote:
> Pete,
>
> I think Erik's suggestion in the bug report is more appropriate. If
> this is only a source bundle issue then the build instructions for
> javadoc should either be Windows specific, or else check for source
> existence.
David, Considering that the source should be in jdk/src/share/classes
does that change things?  -Pete
>
> David
>
> On 8/04/2015 3:51 PM, Pete Brunet wrote:
>> Please review/approve the following patch.
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>
>> The recent push for JDK-8076182 caused a build break, i.e. a problem for
>> the creation of the Javadoc in the environment used by the nightly
>> build.  This was because a newly opened package
>> com.sun.java.accessibility.util was mistakenly located in a windows
>> directory.  This patch moves the package's files from
>> jdk/src/windows/classes to jdk/src/share/classes and this should resolve
>> the build break for the jdk8u-dev nightly.
>>
>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>> Win jobs haven't started yet but the 64 bit build completed OK on my
>> local machine.
>>
>> This patch also had to include the fix for JDK-8051297 "Remove
>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
>> is dead code and its existence in jdk/src/share/classes causes a
>> compilation failure, access of a non-existent enum, the reason the file
>> was planned to be removed.
>>
>> Thanks, Pete
>>
>>

Re: RfR JDK-8076552 nightly build break fix

[Pete Brunet]

Hi Mandy, com.sun.java.accessibility.util can be used on other
platforms.  com.sun.java.accessibility is Win only.  -Pete

On 4/8/15 1:06 AM, Mandy Chung wrote:
> This API is only available on windows but not other platforms.  I
> think src/windows/classes is the right location.
>
> Mandy
>
> On 4/7/2015 10:51 PM, Pete Brunet wrote:
>> Please review/approve the following patch.
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>
>> The recent push for JDK-8076182 caused a build break, i.e. a problem for
>> the creation of the Javadoc in the environment used by the nightly
>> build.  This was because a newly opened package
>> com.sun.java.accessibility.util was mistakenly located in a windows
>> directory.  This patch moves the package's files from
>> jdk/src/windows/classes to jdk/src/share/classes and this should resolve
>> the build break for the jdk8u-dev nightly.
>>
>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>> Win jobs haven't started yet but the 64 bit build completed OK on my
>> local machine.
>>
>> This patch also had to include the fix for JDK-8051297 "Remove
>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
>> is dead code and its existence in jdk/src/share/classes causes a
>> compilation failure, access of a non-existent enum, the reason the file
>> was planned to be removed.
>>
>> Thanks, Pete
>>
>>
>

Re: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9

[Erik Joelsson]

Looks good to me.

/Erik

On 2015-04-08 12:21, Staffan Larsen wrote:

Please review these small changes to support an addition of closed code to the 
java.instrument module.

webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ 


Thanks,
/Staffan

RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9

[Staffan Larsen]

Please review these small changes to support an addition of closed code to the 
java.instrument module.

webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ 


Thanks,
/Staffan

Re: RFR: JDK-8073634: Improve clean targets

[Erik Joelsson]

Hello,

New webrev: http://cr.openjdk.java.net/~erikj/8073634/webrev.02/

On 2015-04-07 13:26, Magnus Ihse Bursie wrote:

In general it looks good. I have a couple of remarks, though.

1) In Clean-docs, you do:
+$(RM) -r $(SUPPORT_OUTPUTDIR)/docs
+$(RM) -r $(IMAGES_OUTPUTDIR)/docs

I'm not quite certain cleaning images/docs the right thing to do. For 
all other clean targets, we only clean the support part. If we want to 
clean images, we run clean-images. And if you think this is the right 
thing to do for images, wouldn't it then also be the right thing for 
e.g. java.base-native? And then things quickly become complicated.


The docs target generates docs directly into images. The directory in 
support is for temporary/intermediate files. Building to support and 
then just copy it all over to images seems like a waste of both time and 
disk space. Also note that the clean targets aren't mutually exclusive 
today. You can for example do clean-support or you can do clean-java.base.
2) The new configure-support, as well as the rather new make-support 
seems to be a bit unfairly treated. There is a MAKESUPPORT_OUTPUTDIR 
in spec.gmk but it's hardcoded there, so you can't use it in 
configure, e.g. in your changes in build-performance.m4. The new 
configure-support does not even have a corresponding 
CONFIGURESUPPORT_OUTPUTDIR in the spec.gmk. Instead, it has a variable 
CONFIGURE_SUPPORT that is present only in the configure files.


I'm not sure how much, if anything, of these inconsistencies that 
should be fixed now. But I'd suggest that you rename CONFIGURE_SUPPORT 
to CONFIGURESUPPORT_OUTPUTDIR at the very least. (Or, maybe, 
MAKESUPPORT_OUTPUTDIR should be MAKE_SUPPORT_OUTPUTDIR.)


Renamed to CONFIGURESUPPORT_OUTPUTDIR and put it in spec. Removed 
reference to make-support in configure and put the single use directly 
in spec.gmk.in instead. There is no need for configure to know about the 
sjavacservers dir. Changed dist-clean in Main.gmk to use the variable 
CONFIGURESUPPORT_OUTPUTDIR.


/Erik