Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Andrew Haley]

On 4/29/20 5:12 AM, Mikael Vidstedt wrote:
> Please review this small change which disables JVMCI, Graal, and AOT when 
> building linux-aarch64 at Oracle, for now.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
> webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/

Why? Are there problems with it? If so, I need bug reports.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Magnus Ihse Bursie]

On 2020-04-29 06:12, Mikael Vidstedt wrote:

Please review this small change which disables JVMCI, Graal, and AOT when 
building linux-aarch64 at Oracle, for now.

JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/

LGTM.

/Magnus


Cheers,
Mikael

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Doug Simon]

If I understand correctly, this disables building jvmci/graal/aot in *any* 
linux-aarch64 jib based build, not just those done at Oracle. Wouldn’t this be 
better done on the jib command line?

-Doug

> On 29 Apr 2020, at 06:12, Mikael Vidstedt  wrote:
> 
> 
> Please review this small change which disables JVMCI, Graal, and AOT when 
> building linux-aarch64 at Oracle, for now.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
> webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
> 
> Cheers,
> Mikael
> 

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Mikael Vidstedt]

JIB is an Oracle (internal) tool, meaning the jib-profiles.js configuration 
file is only relevant at Oracle, so this really only affects builds done at 
Oracle. Does that address your concern?

Cheers,
Mikael

> On Apr 29, 2020, at 1:45 AM, Doug Simon  wrote:
> 
> If I understand correctly, this disables building jvmci/graal/aot in *any* 
> linux-aarch64 jib based build, not just those done at Oracle. Wouldn’t this 
> be better done on the jib command line?
> 
> -Doug
> 
>> On 29 Apr 2020, at 06:12, Mikael Vidstedt  wrote:
>> 
>> 
>> Please review this small change which disables JVMCI, Graal, and AOT when 
>> building linux-aarch64 at Oracle, for now.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
>> 
>> Cheers,
>> Mikael
>> 
> 

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Mikael Vidstedt]

> On Apr 29, 2020, at 12:46 AM, Andrew Haley  wrote:
> 
> On 4/29/20 5:12 AM, Mikael Vidstedt wrote:
>> Please review this small change which disables JVMCI, Graal, and AOT when 
>> building linux-aarch64 at Oracle, for now.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
> 
> Why? Are there problems with it? If so, I need bug reports.

No specific problems or bugs that I’m aware of. We’re simply opting not to 
include Graal/JVMTI/AOT in the linux-aarch64 builds we do at Oracle, for now.

Cheers,
Mikael

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Magnus Ihse Bursie]

On 2020-04-29 10:45, Doug Simon wrote:

If I understand correctly, this disables building jvmci/graal/aot in *any* 
linux-aarch64 jib based build, not just those done at Oracle. Wouldn’t this be 
better done on the jib command line?
While this is technically correct, the jib tool is only used at Oracle, 
so in practice, this is the same thing.


If/when some other party of the community starts using the jib 
configuration (instead of creating their own), that will be a relevant 
feedback.


/Magnus


-Doug


On 29 Apr 2020, at 06:12, Mikael Vidstedt  wrote:


Please review this small change which disables JVMCI, Graal, and AOT when 
building linux-aarch64 at Oracle, for now.

JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/

Cheers,
Mikael

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Doug Simon]

Ok, thanks for the clarification. I wasn’t sure if external parties had managed 
to set up a jib server but it sounds like that’s not so easy in practice.

-Doug

> On 29 Apr 2020, at 11:02, Magnus Ihse Bursie  
> wrote:
> 
> On 2020-04-29 10:45, Doug Simon wrote:
>> If I understand correctly, this disables building jvmci/graal/aot in *any* 
>> linux-aarch64 jib based build, not just those done at Oracle. Wouldn’t this 
>> be better done on the jib command line?
> While this is technically correct, the jib tool is only used at Oracle, so in 
> practice, this is the same thing.
> 
> If/when some other party of the community starts using the jib configuration 
> (instead of creating their own), that will be a relevant feedback.
> 
> /Magnus
>> 
>> -Doug
>> 
>>> On 29 Apr 2020, at 06:12, Mikael Vidstedt  
>>> wrote:
>>> 
>>> 
>>> Please review this small change which disables JVMCI, Graal, and AOT when 
>>> building linux-aarch64 at Oracle, for now.
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
>>> webrev: 
>>> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
>>> 
>>> Cheers,
>>> Mikael
>>> 
> 

RFR: JDK-8243665 exploded-image-optimize touches module-info.class in all modules

[Magnus Ihse Bursie]

Due to the current design of the AddPackagesAttribute build tool, all 
module-info.class files will be written to, when the tool is run. This 
happens whenever at least one module-info.class file has been updated. 
The end result of this is that if you recompile a single module, *all* 
modules will be touch, forcing jmod to repackage all of them.


This fix did not initially work, since the jmod generation was 
non-deterministic, but that has gracefully been fixed by Alan in 
JDK-8243666.


Bug: https://bugs.openjdk.java.net/browse/JDK-8243665
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8243665-fix-AddPackagesAttribute/webrev.01


/Magnus

Re: RFR: JDK-8243665 exploded-image-optimize touches module-info.class in all modules

[Alan Bateman]

