Re: JDK10 build problem: "--module-path"?

[Ted Neward]

The temptation to do a “Well, actually…” here is strong. ;-)

 

Seriously, thanks for taking my incredulity in the spirit it was intended. :-) 
Is it becoming more common for Java tools to accept different “styles” of 
arguments, or did this become a complete switch/rename? (You can tell how much 
I’ve used modules recently, right?)

 

Ted Neward

Author, Speaker, Mentor

http://www.newardassociates.com

t: @tedneward | m: (425) 647-4526

From: Jonathan Gibbons 
Date: Thursday, February 15, 2018 at 7:27 AM
To: Ted Neward , 
Subject: Re: JDK10 build problem: "--module-path"?

 

Ted,

Yes, I'm sure :-) This is the relevant line from the source code for JDK 9, 
listing --module-path and -p as alternatives for this option.
    MODULE_PATH("--module-path -p", "opt.arg.path", "opt.modulepath", STANDARD, 
FILEMANAGER),

http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/65bfdabaab9c/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java#l183
 

-- Jon

On 2/14/18 10:32 PM, Ted Neward wrote:
Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve 
you *grin*, but are you sure? The reason I ask is (barring some really bizarre 
misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and 
I'm getting the error.
 
Ted Neward
Author, Speaker, Mentor
http://www.newardassociates.com
t: @tedneward | m: (425) 647-4526
 
On 2/14/18, 6:53 PM, "build-dev on behalf of Jonathan Gibbons" 
 
wrote:
 
    

On 2/14/18 4:38 PM, Ted Neward wrote:
    > I’m getting a weird error in my OpenJDK 10 (tip) build, where after 
pulling source and configure, I get a build error about the Java compiler being 
executed with “--module-path” as a parameter, which obviously isn’t a 
legitimate javac flag.
    >
    >   
I can't speak to your specific build error, but --module-path is a 
legitimate javac option, as of JDK 9.
    
-- Jon
    
>
    > Is this just me? Is anybody else able to repro this, and is there a fix 
coming that isn’t checked into the main trunk yet?
    >
    >   
>
    > I am in the process of finalizing some Docker images (both with the 
source inside the image and built, so people can just “go”, as well as images 
with the prereqs and some shell scripts to do the build with the source and 
build artifacts on the host machine), and this is holding up the current “tip” 
images from being really ready for public consumption. (JDK8u and JDK9 are up 
and ready to go.)
    >
    >   
>
    > Ted Neward
    >
    > Author, Speaker, Mentor
    >
    > http://www.newardassociates.com
    >
    > t: @tedneward | m: (425) 647-4526
    >
    

 
 

Re: JDK10 build problem: "--module-path"?

[Ted Neward]

So… Hmm. Anybody here know what the blessed way to get OpenJDK9 into a Docker 
image would be, then?

 

Ted Neward

Author, Speaker, Mentor

http://www.newardassociates.com

t: @tedneward | m: (425) 647-4526

From: Martin Buchholz 
Date: Thursday, February 15, 2018 at 8:50 AM
To: Erik Joelsson 
Cc: Alan Bateman , Ted Neward , 
Jonathan Gibbons , "build-dev@openjdk.java.net" 

Subject: Re: JDK10 build problem: "--module-path"?

 

Looking at

https://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=openjdk-9-jdk&searchon=names

it seems like Ubuntu ships whatever openjdk-9 is available at time of creation 
of a specific version, and doesn't update it afterwards, not even for the 
quarterly security patches.

 

On Thu, Feb 15, 2018 at 7:42 AM, Erik Joelsson  wrote:

I have hit this same problem once for the same reason Alan describes. Ubuntu 
provided me with a really old EA build of 9.

/Erik




On 2018-02-15 00:05, Alan Bateman wrote:



On 15/02/2018 06:32, Ted Neward wrote:

Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve 
you *grin*, but are you sure? The reason I ask is (barring some really bizarre 
misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and 
I'm getting the error.

What is your boot JDK? Any possibility that you have really old EA build of JDK 
9?

 

 

Re: RFR: JDK-8198227 Fix COMPARE_BUILD after forest consolidation

[Tim Bell]

Magnus:

Looks good to me as well.

Tim

On 02/15/18 07:40, Erik Joelsson wrote:

Looks good.

/Erik


On 2018-02-15 06:14, Magnus Ihse Bursie wrote:

The new repo structure with the forest consolidation broke the
COMPARE_BUILD functionality when using a closed repo.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198227
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8198227-fix-COMPARE_BUILD-in-CLOSED_ROOT/webrev.01

Re: RFR(S): 8197906: Enable CDS mode execution of jtreg tests via make

[Mikhailo Seledtsov]

Hi Igor,

  Thank you very much for catching this, and for the explanation. I 
have updated the patch and running tests now.
I assume the recommended update is small/trivial enough that it does not 
need another webrev; let me know otherwise.


Thank you,
Misha

On 2/14/18, 9:00 AM, Igor Ignatyev wrote:

[1] and [2] are equivalent for cygwin, but it doesn't mean they are equivalent 
JVM. I recall there were some problems when cygwin paths passed to JVM. so to 
be on the safe side, I'd use mixed or windows path to the archive in JVM flags.

Thanks,
-- Igor


On Feb 14, 2018, at 7:26 AM, Mikhailo Seledtsov  
wrote:

Hi Igor,

  Thank you for review. This is what I see from the test execution logs on 
Windows:

// At archive creation time:

  -XX:SharedArchiveFile=T:/testoutput/jtreg/cds_archive.jsa -Xshare:dump


// At archive use time:


-vmoption:-XX:+UnlockDiagnosticVMOptions 
-vmoption:-XX:SharedArchiveFile=/cygdrive/t/testoutput/jtreg/cds_archive.jsa 
-javaoptions:-Xshare:auto -javaoptions:-Xlog:class+path=trace 
-javaoptions:-showversion


I am not a Windows expert, and especially not a wiz in Cygwin. Do you know if 
these 2 paths are equivalent?
[1] T:/testoutput/jtreg/cds_archive.jsa
[2] /cygdrive/t/testoutput/jtreg/cds_archive.jsa

If these are equivalent, then the code is OK as is. If not, I will change it 
and rerun the tests. Please let me know.


Thank you,
Misha


On 2/13/18, 8:41 PM, Igor Ignatyev wrote:

Hi Misha,

have you check that it works on windows w/ GENERATE_CDS_ARCHIVE=true? it seems 
that you should called GETMIXEDPATH in CDS_VM_ARGS:

CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions 
-XX:SharedArchiveFile=$(CDS_ARCHIVE_FILE)

vs

CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=$(shell 
$(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)")

otherwise, tests won't be able to find cds archive during test execution.

-- Igor


On Feb 13, 2018, at 8:17 PM, Mikhailo Seledtsov  
 wrote:

Please review this small change that enables execution of any jtreg test(s) in 
CDS mode
via make. Please see bug description for details.

Thanks to Erik and Igor for their help with this change.

JBS: https://bugs.openjdk.java.net/browse/JDK-8197906
WebRev: http://cr.openjdk.java.net/~mseledtsov/8197906.01/

Testing:
  - ran hotspot_runtime in CDS mode with this change - Linux-x64 - no new 
failures
  - running several test sets in CDS mode via distributed test system - pass
  - running pre-integration sanity testing (HS tier1, tier2) - in progress

Thank you,
Misha

Re: RFR(S): 8197906: Enable CDS mode execution of jtreg tests via make

[Mikhailo Seledtsov]

Hi Magnus,

 Thank you for review and feedback. I will update my change based on 
your recommendation, the retest. If tests pass, I am planning to push.


Thank you,
Misha

On 2/14/18, 12:04 PM, Magnus Ihse Bursie wrote:



On 2018-02-14 16:26, Mikhailo Seledtsov wrote:

Hi Igor,

  Thank you for review. This is what I see from the test execution 
logs on Windows:


// At archive creation time:
> -XX:SharedArchiveFile=T:/testoutput/jtreg/cds_archive.jsa -Xshare:dump


// At archive use time:

>-vmoption:-XX:+UnlockDiagnosticVMOptions 
-vmoption:-XX:SharedArchiveFile=/cygdrive/t/testoutput/jtreg/cds_archive.jsa 
-javaoptions:-Xshare:auto -javaoptions:-Xlog:class+path=trace 
-javaoptions:-showversion



I am not a Windows expert, and especially not a wiz in Cygwin. Do you 
know if these 2 paths are equivalent?
That's likely incorrect. Java will not be able to correctly interpred 
/cygdrive/t. I believe the fix should be to do:
CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions 
-XX:SharedArchiveFile=$(shell $(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)")

instead.

Otherwise the patch looks OK to me.

/Magnus



[1] T:/testoutput/jtreg/cds_archive.jsa
[2] /cygdrive/t/testoutput/jtreg/cds_archive.jsa

If these are equivalent, then the code is OK as is. If not, I will 
change it and rerun the tests. Please let me know.



Thank you,
Misha


On 2/13/18, 8:41 PM, Igor Ignatyev wrote:

Hi Misha,

have you check that it works on windows w/ 
GENERATE_CDS_ARCHIVE=true? it seems that you should called 
GETMIXEDPATH in CDS_VM_ARGS:
CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions 
-XX:SharedArchiveFile=$(CDS_ARCHIVE_FILE)

vs
CDS_VM_ARGS := -XX:+UnlockDiagnosticVMOptions 
-XX:SharedArchiveFile=$(shell $(GETMIXEDPATH) "$(CDS_ARCHIVE_FILE)")
otherwise, tests won't be able to find cds archive during test 
execution.


-- Igor

On Feb 13, 2018, at 8:17 PM, Mikhailo 
Seledtsov  wrote:


Please review this small change that enables execution of any jtreg 
test(s) in CDS mode

via make. Please see bug description for details.

Thanks to Erik and Igor for their help with this change.

JBS: https://bugs.openjdk.java.net/browse/JDK-8197906
WebRev: http://cr.openjdk.java.net/~mseledtsov/8197906.01/

Testing:
  - ran hotspot_runtime in CDS mode with this change - 
Linux-x64 - no new failures
  - running several test sets in CDS mode via distributed test 
system - pass
  - running pre-integration sanity testing (HS tier1, tier2) - 
in progress


Thank you,
Misha

Re: Choosing which Visual Studio installation to use

[Thomas Stüfe]

Hi Erik,

On Thu, Feb 15, 2018 at 4:22 PM, Erik Joelsson 
wrote:

> Hello Thomas,
>
> If you have multiple versions installed, configure will pick the one to
> use in order of most supported. To explicitly pick one, you can use
> --with-toolchain-version=2010 (or some other number) and configure will
> look for that specific version of Visual Studio. Just pointing to an
> install dir or bin dir does not work because configure needs to know which
> version it is dealing with and we haven't implemented smart enough
> discovery logic to automatically figure that out.
>
>
Great, exactly what I was looking for!


> Note that I recently added configure support for 2015 and 2017 in JDK 11.
> This does NOT mean the product actually builds with those and configure
> will print warnings accordingly. We are working on properly supporting
> 2017, but it's apparently non trivial.
>
>
Yes, I was playing around with getting VS2017 to build, and wanted to test
changes with various VS versions. I see that Lois Foltan is quite active,
maybe I just wait till he is done.

..Thomas


> /Erik
>
>
>
> On 2018-02-14 03:24, Thomas Stüfe wrote:
>
>> Hi all,
>>
>> On Windows, if one has multiple VS installations side by side, is it
>> possible to choose which Visual Studio installation to use?
>>
>> Note that I start the configure script from within the cygwin shell.
>>
>> Thanks, Thomas
>>
>
>

Re: JDK10 build problem: "--module-path"?

[Martin Buchholz]

Looking at
https://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=openjdk-9-jdk&searchon=names
it seems like Ubuntu ships whatever openjdk-9 is available at time of
creation of a specific version, and doesn't update it afterwards, not even
for the quarterly security patches.

On Thu, Feb 15, 2018 at 7:42 AM, Erik Joelsson 
wrote:

> I have hit this same problem once for the same reason Alan describes.
> Ubuntu provided me with a really old EA build of 9.
>
> /Erik
>
>
>
> On 2018-02-15 00:05, Alan Bateman wrote:
>
>>
>>
>> On 15/02/2018 06:32, Ted Neward wrote:
>>
>>> Really?!? I thought the javac -help only listed -modulepath. Not to
>>> disbelieve you *grin*, but are you sure? The reason I ask is (barring some
>>> really bizarre misconfiguration) I should be using the OpenJDK9 as the boot
>>> JDK for this, and I'm getting the error.
>>>
>>> What is your boot JDK? Any possibility that you have really old EA build
>> of JDK 9?
>>
>
>

Re: JDK10 build problem: "--module-path"?

[Erik Joelsson]

I have hit this same problem once for the same reason Alan describes. 
Ubuntu provided me with a really old EA build of 9.


/Erik


On 2018-02-15 00:05, Alan Bateman wrote:



On 15/02/2018 06:32, Ted Neward wrote:
Really?!? I thought the javac -help only listed -modulepath. Not to 
disbelieve you *grin*, but are you sure? The reason I ask is (barring 
some really bizarre misconfiguration) I should be using the OpenJDK9 
as the boot JDK for this, and I'm getting the error.


What is your boot JDK? Any possibility that you have really old EA 
build of JDK 9?

Re: RFR: JDK-8198227 Fix COMPARE_BUILD after forest consolidation

[Erik Joelsson]

Looks good.

/Erik


On 2018-02-15 06:14, Magnus Ihse Bursie wrote:
The new repo structure with the forest consolidation broke the 
COMPARE_BUILD functionality when using a closed repo.


Bug: https://bugs.openjdk.java.net/browse/JDK-8198227
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8198227-fix-COMPARE_BUILD-in-CLOSED_ROOT/webrev.01

Re: macOS High Sierra, version 10.13.2 configure: error: Couldnotfind freetype! You might be able to fix this by running 'brewinstallfreetype'

[Erik Joelsson]

You could hack configure to disable that check and try a slightly newer 
xcode. Maybe 5.x or 6.x works well enough. It's likely that you then 
also need to add --disable-warnings-as-errors to configure. You could 
also try installing an older Macos as a virtual machine on your current 
mac. Note though that the licensing around that is unclear.


/Erik


On 2018-02-14 16:35, mbl wrote:

Thank you to let me know,

You are right, i see my Xcode 4 is , so what can I do if I still want 
to build openjdk on my macos? I really don not want to downgrade my 
Mac OS.


On 14 Feb 2018, at 00:55, Erik Joelsson > wrote:


Hello,

My guess would be that Xcode 4 isn't working on Macos 10.13. 
Internally we build JDK 8 on 10.8.


/Erik


On 2018-02-13 01:41, mbl wrote:

Thank you for your kind help, I’ve jump out of the last pit.

Now the new challenge is:

I execute the following command:

 bash ../8dev/configure 
 --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home 
--with-freetype=/usr/local/Cellar/freetype/2.9/ --enable-ccache 
--with-jvm-variants=server 
--with-boot-jdk-jvmargs="-Xlint:deprecation -Xlint:unchecked" 
--disable-zip-debug-info 
MAKE=/Applications/Xcode9.app/Contents/Developer/usr/bin/make


But I see the following error

dyld: Library not loaded: 
@rpath/DVTFoundation.framework/Versions/A/DVTFoundation
  Referenced from: 
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild

  Reason: no suitable image found.  Did find:
/Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation: 
cannot load 
'/Applications/Xcode.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation' 
because Objective-C garbage collection is not supported
xcrun: error: unable to locate xcodebuild, please make sure the path 
to the Xcode folder is set correctly!
xcrun: error: You can set the path to the Xcode folder using 
/usr/bin/xcode-select -switch
configure: error: Xcode 4 is required to build JDK 8, the version 
found was . Use --with-xcode-path to specify the location of Xcode 4 
or make Xcode 4 active by using xcode-select.

configure exiting with result code 1


Please help me more. Thank your advance!


My Env is:

  * OS: macOS High Sierra, version 10.13.
  * Repo : http://hg.openjdk.java.net/jdk8u/jdk8u-dev/
  * Tags: jdk8u162-b12



Other info:

  * The configure error pick me to mv my default xcode (9.0.4) to a
backup as `/Applications/Xcode9.app`. I install Xcode4.6.3 to
`Applications/Xcode.app`, and execute `sudo xcode-select -switch
/Applications/Xcode.app/Contents/Developer` to active it.




On 13 Feb 2018, at 02:47, Erik Joelsson > wrote:


Hello,

I just tried this myself and configure is automatically picking up 
my freetype from brew in /usr/local/opt/freetype/. Looking at my 
log, this is done using pkg-config from brew. So you could try 
installing pkg-config (brew install pkg-config). You can also try 
adding --with-freetype=/usr/local/opt/freetype if that's where brew 
installed it for you.


/Erik


On 2018-02-11 22:51, mbl wrote:

OS: macOS High Sierra, version 10.13.2
Repo : https://github.com/dmlloyd/openjdk.git
Branch : jdk/jdk

mbldeMacBook-Pro:openjdk mbl$ bash ./configure 
--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk9.0.4.jdk/Home

configure: Configuration created at Mon Feb 12 14:43:36 CST 2018.
configure: error: Could not find freetype! You might be able to 
fix this by running 'brew install freetype'.
/projects/jdpros/openjdk/.build/generated-configure.sh: line 82: 
5: Bad file descriptor

configure exiting with result code 1
mbldeMacBook-Pro:openjdk mbl$ sudo brew install freetype
Password:
Error: Running Homebrew as root is extremely dangerous and no 
longer supported.
As Homebrew does not drop privileges on installation you would be 
giving all

build scripts full access to your system.
mbldeMacBook-Pro:openjdk mbl$ brew install freetype
Updating Homebrew...
Warning: freetype 2.9 is already installed


What can I do?

Re: Choosing which Visual Studio installation to use

[Erik Joelsson]

Hello,

Just want to clear some things up around this. We use Cygwin just as a 
unix emulation layer for running typical unix tools. OpenJDK can only be 
built on Windows using Visual Studio as the compiler toolchain. We 
currently don't support any other unix emulation layer. We have had 
support for msys and we may work with msys2, but it's not being actively 
maintained so I'm pretty sure that has bit rotted by now. It's correct 
that if we actually used the gcc from cygwin, we would build for cygwin 
and not windows.


In the future I would like to support WSL, but it will require some 
work. I do believe the latest version is competent enough to get 
everything we need working though.


/Erik


On 2018-02-14 05:16, John Paul Adrian Glaubitz wrote:

On 02/14/2018 02:07 PM, Thomas Stüfe wrote:

    Does it have to be Cygwin though?


Yes. I love cygwin. You can put it into fullscreen and pretend you 
have a very slow Linux machine :) But seriously, it is very stable 
and mature, would not like at all to change my environment.


Yes, but, if I remember correctly, the problem is that anything built
with Cygwin always requires Cygwin to be present to be able to run.

You always have to carry the runtime around if I remember correctly.

    On Windows I usually install the "git bash for Windows" package 
or whatever
    it's called and it gives me a nice bash command prompt with a 
working git
    and bash environment. You can then call the environment scripts 
from there.



Can you do a full openjdk build with that?
I haven't tried OpenJDK. But in my previous company we did heavy Qt 
development
with git bash for Windows and any additional external libraries that 
were required
could usually be installed manually. It required some elbow grease, 
but at least
the resulting binaries were regular Win32 applications which didn't 
require any
particular runtime environment to be present except for the DLLs the 
binaries

were linked against.

Adrian

Re: JDK10 build problem: "--module-path"?

[Jonathan Gibbons]

Ted,

Yes, I'm sure :-) This is the relevant line from the source code for JDK 
9, listing --module-path and -p as alternatives for this option.


MODULE_PATH("--module-path -p", "opt.arg.path", "opt.modulepath", 
STANDARD, FILEMANAGER),



http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/65bfdabaab9c/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java#l183 



-- Jon

On 2/14/18 10:32 PM, Ted Neward wrote:

Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve 
you *grin*, but are you sure? The reason I ask is (barring some really bizarre 
misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and 
I'm getting the error.

Ted Neward
Author, Speaker, Mentor
http://www.newardassociates.com
t: @tedneward | m: (425) 647-4526

On 2/14/18, 6:53 PM, "build-dev on behalf of Jonathan Gibbons" 
 wrote:

 
 
 On 2/14/18 4:38 PM, Ted Neward wrote:

 > I’m getting a weird error in my OpenJDK 10 (tip) build, where after 
pulling source and configure, I get a build error about the Java compiler being 
executed with “--module-path” as a parameter, which obviously isn’t a legitimate 
javac flag.
 >
 >
 I can't speak to your specific build error, but --module-path is a
 legitimate javac option, as of JDK 9.
 
 -- Jon
 
 >

 > Is this just me? Is anybody else able to repro this, and is there a fix 
coming that isn’t checked into the main trunk yet?
 >
 >
 >
 > I am in the process of finalizing some Docker images (both with the 
source inside the image and built, so people can just “go”, as well as images with 
the prereqs and some shell scripts to do the build with the source and build 
artifacts on the host machine), and this is holding up the current “tip” images 
from being really ready for public consumption. (JDK8u and JDK9 are up and ready 
to go.)
 >
 >
 >
 > Ted Neward
 >
 > Author, Speaker, Mentor
 >
 > http://www.newardassociates.com
 >
 > t: @tedneward | m: (425) 647-4526
 >
 
 

Re: Choosing which Visual Studio installation to use

[Erik Joelsson]

Hello Thomas,

If you have multiple versions installed, configure will pick the one to 
use in order of most supported. To explicitly pick one, you can use 
--with-toolchain-version=2010 (or some other number) and configure will 
look for that specific version of Visual Studio. Just pointing to an 
install dir or bin dir does not work because configure needs to know 
which version it is dealing with and we haven't implemented smart enough 
discovery logic to automatically figure that out.


Note that I recently added configure support for 2015 and 2017 in JDK 
11. This does NOT mean the product actually builds with those and 
configure will print warnings accordingly. We are working on properly 
supporting 2017, but it's apparently non trivial.


/Erik


On 2018-02-14 03:24, Thomas Stüfe wrote:

Hi all,

On Windows, if one has multiple VS installations side by side, is it
possible to choose which Visual Studio installation to use?

Note that I start the configure script from within the cygwin shell.

Thanks, Thomas

Re: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM)

[sangheon.kim]

Hi Thomas,

On 02/15/2018 03:32 AM, Thomas Schatzl wrote:

Hi,

On Wed, 2018-02-14 at 13:45 -0800, sangheon.kim wrote:

Hi all,

Could I have some reviews for CMM removal?
This is closed CR but some public codes also need small
modifications.
This CR is for removing stuff related to an Oracle JDK
module/package.
Changes are just removing CMM from lists or in a test to skip the
testing logic.

CR: https://bugs.openjdk.java.net/browse/JDK-8193909
Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0
Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core


   looks good.

Thank you for your review!

Sangheon




Thomas

RFR: JDK-8198227 Fix COMPARE_BUILD after forest consolidation

[Magnus Ihse Bursie]

The new repo structure with the forest consolidation broke the 
COMPARE_BUILD functionality when using a closed repo.


Bug: https://bugs.openjdk.java.net/browse/JDK-8198227
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8198227-fix-COMPARE_BUILD-in-CLOSED_ROOT/webrev.01

[PATCH] Add post custom extension hooks to two launchers

[Ben Walsh]

This patch simply adds a hook to two launchers to call a post custom 
extension 
if it is available.

I would like to pair with a sponsor to contribute this patch ...



diff -r 85c27aabf312 make/launcher/Launcher-jdk.jcmd.gmk
--- a/make/launcher/Launcher-jdk.jcmd.gmk   Thu Feb 08 10:06:57 2018 
-0500
+++ b/make/launcher/Launcher-jdk.jcmd.gmk   Thu Feb 15 11:16:28 2018 
+
@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights 
reserved.
+# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights 
reserved.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or modify it
@@ -60,3 +60,6 @@
 $(eval $(call SetupBuildLauncher, jcmd, \
 MAIN_CLASS := sun.tools.jcmd.JCmd, \
 ))
+
+# Hook to include the corresponding custom file, if present.
+$(eval $(call IncludeCustomExtension, 
launcher/Launcher-jdk.jcmd-post.gmk))
diff -r 85c27aabf312 make/launcher/Launcher-jdk.jstatd.gmk
--- a/make/launcher/Launcher-jdk.jstatd.gmk Thu Feb 08 10:06:57 2018 
-0500
+++ b/make/launcher/Launcher-jdk.jstatd.gmk Thu Feb 15 11:16:28 2018 
+
@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights 
reserved.
+# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights 
reserved.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or modify it
@@ -28,3 +28,6 @@
 $(eval $(call SetupBuildLauncher, jstatd, \
 MAIN_CLASS := sun.tools.jstatd.Jstatd, \
 ))
+
+# Hook to include the corresponding custom file, if present.
+$(eval $(call IncludeCustomExtension, 
launcher/Launcher-jdk.jstatd-post.gmk))



Regards,
Ben Walsh


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

Re: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM)

[Thomas Schatzl]

Hi,

On Wed, 2018-02-14 at 13:45 -0800, sangheon.kim wrote:
> Hi all,
> 
> Could I have some reviews for CMM removal?
> This is closed CR but some public codes also need small
> modifications. 
> This CR is for removing stuff related to an Oracle JDK
> module/package.
> Changes are just removing CMM from lists or in a test to skip the 
> testing logic.
> 
> CR: https://bugs.openjdk.java.net/browse/JDK-8193909
> Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0
> Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core
> 

  looks good.

Thomas

Re: JDK10 build problem: "--module-path"?

[Alan Bateman]

On 15/02/2018 06:32, Ted Neward wrote:

Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve 
you *grin*, but are you sure? The reason I ask is (barring some really bizarre 
misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and 
I'm getting the error.

What is your boot JDK? Any possibility that you have really old EA build 
of JDK 9?