Re: RFR 8030011: Update Hotspot version string output
On 4/18/2014 6:50 PM, John Coomes wrote:
Alejandro E Murillo (alejandro.muri...@oracle.com) wrote:
Please review this change to make the hotspot related output produced by
java -version
match the corresponding JDK output:
webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
Note that we initially wanted to obtain more information from the repo
being built and add
it to the hotspot version output, but that will require changes in the
JPRT, so
we have decided to split the change in 2 bugs. One to make the version match
(above webrev) and another one, an RFE, to add additional information
extracted from the repo.
Generally looks good, but I agree with David that the long lines
should be wrapped, and it might even be clearer to separate them into
two variables, e.g.,
JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ \
-DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ \
... other defs ...
VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ \
-DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ \
$(JDK_VERSION_DEFS)
Also the change to this part of vm.make differs between at least the
solaris version and the linux version (didn't check bsd or windows).
Please make them all consistent.
Note that in the current version of vm_version.cpp, there is no error
checking in product mode,
I was suggested to make that explicit.
I like the additional error checking. I think you could eliminate the
4 copies of similar code with a function that does the checks and sets
the field, e.g.,
void set_version_field(int * version_field, const char * version_str,
const char * const assert_msg) {
if (version_str != NULL ...) {
DEBUG_ONLY(assert_digits(version_str, assert_msg));
*version_field = atoi(version_str);
}
}
-John
Thanks John,
working on adding these changes and sanity testing
Thanks
--
Alejandro
RFR: [8038961] kinit, klist and ktab aren't built from jdk7u51 in licensee src bundles
Hello! This is a 7u only issue. I was reported that kerberos tools aren't built from the licensee source bundle. The cause is that building of the launchers is started from the 'build' target in the Makefile. On Windows, the 'build' target is only defined, if ./common/Library.gmk is included, and this is included when ./jdk/windows/native/sun/security/krb5 directory exists. This is not the case for the licensee source bundle. It appears to be enough to replace the 'build' target with 'all': BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038961 WEBREV: http://cr.openjdk.java.net/~igerasim/8038961/0/webrev/ Sincerely yours, Ivan
Re: RFR 8030011: Update Hotspot version string output
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.
Next should be 2014 (I think David pointed it too but there is no new
webrev): HOTSPOT_VM_COPYRIGHT=Copyright 2013
If you pass major, micro etc numbers to avoid parsing you need to verify
that constructed from them string is equal to passed
HOTSPOT_RELEASE_VERSION.
Next assert message is not consistent with previous messages which use
vm, I think it should be vm here too:
DEBUG_ONLY(assert_digits(vm_build_num, offset, wrong JDK build
number));
Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.
Use corresponding test in jdk for testing of these changes:
jdk/test/sun/misc/Version/Version.java
jvm.h: Next comment is not accurate:
+/* VM version string: JDK version string */
If we build VM separately (for example, in JPRT) VM version will not be
JDK version in which VM is installed. It will take numbers either from
passed make parameters or from make/hotspot_version. I think it should say:
+/* VM version string follows the JDK release version naming convention
+ * major.minor.micro-bxx[-identifier][-debug_flavor]
Based on your examples [-identifier][-debug_flavor] is still used so
it should be reflected in the comment.
Don't remove next comments from vm_version.cpp but fix it (follow the
JDK release):
-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// major_ver.minor_ver-bnn[-identifier][-debug_target]
You did not show default VM version example when VM is built locally by
engineer.
Please test that correct version string is constructed when you build VM
using make/build.sh, for example 'sh make/build.sh debug LP64=1'
Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:
-# HOTSPOT_RELEASE_VERSION - major.minor-bnn (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus HOTSPOT_BUILD_VERSION
see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:
-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I know that windows build is mess. Please verify it carefully. For
example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but
build.make uses them:
JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER)
Regards,
Vladimir
On 4/21/14 10:13 AM, Alejandro E Murillo wrote:
On 4/18/2014 6:50 PM, John Coomes wrote:
Alejandro E Murillo (alejandro.muri...@oracle.com) wrote:
Please review this change to make the hotspot related output produced by
java -version
match the corresponding JDK output:
webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
Note that we initially wanted to obtain more information from the repo
being built and add
it to the hotspot version output, but that will require changes in the
JPRT, so
we have decided to split the change in 2 bugs. One to make the
version match
(above webrev) and another one, an RFE, to add additional information
extracted from the repo.
Generally looks good, but I agree with David that the long lines
should be wrapped, and it might even be clearer to separate them into
two variables, e.g.,
JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ \
-DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ \
... other defs ...
VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ \
-DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ \
$(JDK_VERSION_DEFS)
Also the change to this part of vm.make differs between at least the
solaris version and the linux version (didn't check bsd or windows).
Please make them all consistent.
Note that in the current version of vm_version.cpp, there is no error
checking in product mode,
I was suggested to make that explicit.
I like the additional error checking. I think you could eliminate the
4 copies of similar code with a function that does the checks and sets
the field, e.g.,
void set_version_field(int * version_field, const char *
version_str,
const char * const assert_msg) {
if (version_str != NULL ...) {
DEBUG_ONLY(assert_digits(version_str, assert_msg));
*version_field = atoi(version_str);
}
}
-John
Thanks John,
working on adding these changes and sanity testing
Thanks
URGENT RFR: 8041141: JDK9 emb build failure on PPC platform
http://cr.openjdk.java.net/~dholmes/8041141/webrev/ The recent changes to convert warnings to errors didn't account for some type-punning warnings in our Embedded PPC build due to the use of strict-aliasing. Really we shouldn't be using strict-aliasing so this change (which for some reason is in the open flags.m4 file) brings ppc in-line with all other platforms and sets -fno-strict-aliasing I will be pushing this to jdk9/dev as we need this fixed immediately. Thanks, David
Re: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform
Hi David: http://cr.openjdk.java.net/~dholmes/8041141/webrev/ The recent changes to convert warnings to errors didn't account for some type-punning warnings in our Embedded PPC build due to the use of strict-aliasing. Really we shouldn't be using strict-aliasing so this change (which for some reason is in the open flags.m4 file) brings ppc in-line with all other platforms and sets -fno-strict-aliasing I will be pushing this to jdk9/dev as we need this fixed immediately. Looks good to me. Tim
Re: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform
Thanks Tim! Changes pushed. David On 22/04/2014 9:57 AM, Tim Bell wrote: Hi David: http://cr.openjdk.java.net/~dholmes/8041141/webrev/ The recent changes to convert warnings to errors didn't account for some type-punning warnings in our Embedded PPC build due to the use of strict-aliasing. Really we shouldn't be using strict-aliasing so this change (which for some reason is in the open flags.m4 file) brings ppc in-line with all other platforms and sets -fno-strict-aliasing I will be pushing this to jdk9/dev as we need this fixed immediately. Looks good to me. Tim
Re: JDK-8025705
2014/4/16 14:52 -0700, david.hol...@oracle.com: src/closed is Oracle's custom source location (hotspot calls it alt_src). If we never saw src/closed in the makefiles, only CUSTOM_SRC_DIR, and guarded with an existence test for a specific directory/file, then that should address your problem. That would be a first step in moving things to the custom makefiles where they belong. I'm opposed to the ORACLEJDK variable because I want to maintain the pressure to get this fixed properly. If we hack around it then it will never get cleaned up. I think it's wrong, in principle, for OpenJDK source code to contain identifiers naming specific vendors of JDK implementations. We're not quite there at the moment, but let's please not add any more. - Mark
Re: building 7u on macosx
On 19/04/2014 5:25 AM, Pete Brunet wrote: Success. I found this post from Arun Gupta: https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on which specifies this make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v1.6` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` rather than this CPATH=/usr/X11/include LANG=C make ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` at https://wiki.openjdk.java.net/display/MacOSXPort/Main The differences are: - At the front, remove: CPATH=/usr/X11/include LANG=C - Add this: SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true You missed the v1.6 vs v1.7+ on the ALT_BOOTDIR setting. I suspect that is the real difference. David - I didn't yet investigate if there is a subset of the changes that would be successful. Pete On 4/18/14 1:43 PM, Pete Brunet wrote: I see Mac downloads for 7u55 so I should be able to build 7u. But the instructions at https://wiki.openjdk.java.net/display/MacOSXPort/Main are for 8 so maybe the instructions are different for 7? The instuctions in the 7 section of http://openjdk.java.net/groups/build/ have no mention of mac os x. Pete On 4/18/14 11:59 AM, Pete Brunet wrote: Maybe 7 is not supported? The reason I am trying to build it is to back port two bugs from 9, but maybe that's not needed. On 4/18/14 11:39 AM, Pete Brunet wrote: Hi, It's been a long time since I built 7 on macosx. Refering to https://wiki.openjdk.java.net/display/MacOSXPort/Main I see these instructions CPATH=/usr/X11/include LANG=C make ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` but that fails. See the log below. Are the instructions still OK? Pete ptb-mbp-2:jdk7 petebrunet$ CPATH=/usr/X11/include LANG=C make ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` ( cd ./jdk/make \ make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64 ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import BUILD_HOTSPOT=true ; ) Build Machine Information: build machine = ptb-mbp-2.local Build Directory Structure: CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7 TOPDIR = . LANGTOOLS_TOPDIR = ./langtools JAXP_TOPDIR = ./jaxp JAXWS_TOPDIR = ./jaxws CORBA_TOPDIR = ./corba HOTSPOT_TOPDIR = ./hotspot JDK_TOPDIR = ./jdk Build Directives: BUILD_LANGTOOLS = true BUILD_JAXP = true BUILD_JAXWS = true BUILD_CORBA = true BUILD_HOTSPOT = true BUILD_JDK= true DEBUG_CLASSFILES = DEBUG_BINARIES = Hotspot Settings: HOTSPOT_BUILD_JOBS = 8 HOTSPOT_OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir HOTSPOT_EXPORT_PATH = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import Bootstrap Settings: BOOTDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home ALT_BOOTDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home BOOT_VER = 1.8.0 [requires at least 1.6] OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64 ALT_OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64 ABS_OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64 Build Tool Settings: SLASH_JAVA = /java ALT_SLASH_JAVA = VARIANT = OPT JDK_DEVTOOLS_DIR = /java/devtools ALT_JDK_DEVTOOLS_DIR = ANT_HOME = UNIXCOMMAND_PATH = /bin/ ALT_UNIXCOMMAND_PATH = COMPILER_PATH = /Applications/Xcode.app/Contents/Developer/usr/bin/ ALT_COMPILER_PATH = DEVTOOLS_PATH = /opt/local/bin/ ALT_DEVTOOLS_PATH = COMPILER_NAME = LLVM-GCC4 COMPILER_VERSION = LLVM-GCC4 CC_VER = 4.2.1 [requires at least 4.2.1] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = 5.52 [requires at least
Re: building 7u on macosx
On 4/21/14 9:30 PM, David Holmes wrote: On 19/04/2014 5:25 AM, Pete Brunet wrote: Success. I found this post from Arun Gupta: https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on which specifies this make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v1.6` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` rather than this CPATH=/usr/X11/include LANG=C make ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` at https://wiki.openjdk.java.net/display/MacOSXPort/Main The differences are: - At the front, remove: CPATH=/usr/X11/include LANG=C - Add this: SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true You missed the v1.6 vs v1.7+ on the ALT_BOOTDIR setting. I suspect that is the real difference. Thanks David, That makes sense. What does -v do? I didn't find a spec describing it. -Pete David - I didn't yet investigate if there is a subset of the changes that would be successful. Pete On 4/18/14 1:43 PM, Pete Brunet wrote: I see Mac downloads for 7u55 so I should be able to build 7u. But the instructions at https://wiki.openjdk.java.net/display/MacOSXPort/Main are for 8 so maybe the instructions are different for 7? The instuctions in the 7 section of http://openjdk.java.net/groups/build/ have no mention of mac os x. Pete On 4/18/14 11:59 AM, Pete Brunet wrote: Maybe 7 is not supported? The reason I am trying to build it is to back port two bugs from 9, but maybe that's not needed. On 4/18/14 11:39 AM, Pete Brunet wrote: Hi, It's been a long time since I built 7 on macosx. Refering to https://wiki.openjdk.java.net/display/MacOSXPort/Main I see these instructions CPATH=/usr/X11/include LANG=C make ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` but that fails. See the log below. Are the instructions still OK? Pete ptb-mbp-2:jdk7 petebrunet$ CPATH=/usr/X11/include LANG=C make ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` ( cd ./jdk/make \ make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64 ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import BUILD_HOTSPOT=true ; ) Build Machine Information: build machine = ptb-mbp-2.local Build Directory Structure: CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7 TOPDIR = . LANGTOOLS_TOPDIR = ./langtools JAXP_TOPDIR = ./jaxp JAXWS_TOPDIR = ./jaxws CORBA_TOPDIR = ./corba HOTSPOT_TOPDIR = ./hotspot JDK_TOPDIR = ./jdk Build Directives: BUILD_LANGTOOLS = true BUILD_JAXP = true BUILD_JAXWS = true BUILD_CORBA = true BUILD_HOTSPOT = true BUILD_JDK= true DEBUG_CLASSFILES = DEBUG_BINARIES = Hotspot Settings: HOTSPOT_BUILD_JOBS = 8 HOTSPOT_OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir HOTSPOT_EXPORT_PATH = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import Bootstrap Settings: BOOTDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home ALT_BOOTDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home BOOT_VER = 1.8.0 [requires at least 1.6] OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64 ALT_OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64 ABS_OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64 Build Tool Settings: SLASH_JAVA = /java ALT_SLASH_JAVA = VARIANT = OPT JDK_DEVTOOLS_DIR = /java/devtools ALT_JDK_DEVTOOLS_DIR = ANT_HOME = UNIXCOMMAND_PATH = /bin/ ALT_UNIXCOMMAND_PATH = COMPILER_PATH = /Applications/Xcode.app/Contents/Developer/usr/bin/
Re: JDK-8025705
Hi Mark, et al., The sad reality of the situation is that there is indeed Oracle-specific code in the OpenJDK makefiles, and this code interferes with our customization of the JDK. Adding temporary signposts to allow us (and others) to avoid this code will not make things worse. It doesn't have to be a distribution name -- we call it whatever you like: TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to latch onto to deactivate that code when it is not needed. This would provide immediate relief to customizing distributors and give Oracle engineers time to phase that code into closed makefiles (at which time the signposts can be removed completely). Taking all this code out wholesale instead would be great, and this is something I am totally willing to tackle and put the effort in on if I was in a position to do so. Unfortunately, since this is not fully open-source, I can't do the refactoring needed to move this code into the closed directories. And I though I could easily strip the code from OpenJDK, this would totally muck with Oracle distribution so any patch I would submit would surely be immediately rejected. Considering that the code is question has been in OpenJDK for about 8 years now, I think it's safe to assume that it's not a high priority item for Oracle engineers to get this fixed. Which is totally fine, IMO -- it's very much a tenant of open source development that he who has the itch ought to be the one to scratch it, and different entities are expected to have different sets of priorities. No doubt I'm probably the first one to complain about this :) Unfortunately, I'm also in the unfortunate position of having an itch (and willing fingernails), but an inability to scratch it. So, where do we go from here and how can I help in this effort? I really do want to help, as this is an immediate problem for me and I can't afford to wait years for it to get fixed. I still think that signposts are a very reasonable compromise given that: (1) It is something that can be done independently and doesn't require Oracle engineering resources (other than reviews and shepherding) (2) It does not interfere with efforts to move closed code out of OpenJDK makefiles (3) it can be done quickly (4) It does not avoid the Makefile-checking for existence of required files/directories (which reduces build-brittleness) Mark/Dave, if I can't convince you that we should take this path, can you please suggest an alternative design? I'm not picky -- if we can come up with something else that works then let's do it and I'll start on it right away. -- - Keith (itchy) On Mon, Apr 21, 2014 at 8:23 PM, mark.reinh...@oracle.com wrote: 2014/4/16 14:52 -0700, david.hol...@oracle.com: src/closed is Oracle's custom source location (hotspot calls it alt_src). If we never saw src/closed in the makefiles, only CUSTOM_SRC_DIR, and guarded with an existence test for a specific directory/file, then that should address your problem. That would be a first step in moving things to the custom makefiles where they belong. I'm opposed to the ORACLEJDK variable because I want to maintain the pressure to get this fixed properly. If we hack around it then it will never get cleaned up. I think it's wrong, in principle, for OpenJDK source code to contain identifiers naming specific vendors of JDK implementations. We're not quite there at the moment, but let's please not add any more. - Mark