On 29/04/2020 10:27, Magnus Ihse Bursie wrote:
Due to the current design of the AddPackagesAttribute build tool, all 
module-info.class files will be written to, when the tool is run. This 
happens whenever at least one module-info.class file has been updated. 
The end result of this is that if you recompile a single module, *all* 
modules will be touch, forcing jmod to repackage all of them.


This fix did not initially work, since the jmod generation was 
non-deterministic, but that has gracefully been fixed by Alan in 
JDK-8243666.


Bug: https://bugs.openjdk.java.net/browse/JDK-8243665
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8243665-fix-AddPackagesAttribute/webrev.01
The indentation should be 4 spaces rather than 2, otherwise the 
Arrays.equals check looks okay. Are you sure you want the "Writing to " 
noise?


-Alan

RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Magnus Ihse Bursie]

The IDE support in OpenJDK unfortunately leaves a lot to be desired. 
There have been a garden variety of attempt to support a specific IDE 
for a specific part of the code base, cluttered all over the code base.


This patch is a first attempt go get one ring, eh..., structure, to rule 
them all.


I have moved all IDE project creators into the following structure:

make/ide//

where  is one of currently "hotspot", "langtools" or 
"jdk", and  is one of "vscode", "idea", "netbeans" or "vistualstudio".


This will not magically improve IDE support, but will at least make it 
clearer what we have and what we are missing.


Ownership of the IDE support is notoriously vague. I've cc:ed a bunch of 
people who has shown interest and/or submitted fixes to some of the IDE 
projects according to the hg history. I'd appreciate it if anyone who is 
interested in a particular case for IDE support can verify that it still 
works. I've tried my best to make sure all targets can run without 
errors, but I cannot verify that the IDE environment themselves are correct.


If you know about an IDE project that is no longer relevant, and should 
be removed instead of shuffled around, please let me know!


Bug: https://bugs.openjdk.java.net/browse/JDK-8244093
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8244093-move-ide-support/webrev.01


/Magnus

Re: RFR: JDK-8243665 exploded-image-optimize touches module-info.class in all modules

[Magnus Ihse Bursie]

On 2020-04-29 12:31, Alan Bateman wrote:



On 29/04/2020 10:27, Magnus Ihse Bursie wrote:
Due to the current design of the AddPackagesAttribute build tool, all 
module-info.class files will be written to, when the tool is run. 
This happens whenever at least one module-info.class file has been 
updated. The end result of this is that if you recompile a single 
module, *all* modules will be touch, forcing jmod to repackage all of 
them.


This fix did not initially work, since the jmod generation was 
non-deterministic, but that has gracefully been fixed by Alan in 
JDK-8243666.


Bug: https://bugs.openjdk.java.net/browse/JDK-8243665
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8243665-fix-AddPackagesAttribute/webrev.01
The indentation should be 4 spaces rather than 2, otherwise the 
Arrays.equals check looks okay. 

Of course. Getting damaged from all the makefile nonsense. :)

Are you sure you want the "Writing to " noise?


Oops! No, that was just a debug message left over. How embarrassing! :)

New try:

http://cr.openjdk.java.net/~ihse/JDK-8243665-fix-AddPackagesAttribute/webrev.02

/Magnus


-Alan

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Andrew Haley]

On 4/29/20 10:02 AM, Mikael Vidstedt wrote:
> 
>> On Apr 29, 2020, at 12:46 AM, Andrew Haley  wrote:
>>
>> On 4/29/20 5:12 AM, Mikael Vidstedt wrote:
>>> Please review this small change which disables JVMCI, Graal, and AOT when 
>>> building linux-aarch64 at Oracle, for now.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
>>> webrev: 
>>> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
>>
>> Why? Are there problems with it? If so, I need bug reports.
> 
> No specific problems or bugs that I’m aware of. We’re simply opting not to 
> include Graal/JVMTI/AOT in the linux-aarch64 builds we do at Oracle, for now.

Cool, NP. Obvs. I'd prefer it if y'all built and tested it all,
but fair enough.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR: JDK-8243665 exploded-image-optimize touches module-info.class in all modules

[Alan Bateman]

On 29/04/2020 11:40, Magnus Ihse Bursie wrote:

:

http://cr.openjdk.java.net/~ihse/JDK-8243665-fix-AddPackagesAttribute/webrev.02 

Looks good. It could be optimized to only read the module-info.class 
once but will hardly be noticeable I suspect.


-Alan

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Maurizio Cimadamore]

Didn't review in detail, but some pieces seems suspicious - e.g.

moving "/make/langtools/build.properties" to 
"///make/ide/idea/langtools/build.properties//


Note that langtools's build.properties is used by the langtools ANT 
build which is independent from make - and also mostly independent from 
the IDE. It just provides an ANT target to create the necessary IDE 
files. So, if you want you can move the IDE templates in the new folder, 
but the build script and properties should remain where they are, I think.


Maurizio

On 29/04/2020 11:36, Magnus Ihse Bursie wrote:
The IDE support in OpenJDK unfortunately leaves a lot to be desired. 
There have been a garden variety of attempt to support a specific IDE 
for a specific part of the code base, cluttered all over the code base.


This patch is a first attempt go get one ring, eh..., structure, to 
rule them all.


I have moved all IDE project creators into the following structure:

make/ide//

where  is one of currently "hotspot", "langtools" or 
"jdk", and  is one of "vscode", "idea", "netbeans" or 
"vistualstudio".


This will not magically improve IDE support, but will at least make it 
clearer what we have and what we are missing.


Ownership of the IDE support is notoriously vague. I've cc:ed a bunch 
of people who has shown interest and/or submitted fixes to some of the 
IDE projects according to the hg history. I'd appreciate it if anyone 
who is interested in a particular case for IDE support can verify that 
it still works. I've tried my best to make sure all targets can run 
without errors, but I cannot verify that the IDE environment 
themselves are correct.


If you know about an IDE project that is no longer relevant, and 
should be removed instead of shuffled around, please let me know!


Bug: https://bugs.openjdk.java.net/browse/JDK-8244093
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8244093-move-ide-support/webrev.01


/Magnus

Re: RFR: JDK-8243665 exploded-image-optimize touches module-info.class in all modules

[Magnus Ihse Bursie]

On 2020-04-29 12:47, Alan Bateman wrote:



On 29/04/2020 11:40, Magnus Ihse Bursie wrote:

:

http://cr.openjdk.java.net/~ihse/JDK-8243665-fix-AddPackagesAttribute/webrev.02 


Looks good.

Thanks.
It could be optimized to only read the module-info.class once but will 
hardly be noticeable I suspect.
It could possibly also be optimized by only running on those modules 
which has changed, if it could get better cooperation with the build 
system. :-) But I'll leave it at this for now.


/Magnus



-Alan

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Magnus Ihse Bursie]

On 2020-04-29 12:47, Maurizio Cimadamore wrote:


Didn't review in detail, but some pieces seems suspicious - e.g.

moving "/make/langtools/build.properties" to 
"///make/ide/idea/langtools/build.properties//


Note that langtools's build.properties is used by the langtools ANT 
build which is independent from make - and also mostly independent 
from the IDE. It just provides an ANT target to create the necessary 
IDE files. So, if you want you can move the IDE templates in the new 
folder, but the build script and properties should remain where they 
are, I think.
So who/what is using the ant build? I thought it was just the IDEA 
project that generated ant targets. Is it run explicitly using ant by 
langtool developers? I know for sure it's not used when we build the 
product in our CI.


/Magnus



Maurizio

On 29/04/2020 11:36, Magnus Ihse Bursie wrote:
The IDE support in OpenJDK unfortunately leaves a lot to be desired. 
There have been a garden variety of attempt to support a specific IDE 
for a specific part of the code base, cluttered all over the code base.


This patch is a first attempt go get one ring, eh..., structure, to 
rule them all.


I have moved all IDE project creators into the following structure:

make/ide//

where  is one of currently "hotspot", "langtools" 
or "jdk", and  is one of "vscode", "idea", "netbeans" or 
"vistualstudio".


This will not magically improve IDE support, but will at least make 
it clearer what we have and what we are missing.


Ownership of the IDE support is notoriously vague. I've cc:ed a bunch 
of people who has shown interest and/or submitted fixes to some of 
the IDE projects according to the hg history. I'd appreciate it if 
anyone who is interested in a particular case for IDE support can 
verify that it still works. I've tried my best to make sure all 
targets can run without errors, but I cannot verify that the IDE 
environment themselves are correct.


If you know about an IDE project that is no longer relevant, and 
should be removed instead of shuffled around, please let me know!


Bug: https://bugs.openjdk.java.net/browse/JDK-8244093
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8244093-move-ide-support/webrev.01


/Magnus

RFR: 8244097: make bootcycle-images fails after JDK-8244036

[傅杰]

Hi all,

May I get reviews for this fix?

JBS: https://bugs.openjdk.java.net/browse/JDK-8244097
Webrev: http://cr.openjdk.java.net/~jiefu/8244097/webrev.00/

Thanks a lot.
Best regards,
Jie

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Jan Lahoda]

I am not sure if anyone is still using make/jdk/netbeans. Apache 
NetBeans does not (should not) need these config files, it supports 
OpenJDK modules out of the box (with some tweaks/dependencies on 
make/langtools/** to speed up langtools build).


As Maurizio, there may be some need to move the "fast" langtools build 
more carefully. I'll try to take a look later, unless some else wants 
to. Although, a little independently, I wonder somewhat if there's an 
opportunity to further speed up the ordinary make build in incremental 
environment to reduce the need for a "fast" langtools build. E.g. by 
enhancing the current Depend javac plugin, and possibly optionally 
disabling the interim langtools build. This could improve incremental 
build behavior for other modules (like java.base or java.desktop) as well.


Jan

On 29. 04. 20 12:36, Magnus Ihse Bursie wrote:
The IDE support in OpenJDK unfortunately leaves a lot to be desired. 
There have been a garden variety of attempt to support a specific IDE 
for a specific part of the code base, cluttered all over the code base.


This patch is a first attempt go get one ring, eh..., structure, to rule 
them all.


I have moved all IDE project creators into the following structure:

make/ide//

where  is one of currently "hotspot", "langtools" or 
"jdk", and  is one of "vscode", "idea", "netbeans" or "vistualstudio".


This will not magically improve IDE support, but will at least make it 
clearer what we have and what we are missing.


Ownership of the IDE support is notoriously vague. I've cc:ed a bunch of 
people who has shown interest and/or submitted fixes to some of the IDE 
projects according to the hg history. I'd appreciate it if anyone who is 
interested in a particular case for IDE support can verify that it still 
works. I've tried my best to make sure all targets can run without 
errors, but I cannot verify that the IDE environment themselves are 
correct.


If you know about an IDE project that is no longer relevant, and should 
be removed instead of shuffled around, please let me know!


Bug: https://bugs.openjdk.java.net/browse/JDK-8244093
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8244093-move-ide-support/webrev.01


/Magnus

Re: RFR: 8244097: make bootcycle-images fails after JDK-8244036

[Magnus Ihse Bursie]

On 2020-04-29 13:02, jiefu(傅杰) wrote:

Hi all,

May I get reviews for this fix?

JBS: https://bugs.openjdk.java.net/browse/JDK-8244097
Dang it! I thought I had tested bootcycle-images, but maybe that wasn't 
the last iteration of my fix.

Webrev: http://cr.openjdk.java.net/~jiefu/8244097/webrev.00/
No, I don't think this is the right way to solve it, by stopping 
warnings from being errors. Let me get back to you with another approach.


/Magnus


Thanks a lot.
Best regards,
Jie

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Maurizio Cimadamore]

On 29/04/2020 11:57, Magnus Ihse Bursie wrote:
So who/what is using the ant build? I thought it was just the IDEA 
project that generated ant targets. Is it run explicitly using ant by 
langtool developers? I know for sure it's not used when we build the 
product in our CI.


As Jan mentioned, the main purpose of the langtools Ant build is to get 
very very fast incremental recompilation. Which happens to be very 
useful when working in an IDE environment, but one can also use it (and 
I've seen people doing that) just from the command line. You can run 
most (all?) of langtools tests by just doing a private langtools build, 
so langtools developers sometimes go down that path.


Now, to be fair, this was much more common in the non-consolidated world 
than it is in the new world, but, as Jan mentioned, Make is currently 
not useful as a replacement for the private langtools build because it 
has to go through the interim step and all that - and doing that, even 
in the face of one line change in one file was taking approx 15s 
recompilation time back when I did the test. So the private build still 
has a purpose.


Maurizio

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Magnus Ihse Bursie]

On 2020-04-29 13:36, Maurizio Cimadamore wrote:


On 29/04/2020 11:57, Magnus Ihse Bursie wrote:
So who/what is using the ant build? I thought it was just the IDEA 
project that generated ant targets. Is it run explicitly using ant by 
langtool developers? I know for sure it's not used when we build the 
product in our CI.


As Jan mentioned, the main purpose of the langtools Ant build is to 
get very very fast incremental recompilation. Which happens to be very 
useful when working in an IDE environment, but one can also use it 
(and I've seen people doing that) just from the command line. You can 
run most (all?) of langtools tests by just doing a private langtools 
build, so langtools developers sometimes go down that path.


Now, to be fair, this was much more common in the non-consolidated 
world than it is in the new world, but, as Jan mentioned, Make is 
currently not useful as a replacement for the private langtools build 
because it has to go through the interim step and all that - and doing 
that, even in the face of one line change in one file was taking 
approx 15s recompilation time back when I did the test. So the private 
build still has a purpose.
While I don't really like there to be two different and parallel build 
systems, I agree that the incremental behavior of the normal build 
system is not optimal. Let's work on getting that fixed -- but that's a 
long term goal.


In the meantime, there's obviously room for, and need of, a separate 
ant-based build system for langtools. If this is run manually by 
developers using "ant" on the command line, I see the point that it does 
not really belong in the IDE directory.


Let's say we keep it in langtools (unless we can find a better home for 
it). My question is: Are we talking only about build.properties and 
build.xml? Or are there more files that these depend on, that I had 
assumed belong to the IDE generation?


/Magnus


Maurizio

Re: RFR: 8244097: make bootcycle-images fails after JDK-8244036

[Magnus Ihse Bursie]

On 2020-04-29 13:23, Magnus Ihse Bursie wrote:

On 2020-04-29 13:02, jiefu(傅杰) wrote:

Hi all,

May I get reviews for this fix?

JBS: https://bugs.openjdk.java.net/browse/JDK-8244097
Dang it! I thought I had tested bootcycle-images, but maybe that 
wasn't the last iteration of my fix.

Webrev: http://cr.openjdk.java.net/~jiefu/8244097/webrev.00/
No, I don't think this is the right way to solve it, by stopping 
warnings from being errors. Let me get back to you with another approach.
As a short time solution, I suggest amending BOOT_JDK_SOURCETARGET when 
running bootcycle builds instead.


As a more long term solution, I should probably sit down (at least 
metaphorically) with someone from the compiler team and make a complete 
pass over all our javac options. I think this warning ensues from 
something we're doing incorrect, so we ought to fix it properly instead.


Patch inline:
diff --git a/make/autoconf/bootcycle-spec.gmk.in 
b/make/autoconf/bootcycle-spec.gmk.in

--- a/make/autoconf/bootcycle-spec.gmk.in
+++ b/make/autoconf/bootcycle-spec.gmk.in
@@ -59,3 +59,6 @@

 # Pandoc cannot be used without the jjs plugin, which was removed with 
Nashorn.

 ENABLE_PANDOC := false
+
+# Avoid "warning: [options] system modules path not set in conjunction 
with -source"

+BOOT_JDK_SOURCETARGET := $(BOOT_JDK_SOURCETARGET) -Xlint:-options

/Magnus




/Magnus


Thanks a lot.
Best regards,
Jie

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Magnus Ihse Bursie]

On 2020-04-29 13:06, Jan Lahoda wrote:
I am not sure if anyone is still using make/jdk/netbeans. Apache 
NetBeans does not (should not) need these config files, it supports 
OpenJDK modules out of the box (with some tweaks/dependencies on 
make/langtools/** to speed up langtools build).
It's by far the oldest IDE files in the source repo. They have not been 
touched for a very long time, which indicates that they might indeed be 
dead.


Would anyone be opposed to me removing them?

/Magnus



As Maurizio, there may be some need to move the "fast" langtools build 
more carefully. I'll try to take a look later, unless some else wants 
to. Although, a little independently, I wonder somewhat if there's an 
opportunity to further speed up the ordinary make build in incremental 
environment to reduce the need for a "fast" langtools build. E.g. by 
enhancing the current Depend javac plugin, and possibly optionally 
disabling the interim langtools build. This could improve incremental 
build behavior for other modules (like java.base or java.desktop) as 
well.


Jan

On 29. 04. 20 12:36, Magnus Ihse Bursie wrote:
The IDE support in OpenJDK unfortunately leaves a lot to be desired. 
There have been a garden variety of attempt to support a specific IDE 
for a specific part of the code base, cluttered all over the code base.


This patch is a first attempt go get one ring, eh..., structure, to 
rule them all.


I have moved all IDE project creators into the following structure:

make/ide//

where  is one of currently "hotspot", "langtools" 
or "jdk", and  is one of "vscode", "idea", "netbeans" or 
"vistualstudio".


This will not magically improve IDE support, but will at least make 
it clearer what we have and what we are missing.


Ownership of the IDE support is notoriously vague. I've cc:ed a bunch 
of people who has shown interest and/or submitted fixes to some of 
the IDE projects according to the hg history. I'd appreciate it if 
anyone who is interested in a particular case for IDE support can 
verify that it still works. I've tried my best to make sure all 
targets can run without errors, but I cannot verify that the IDE 
environment themselves are correct.


If you know about an IDE project that is no longer relevant, and 
should be removed instead of shuffled around, please let me know!


Bug: https://bugs.openjdk.java.net/browse/JDK-8244093
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8244093-move-ide-support/webrev.01


/Magnus

Re: 8244097: make bootcycle-images fails after JDK-8244036(Internet mail)

[傅杰]

Thanks Magnus for your review and nice help.
It seems that your patch didn't fix the build failure when configure 
--with-boot-jdk=jdk15.

I've made : http://cr.openjdk.java.net/~jiefu/8244097/webrev.01/ based on your 
work.

Please review it and give me some advice.
Thanks.

Best regards,
Jie


On 2020/4/29, 7:49 PM, "Magnus Ihse Bursie"  
wrote:

On 2020-04-29 13:23, Magnus Ihse Bursie wrote:
> On 2020-04-29 13:02, jiefu(傅杰) wrote:
>> Hi all,
>>
>> May I get reviews for this fix?
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244097
> Dang it! I thought I had tested bootcycle-images, but maybe that 
> wasn't the last iteration of my fix.
>> Webrev: http://cr.openjdk.java.net/~jiefu/8244097/webrev.00/
> No, I don't think this is the right way to solve it, by stopping 
> warnings from being errors. Let me get back to you with another approach.
As a short time solution, I suggest amending BOOT_JDK_SOURCETARGET when 
running bootcycle builds instead.

As a more long term solution, I should probably sit down (at least 
metaphorically) with someone from the compiler team and make a complete 
pass over all our javac options. I think this warning ensues from 
something we're doing incorrect, so we ought to fix it properly instead.

Patch inline:
diff --git a/make/autoconf/bootcycle-spec.gmk.in 
b/make/autoconf/bootcycle-spec.gmk.in
--- a/make/autoconf/bootcycle-spec.gmk.in
+++ b/make/autoconf/bootcycle-spec.gmk.in
@@ -59,3 +59,6 @@

  # Pandoc cannot be used without the jjs plugin, which was removed with 
Nashorn.
  ENABLE_PANDOC := false
+
+# Avoid "warning: [options] system modules path not set in conjunction 
with -source"
+BOOT_JDK_SOURCETARGET := $(BOOT_JDK_SOURCETARGET) -Xlint:-options

/Magnus


>
> /Magnus
>>
>> Thanks a lot.
>> Best regards,
>> Jie
>>
>

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Erik Joelsson]

Looks good.

/Erik

On 2020-04-28 21:12, Mikael Vidstedt wrote:

Please review this small change which disables JVMCI, Graal, and AOT when 
building linux-aarch64 at Oracle, for now.

JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/

Cheers,
Mikael

Re: RFR: JDK-8243665 exploded-image-optimize touches module-info.class in all modules

[Erik Joelsson]

Looks good to me.

/Erik

On 2020-04-29 03:47, Alan Bateman wrote:



On 29/04/2020 11:40, Magnus Ihse Bursie wrote:

:

http://cr.openjdk.java.net/~ihse/JDK-8243665-fix-AddPackagesAttribute/webrev.02 

Looks good. It could be optimized to only read the module-info.class 
once but will hardly be noticeable I suspect.


-Alan

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Chris Hegarty]

> On 29 Apr 2020, at 11:36, Magnus Ihse Bursie  
> wrote:
> 
> ...
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8244093
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8244093-move-ide-support/webrev.01


The make/idea changes look ok to me.

-Chris.

Re: RFR: 8244097: make bootcycle-images fails after JDK-8244036

[Erik Joelsson]

On 2020-04-29 04:48, Magnus Ihse Bursie wrote:

On 2020-04-29 13:23, Magnus Ihse Bursie wrote:

On 2020-04-29 13:02, jiefu(傅杰) wrote:

Hi all,

May I get reviews for this fix?

JBS: https://bugs.openjdk.java.net/browse/JDK-8244097
Dang it! I thought I had tested bootcycle-images, but maybe that 
wasn't the last iteration of my fix.

Webrev: http://cr.openjdk.java.net/~jiefu/8244097/webrev.00/
No, I don't think this is the right way to solve it, by stopping 
warnings from being errors. Let me get back to you with another 
approach.
As a short time solution, I suggest amending BOOT_JDK_SOURCETARGET 
when running bootcycle builds instead.


As a more long term solution, I should probably sit down (at least 
metaphorically) with someone from the compiler team and make a 
complete pass over all our javac options. I think this warning ensues 
from something we're doing incorrect, so we ought to fix it properly 
instead.


Patch inline:
diff --git a/make/autoconf/bootcycle-spec.gmk.in 
b/make/autoconf/bootcycle-spec.gmk.in

--- a/make/autoconf/bootcycle-spec.gmk.in
+++ b/make/autoconf/bootcycle-spec.gmk.in
@@ -59,3 +59,6 @@

 # Pandoc cannot be used without the jjs plugin, which was removed 
with Nashorn.

 ENABLE_PANDOC := false
+
+# Avoid "warning: [options] system modules path not set in 
conjunction with -source"

+BOOT_JDK_SOURCETARGET := $(BOOT_JDK_SOURCETARGET) -Xlint:-options

Won't this also break if you configure with a JDK 15 boot JDK, which we 
do allow in configure. If so the -Xlin:-options needs to be added to all 
previous uses of the BOOT_JAVAC compiler setup.


/Erik

Re: 8244097: make bootcycle-images fails after JDK-8244036(Internet mail)

[Erik Joelsson]

On 2020-04-29 05:25, jiefu(傅杰) wrote:

Thanks Magnus for your review and nice help.
It seems that your patch didn't fix the build failure when configure 
--with-boot-jdk=jdk15.

I've made : http://cr.openjdk.java.net/~jiefu/8244097/webrev.01/ based on your 
work.


Ah, you already discovered this. I think this is the right approach. 
Looks good to me.


/Erik


Please review it and give me some advice.
Thanks.

Best regards,
Jie


On 2020/4/29, 7:49 PM, "Magnus Ihse Bursie"  
wrote:

 On 2020-04-29 13:23, Magnus Ihse Bursie wrote:
 > On 2020-04-29 13:02, jiefu(傅杰) wrote:
 >> Hi all,
 >>
 >> May I get reviews for this fix?
 >>
 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244097
 > Dang it! I thought I had tested bootcycle-images, but maybe that
 > wasn't the last iteration of my fix.
 >> Webrev: http://cr.openjdk.java.net/~jiefu/8244097/webrev.00/
 > No, I don't think this is the right way to solve it, by stopping
 > warnings from being errors. Let me get back to you with another approach.
 As a short time solution, I suggest amending BOOT_JDK_SOURCETARGET when
 running bootcycle builds instead.
 
 As a more long term solution, I should probably sit down (at least

 metaphorically) with someone from the compiler team and make a complete
 pass over all our javac options. I think this warning ensues from
 something we're doing incorrect, so we ought to fix it properly instead.
 
 Patch inline:

 diff --git a/make/autoconf/bootcycle-spec.gmk.in
 b/make/autoconf/bootcycle-spec.gmk.in
 --- a/make/autoconf/bootcycle-spec.gmk.in
 +++ b/make/autoconf/bootcycle-spec.gmk.in
 @@ -59,3 +59,6 @@
 
   # Pandoc cannot be used without the jjs plugin, which was removed with

 Nashorn.
   ENABLE_PANDOC := false
 +
 +# Avoid "warning: [options] system modules path not set in conjunction
 with -source"
 +BOOT_JDK_SOURCETARGET := $(BOOT_JDK_SOURCETARGET) -Xlint:-options
 
 /Magnus
 
 
 >

 > /Magnus
 >>
 >> Thanks a lot.
 >> Best regards,
 >> Jie
 >>
 >
 
 
 

Re: 8244097: make bootcycle-images fails after JDK-8244036(Internet mail)

[Magnus Ihse Bursie]

If this works both when building normally and when building bootcycle-images, 
I’m okay with this. 

Are you a committer, or do you need someone to sponsor the patch?

/Magnus

> 29 apr. 2020 kl. 14:25 skrev jiefu(傅杰) :
> 
> Thanks Magnus for your review and nice help.
> It seems that your patch didn't fix the build failure when configure 
> --with-boot-jdk=jdk15.
> 
> I've made : http://cr.openjdk.java.net/~jiefu/8244097/webrev.01/ based on 
> your work.
> 
> Please review it and give me some advice.
> Thanks.
> 
> Best regards,
> Jie
> 
> 
> On 2020/4/29, 7:49 PM, "Magnus Ihse Bursie"  
> wrote:
> 
>>On 2020-04-29 13:23, Magnus Ihse Bursie wrote:
>>> On 2020-04-29 13:02, jiefu(傅杰) wrote:
>>> Hi all,
>>> 
>>> May I get reviews for this fix?
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244097
>> Dang it! I thought I had tested bootcycle-images, but maybe that 
>> wasn't the last iteration of my fix.
>>> Webrev: http://cr.openjdk.java.net/~jiefu/8244097/webrev.00/
>> No, I don't think this is the right way to solve it, by stopping 
>> warnings from being errors. Let me get back to you with another approach.
>As a short time solution, I suggest amending BOOT_JDK_SOURCETARGET when 
>running bootcycle builds instead.
> 
>As a more long term solution, I should probably sit down (at least 
>metaphorically) with someone from the compiler team and make a complete 
>pass over all our javac options. I think this warning ensues from 
>something we're doing incorrect, so we ought to fix it properly instead.
> 
>Patch inline:
>diff --git a/make/autoconf/bootcycle-spec.gmk.in 
>b/make/autoconf/bootcycle-spec.gmk.in
>--- a/make/autoconf/bootcycle-spec.gmk.in
>+++ b/make/autoconf/bootcycle-spec.gmk.in
>@@ -59,3 +59,6 @@
> 
>  # Pandoc cannot be used without the jjs plugin, which was removed with 
>Nashorn.
>  ENABLE_PANDOC := false
>+
>+# Avoid "warning: [options] system modules path not set in conjunction 
>with -source"
>+BOOT_JDK_SOURCETARGET := $(BOOT_JDK_SOURCETARGET) -Xlint:-options
> 
>/Magnus
> 
> 
>> 
>> /Magnus
>>> 
>>> Thanks a lot.
>>> Best regards,
>>> Jie
>>> 
>> 
> 
> 
> 
> 

Re: 8244097: make bootcycle-images fails after JDK-8244036(Internet mail)

[傅杰]

Thanks Erik and Magnus for your review.
I'll push it soon.

On 2020/4/29, 9:33 PM, "Magnus Ihse Bursie"  
wrote:

If this works both when building normally and when building 
bootcycle-images, I’m okay with this. 

Are you a committer, or do you need someone to sponsor the patch?

/Magnus

> 29 apr. 2020 kl. 14:25 skrev jiefu(傅杰) :
> 
> Thanks Magnus for your review and nice help.
> It seems that your patch didn't fix the build failure when configure 
--with-boot-jdk=jdk15.
> 
> I've made : http://cr.openjdk.java.net/~jiefu/8244097/webrev.01/ based on 
your work.
> 
> Please review it and give me some advice.
> Thanks.
> 
> Best regards,
> Jie
> 
> 
> On 2020/4/29, 7:49 PM, "Magnus Ihse Bursie" 
 wrote:
> 
>>On 2020-04-29 13:23, Magnus Ihse Bursie wrote:
>>> On 2020-04-29 13:02, jiefu(傅杰) wrote:
>>> Hi all,
>>> 
>>> May I get reviews for this fix?
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244097
>> Dang it! I thought I had tested bootcycle-images, but maybe that 
>> wasn't the last iteration of my fix.
>>> Webrev: http://cr.openjdk.java.net/~jiefu/8244097/webrev.00/
>> No, I don't think this is the right way to solve it, by stopping 
>> warnings from being errors. Let me get back to you with another approach.
>As a short time solution, I suggest amending BOOT_JDK_SOURCETARGET 
when 
>running bootcycle builds instead.
> 
>As a more long term solution, I should probably sit down (at least 
>metaphorically) with someone from the compiler team and make a 
complete 
>pass over all our javac options. I think this warning ensues from 
>something we're doing incorrect, so we ought to fix it properly 
instead.
> 
>Patch inline:
>diff --git a/make/autoconf/bootcycle-spec.gmk.in 
>b/make/autoconf/bootcycle-spec.gmk.in
>--- a/make/autoconf/bootcycle-spec.gmk.in
>+++ b/make/autoconf/bootcycle-spec.gmk.in
>@@ -59,3 +59,6 @@
> 
>  # Pandoc cannot be used without the jjs plugin, which was removed 
with 
>Nashorn.
>  ENABLE_PANDOC := false
>+
>+# Avoid "warning: [options] system modules path not set in 
conjunction 
>with -source"
>+BOOT_JDK_SOURCETARGET := $(BOOT_JDK_SOURCETARGET) -Xlint:-options
> 
>/Magnus
> 
> 
>> 
>> /Magnus
>>> 
>>> Thanks a lot.
>>> Best regards,
>>> Jie
>>> 
>> 
> 
> 
> 
> 

RFR: JDK-8244051: AbsPathsInImage.java still fails on Windows

[Erik Joelsson]

Hello,

My fix for JDK-8243510 was not enough to catch all potential exceptions 
needed. Here is a new attempt that casts a wider net.


Webrev: http://cr.openjdk.java.net/~erikj/8244051/webrev.01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8244051

/Erik

Re: RFR: JDK-8244051: AbsPathsInImage.java still fails on Windows

[Magnus Ihse Bursie]

LGTM. 

/Magnus

> 29 apr. 2020 kl. 17:23 skrev Erik Joelsson :
> 
> Hello,
> 
> My fix for JDK-8243510 was not enough to catch all potential exceptions 
> needed. Here is a new attempt that casts a wider net.
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8244051/webrev.01/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8244051
> 
> /Erik
> 

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Maurizio Cimadamore]

On 29/04/2020 12:45, Magnus Ihse Bursie wrote:
Let's say we keep it in langtools (unless we can find a better home 
for it). My question is: Are we talking only about build.properties 
and build.xml? Or are there more files that these depend on, that I 
had assumed belong to the IDE generation? 


I think all the make/langtools stuff would need to stay where it is - 
with the exception of the 'idea' templates, which can be moved to the 
new location - but then the langtools build.xml project will have to be 
tweaked to find the template in the right place (something which you had 
to do already, in a way).


Maurizio

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

[Bradford Wetmore]

Jan,

What is your current recommended technique to use NetBeans to 
build/edit/test OpenJDK for normal OpenJDK library developers?


After many versions of Netbeans, my current setup is to:

1.  Do an external "exploded" build

2.  Run Netbeans, open the src/java.base module project and any other 
modules needed.


3a. For OpenJDK test files under test/jdk:  Open the java.base test dirs 
for the JTREG tests I need.  Then run "Debug Test File" to invoke JTREG


3b. For tests not in test/jdk (external to repo):
1.  Add a Java platform for the exploded-build
2.  Create a project, assign the platform
3.  Create standard Debug project.

4.  For incremental builds, edit source file, build from the command 
line something like:


% make JDK_FILTER=java/security java.base-java-only

Is there another way of working I'm missing?

Things have been really solid for me lately (OpenJDK/JTREG plugins not 
needed), thanks for all your hard work on this.


Cheers,

Brad


On 4/29/2020 4:06 AM, Jan Lahoda wrote:
I am not sure if anyone is still using make/jdk/netbeans. Apache 
NetBeans does not (should not) need these config files, it supports 
OpenJDK modules out of the box (with some tweaks/dependencies on 
make/langtools/** to speed up langtools build).


As Maurizio, there may be some need to move the "fast" langtools build 
more carefully. I'll try to take a look later, unless some else wants 
to. Although, a little independently, I wonder somewhat if there's an 
opportunity to further speed up the ordinary make build in incremental 
environment to reduce the need for a "fast" langtools build. E.g. by 
enhancing the current Depend javac plugin, and possibly optionally 
disabling the interim langtools build. This could improve incremental 
build behavior for other modules (like java.base or java.desktop) as well.


Jan

On 29. 04. 20 12:36, Magnus Ihse Bursie wrote:
The IDE support in OpenJDK unfortunately leaves a lot to be desired. 
There have been a garden variety of attempt to support a specific IDE 
for a specific part of the code base, cluttered all over the code base.


This patch is a first attempt go get one ring, eh..., structure, to 
rule them all.


I have moved all IDE project creators into the following structure:

make/ide//

where  is one of currently "hotspot", "langtools" or 
"jdk", and  is one of "vscode", "idea", "netbeans" or 
"vistualstudio".


This will not magically improve IDE support, but will at least make it 
clearer what we have and what we are missing.


Ownership of the IDE support is notoriously vague. I've cc:ed a bunch 
of people who has shown interest and/or submitted fixes to some of the 
IDE projects according to the hg history. I'd appreciate it if anyone 
who is interested in a particular case for IDE support can verify that 
it still works. I've tried my best to make sure all targets can run 
without errors, but I cannot verify that the IDE environment 
themselves are correct.


If you know about an IDE project that is no longer relevant, and 
should be removed instead of shuffled around, please let me know!


Bug: https://bugs.openjdk.java.net/browse/JDK-8244093
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8244093-move-ide-support/webrev.01


/Magnus

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Mikael Vidstedt]

> On Apr 29, 2020, at 3:44 AM, Andrew Haley  wrote:
> 
> On 4/29/20 10:02 AM, Mikael Vidstedt wrote:
>> 
>>> On Apr 29, 2020, at 12:46 AM, Andrew Haley  wrote:
>>> 
>>> On 4/29/20 5:12 AM, Mikael Vidstedt wrote:
 Please review this small change which disables JVMCI, Graal, and AOT when 
 building linux-aarch64 at Oracle, for now.
 
 JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
 webrev: 
 http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
>>> 
>>> Why? Are there problems with it? If so, I need bug reports.
>> 
>> No specific problems or bugs that I’m aware of. We’re simply opting not to 
>> include Graal/JVMTI/AOT in the linux-aarch64 builds we do at Oracle, for now.
> 
> Cool, NP. Obvs. I'd prefer it if y'all built and tested it all,
> but fair enough.

One small step at a time :)

Cheers,
Mikael

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

[Mikael Vidstedt]

Vladimir/Magnus/Erik,

Thanks for the reviews, change pushed.

Cheers,
Mikael

> On Apr 29, 2020, at 5:45 AM, Erik Joelsson  wrote:
> 
> Looks good.
> 
> /Erik
> 
> On 2020-04-28 21:12, Mikael Vidstedt wrote:
>> Please review this small change which disables JVMCI, Graal, and AOT when 
>> building linux-aarch64 at Oracle, for now.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
>> 
>> Cheers,
>> Mikael
>>