Re: Is slowdebug supposed to also compile JNI portions of JDK with -g?
It is supposed to compile everything with debug turned on AFAIK. I will take a look. /Erik On 2013-05-09 20:10, David Chase wrote: Because for me it did not, at least not on a Mac. My workaround, which was not too painful because the new build seems to use fully-qualified path names: touch jdk/src/share/native/java/util/zip/CRC32.c make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug ... touch jdk/src/share/native/java/util/zip/CRC32.c # copy compilation command line from above log, add -g, paste ... /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -g ... /Users/dr2chase/work/jdk8tl-full/jdk/src/share/native/java/util/zip/CRC32.c make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug and now I am debugging. But it would be better yet to compile those files for debugging. David
Re: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds)
Dmitry, On 12/05/2013 23:42, Dmitry Samersoff wrote: Mark, I did some experiments on weekends and I'm against of using -u option under any circumstances. There are valid usecases for '-u'. For one, sync'ing from upstream projects, Doug's CVS comes to mind. -Chris. People sponsoring changeset can make a mistake - most obvious one is wrong merge conflict resolution. If it happens we are loosing the way to solve the problem quickly - author know nothing about conflict but we have no obvious record about sponsor. So I think we have only two options (leaving aside extra repo) - a) author prepare changeset by it's own and sponsor acts just as slow bot - all problems transmitted back to author. b) author send a webrev and sponsor uses Contributed-by: field to respect credits. -Dmitry On 2013-05-10 01:47, [email protected] wrote: 2013/5/9 2:10 -0700, [email protected]: Indeed. I do this with the Oracle patches when applying them to IcedTea. The problem is how this gets done is down to the sponsor; I've had ones that have been imported, ones where I've just been giving the Contributed-by attribution (despite having commit rights) and at least one with no credit at ... An example I just came across when looking into an issue: changeset: 2657:46cb9a7b8b01 parent: 2647:ca1f1753c866 user:dsamersoff date:Wed Aug 10 15:04:21 2011 +0400 files: src/share/vm/runtime/os.cpp description: 7073913: The fix for 7017193 causes segfaults Summary: Buffer overflow in os::get_line_chars Reviewed-by: coleenp, dholmes, dcubed Contributed-by: [email protected] That should have had 'aph' as the user. If you get the default output: changeset: 2657:46cb9a7b8b01 parent: 2647:ca1f1753c866 user:dsamersoff date:Wed Aug 10 15:04:21 2011 +0400 summary: 7073913: The fix for 7017193 causes segfaults it looks like Dmitry wrote the fix. I'm sure there was no intent on Dmitry's part to try to claim credit for this fix. The most important principle to be maintained here is that people get proper credit for their work, as you wrote earlier. Beyond that, it's reasonable to prefer that credit be given in the "most obvious" way, in particular by using proper usernames, when available, in changesets. If a sponsor makes a mistake, however, and winds up using a Contributed-by: line instead, then that's unfortunate but not, in my view, the end of the world. In general, if you have the Author role (or higher) in some OpenJDK Project then when you submit a change that requires a sponsor's help you should send a Mercurial patch (hg export) or bundle (hg bundle) with the proper username, summary, etc. In normal circumstances the sponsor should not change the patch but merely make sure that it's properly tested, merged, and pushed. If a change is required then the sponsor should ask the submitter to create a new patch or bundle. If for some reason the sponsor must modify the patch directly then the hg -u option should be used, as appropriate, to preserve the submitter's user name in the changeset. (Yes, this is one of those rare cases in which a sponsor should use the -u option.) Iris -- Could you please make a note to add guidance on this issue to the next revision of the developers' guide? Thanks. - Mark
Re: JDK 8 code review request of langtools build changes for JDK-8014365 Restore Objects.requireNonNull(T, Supplier)
Looks good to me. On 2013-05-10 23:06, Joe Darcy wrote: Hello, Please review the patch below for JDK-8014365 "Restore Objects.requireNonNull(T, Supplier)" which addresses the issue tripped over during JDK-8012344 "Backout 8011800 until langtools genstubs updated." A full build with the below patch to langtools and the update JDK library succeeds. Thanks, -Joe diff -r ce7e1674eb73 makefiles/BuildLangtools.gmk --- a/makefiles/BuildLangtools.gmkFri May 10 16:10:20 2013 +0100 +++ b/makefiles/BuildLangtools.gmkFri May 10 14:04:29 2013 -0700 @@ -1,5 +1,5 @@ # -# Copyright (c) 2011, 2012, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2011, 2013, 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 @@ -123,10 +123,10 @@ genstubs.GenStubs # We fetch source from the JDK... JDKS=$(JDK_TOPDIR)/src/share/classes -# Build the list of classes to generate stubs from. java/util/Objects.java isn't +# Build the list of classes to generate stubs from. java/util/function/Predicate.java isn't # currently needed, but is used as a demo for now. STUBSOURCES:=$(shell $(FIND) $(JDKS) -name "*.java" | $(GREP) \ --e "$(JDKS)/java/util/Objects.java") +-e "$(JDKS)/java/util/function/Predicate.java") # Rewrite the file names into class names because the GenStubs tool require this. STUBCLASSES:=$(subst /,.,$(patsubst $(JDKS)/%.java,%,$(STUBSOURCES)))
Re: Is slowdebug supposed to also compile JNI portions of JDK with -g?
I've reproduced your problem. Looks like a mistake in common/autoconf/toolchain.m4. Filed JDK-8014404. /Erik On 2013-05-13 10:29, Erik Joelsson wrote: It is supposed to compile everything with debug turned on AFAIK. I will take a look. /Erik On 2013-05-09 20:10, David Chase wrote: Because for me it did not, at least not on a Mac. My workaround, which was not too painful because the new build seems to use fully-qualified path names: touch jdk/src/share/native/java/util/zip/CRC32.c make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug ... touch jdk/src/share/native/java/util/zip/CRC32.c # copy compilation command line from above log, add -g, paste ... /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -g ... /Users/dr2chase/work/jdk8tl-full/jdk/src/share/native/java/util/zip/CRC32.c make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug and now I am debugging. But it would be better yet to compile those files for debugging. David
Re: Please review changes for JDK-8012975: Remove rhino from jdk8
Incorporated changes as suggested. Uploaded webrev for historical purpose: http://cr.openjdk.java.net/~sundar/8012975/webrev.02/ PS. I am going ahead with push.. Thanks -Sundar On Friday 10 May 2013 06:17 PM, A. Sundararajan wrote: Okay, thanks. com.sun.script.util is not supported API (no CCC done for it in the past). I'll remove it as suggested and run "make profiles" to check Thanks -Sundar On Friday 10 May 2013 04:09 PM, Alan Bateman wrote: On 10/05/2013 11:23, A. Sundararajan wrote: com/sun/script/util is generic utility package for script engine implementations. Only com/sun/script/javascript package is being removed. Since we include javax/script for profile 3, should we also include com/sun/script/util ? Is com.sun.script.util meant to be a supported/documented API? Do you know if anything outside of the JDK is using it? Is Nashorn using it? The only usage I see is in com.sun.script.javascript so this is why I assumed that com.sun.script.** would go away. As you know, we moved javax.script to compact1. It doesn't require com.sun.script.util of course but if this is used by 3rd party scripting engines then it may have to be added to compact1 builds to get them working. On refs.allowed, I'll remove it. How should I check this? "make profiles" on Linux should be fine. As part of the profiles build it will run a dependency analyzer that checks for references to types that do not exist (this is catch configuration issues). -Alan
Re: Please review changes for JDK-8012975: Remove rhino from jdk8
On 13/05/2013 13:14, A. Sundararajan wrote: Incorporated changes as suggested. Uploaded webrev for historical purpose: http://cr.openjdk.java.net/~sundar/8012975/webrev.02/ PS. I am going ahead with push.. Thanks for fixing up refs.allowed, that one looks fine okay. Did you decide to keep com.sun.script.util? Just wondering because it appears that only com.sun.script.javascript is being removed. If the util API is going away then I assume that make/com/sun/script/Makefile should be removed (although we don't really care about the old build anymore). On the other, if the util API is staying then we need to figure out which profile is should go in. If nothing is using it then I assume it should be listed in FULL_JRE_RTJAR_INCLUDE_PACKAGES. -Alan
Re: how to install and build
I set up the openjdk7 mercurial project and did "make all". Now, I want to edit the appropriate Object.java file that make is using and issue "make". Is this possible? From: Weijun Wang To: Andy Nuss Cc: "[email protected]" Sent: Friday, May 10, 2013 6:17 AM Subject: Re: how to install and build Hi Andy If you only want to make small changes to .java files, just download the source code for those files, compile them with javac -d /tmp Those.java and call java -Xbootclasspath/p:/tmp YourApp to try out. If you don't like the -X option, you can call "jar uvf" to update the class files inside rt.jar with your newly built ones. -Max On 5/10/13 7:58 PM, Andy Nuss wrote: > Hi, > > I want to install jdk 7 project for linux 64, and make a simple change to > Object.java and test it. What do I do? > > Andy >
Disable overrides during jdk build
Please hold your fire! This is not a suggestion to about general handling of warnings during the build, just a specific gripe I have when trying to find genuine build failures among the noise. Would there be any objection to adding '-overrides' to the jdk build? This lint warning was added after the new build was introduced. I suspect it would have been suppressed originally if it was supported at the time. diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk --- a/makefiles/Setup.gmk +++ b/makefiles/Setup.gmk @@ -23,7 +23,7 @@ # questions. # -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides # The generate old bytecode javac setup uses the new compiler to compile for the # boot jdk to generate tools that need to be run with the boot jdk. -Chris. P.S. how to handle warnings generally will have to be addressed at some point, but I am not making any proposal at this time.
Re: MacOS build tool selections for JDK8
One reason to use gcc instead of clang would be to have one less difference between platforms. It's always annoying when different compilers have a different set of warnings (even if the warnings are correct and useful) and you try to get something to compile on all platforms. I don't know if there is any performance difference between the two - either in compile time or runtime performance of the generated code. /Staffan On 11 maj 2013, at 00:16, Tim Bell wrote: > All- > > The question of what toolchain to use on MacOS when building JDK8 is in play. > > This is important because the decisions we make in the next few weeks will be > in place for the lifetime of JDK8, including all future JDK8 update releases. > > I have a few different pieces of feedback at this point, and (due to my own > ignorance of the developer environment choices on MacOS), I'd like to throw > the discussion out to a larger audience of MacOS developers. > > 1) Use gcc as the build does today. > > 2) Use Clang. > > 3) Support both (since they should both compile the same source) but identify > Clang as the official tool. > > 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if > I am mistaken here) > > > As part of the build-infrastructure team, my #1 concern is getting solid, > repeatable builds from the toolchain, every time, that that's what I mean by > 'official'. > > If developers feel adventurous and want to run out ahead using bleeding edge > tools, good for them - have fun. > > What we would like to define here is a solid baseline of what we use to run > the official from-scratch JDK8 builds. That said, I'd like to nail down the > tools used, and the specific version of the tools. > > Thanks in advance for any feedback. > > Tim Bell > Java Platform Group Infrastructure >
Re: Disable overrides during jdk build
I think it makes sense, esp. if the messages appear to be redundant. The
compiler logic is very strict and there are cases where it comes down to
guessing user intent and compilers are notoriously bad at doing that. In
the long term, I'd like to see @SuppressWarnings("overrides") applied in
those cases where the impl knows what it's doing.
Maurizio
On 13/05/13 14:53, Chris Hegarty wrote:
Please hold your fire! This is not a suggestion to about general
handling of warnings during the build, just a specific gripe I have
when trying to find genuine build failures among the noise.
Would there be any objection to adding '-overrides' to the jdk build?
This lint warning was added after the new build was introduced. I
suspect it would have been suppressed originally if it was supported
at the time.
diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk
--- a/makefiles/Setup.gmk
+++ b/makefiles/Setup.gmk
@@ -23,7 +23,7 @@
# questions.
#
-DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally
+DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides
# The generate old bytecode javac setup uses the new compiler to
compile for the
# boot jdk to generate tools that need to be run with the boot jdk.
-Chris.
P.S. how to handle warnings generally will have to be addressed at
some point, but I am not making any proposal at this time.
Re: Disable overrides during jdk build
On 13/05/2013 15:24, Maurizio Cimadamore wrote:
I think it makes sense, esp. if the messages appear to be redundant. The
compiler logic is very strict and there are cases where it comes down to
guessing user intent and compilers are notoriously bad at doing that. In
the long term, I'd like to see @SuppressWarnings("overrides") applied in
those cases where the impl knows what it's doing.
Agreed. Tackling warnings, on a per area basis, is something that we
need to spend more time on.
I have not taken a look at the reason for the specific overrides
warnings. It is just that it appears the intent of the new build was to
suppress as many warnings as necessary, to make the output reasonable.
Since this warning was not in existence at the time, I could not be
suppressed.
@SuppressWarnings("overrides") can be added, where appropriate, during
future warning cleanup events.
-Chris.
Maurizio
On 13/05/13 14:53, Chris Hegarty wrote:
Please hold your fire! This is not a suggestion to about general
handling of warnings during the build, just a specific gripe I have
when trying to find genuine build failures among the noise.
Would there be any objection to adding '-overrides' to the jdk build?
This lint warning was added after the new build was introduced. I
suspect it would have been suppressed originally if it was supported
at the time.
diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk
--- a/makefiles/Setup.gmk
+++ b/makefiles/Setup.gmk
@@ -23,7 +23,7 @@
# questions.
#
-DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally
+DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides
# The generate old bytecode javac setup uses the new compiler to
compile for the
# boot jdk to generate tools that need to be run with the boot jdk.
-Chris.
P.S. how to handle warnings generally will have to be addressed at
some point, but I am not making any proposal at this time.
Re: Disable overrides during jdk build
No objection although it feels like we are going backwards rather than forwards. I submitted a few bugs on this topic recently as it seems to me that there aren't too many override warnings to kill off. Daniel Fuchs has a patch out for review today that fixes these warnings in the jaxp repository. The overrides warnings were also fixed in the jaxws repository as part of the bulk update a few weeks ago. That leaves 12 for the corba repository and about 29 in the jdk repository (29 on Linux at least, it varies by platform). I completely agree with you that the noise is high. On several occasions I've had to edit the build log to find the errors when they get lots in the warnings. I just wonder whether we should just fix what seems like a small number of warnings. -Alan On 13/05/2013 14:53, Chris Hegarty wrote: Please hold your fire! This is not a suggestion to about general handling of warnings during the build, just a specific gripe I have when trying to find genuine build failures among the noise. Would there be any objection to adding '-overrides' to the jdk build? This lint warning was added after the new build was introduced. I suspect it would have been suppressed originally if it was supported at the time. diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk --- a/makefiles/Setup.gmk +++ b/makefiles/Setup.gmk @@ -23,7 +23,7 @@ # questions. # -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides # The generate old bytecode javac setup uses the new compiler to compile for the # boot jdk to generate tools that need to be run with the boot jdk. -Chris. P.S. how to handle warnings generally will have to be addressed at some point, but I am not making any proposal at this time.
Re: Disable overrides during jdk build
I have no objection to someone fixing these warnings. They are across a number of different areas, and could take an amount of time to resolve. If we are to have a concerted effort, I'm not sure that I would start with these warnings. I too feel the pain, and it does appear that we are moving backwards on this problem, I just don't see that this is the right place to start. I'm just after a slightly easier life here, but I understand that this is a hot topic ;-) -Chris. On 13/05/2013 16:08, Alan Bateman wrote: No objection although it feels like we are going backwards rather than forwards. I submitted a few bugs on this topic recently as it seems to me that there aren't too many override warnings to kill off. Daniel Fuchs has a patch out for review today that fixes these warnings in the jaxp repository. The overrides warnings were also fixed in the jaxws repository as part of the bulk update a few weeks ago. That leaves 12 for the corba repository and about 29 in the jdk repository (29 on Linux at least, it varies by platform). I completely agree with you that the noise is high. On several occasions I've had to edit the build log to find the errors when they get lots in the warnings. I just wonder whether we should just fix what seems like a small number of warnings. -Alan On 13/05/2013 14:53, Chris Hegarty wrote: Please hold your fire! This is not a suggestion to about general handling of warnings during the build, just a specific gripe I have when trying to find genuine build failures among the noise. Would there be any objection to adding '-overrides' to the jdk build? This lint warning was added after the new build was introduced. I suspect it would have been suppressed originally if it was supported at the time. diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk --- a/makefiles/Setup.gmk +++ b/makefiles/Setup.gmk @@ -23,7 +23,7 @@ # questions. # -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides # The generate old bytecode javac setup uses the new compiler to compile for the # boot jdk to generate tools that need to be run with the boot jdk. -Chris. P.S. how to handle warnings generally will have to be addressed at some point, but I am not making any proposal at this time.
Re: Please review changes for JDK-8012975: Remove rhino from jdk8
I agree that it is better to remove com.sun.script.util package as well. It is not used elsewhere and was never declared as supported API. I've removed the same and re-generated webrev. http://cr.openjdk.java.net/~sundar/8012975/webrev.03/ I ran NEWBUILD=false as well as NEWBUILD=true to make sure build finishes fine. Please review. Thanks -Sundar On Monday 13 May 2013 05:56 PM, Alan Bateman wrote: On 13/05/2013 13:14, A. Sundararajan wrote: Incorporated changes as suggested. Uploaded webrev for historical purpose: http://cr.openjdk.java.net/~sundar/8012975/webrev.02/ PS. I am going ahead with push.. Thanks for fixing up refs.allowed, that one looks fine okay. Did you decide to keep com.sun.script.util? Just wondering because it appears that only com.sun.script.javascript is being removed. If the util API is going away then I assume that make/com/sun/script/Makefile should be removed (although we don't really care about the old build anymore). On the other, if the util API is staying then we need to figure out which profile is should go in. If nothing is using it then I assume it should be listed in FULL_JRE_RTJAR_INCLUDE_PACKAGES. -Alan
Re: MacOS build tool selections for JDK8
Clang emulates gcc (even so far as identifying itself as GCC for source level compatibility), they use the same command line arguments. Internally, clang has a somewhat better optimizer than gcc and feedback to the developer (warnings, error, etc..) is generally more useful than gcc. They both feed llvm so the backend is the same in either case. Apple seems to have a bigger investment in pushing clang forward than gcc, which generally means it has more of a future (there's never a guarantee though). I've been developing Mac OS X software since before the release of 10.0 and quite frankly the underlying tools haven't changed *that* much, the notable exception being when they dropped jam as the project tool. Windows has undergone far greater changes in that same time period.. If it were my choice, Mac OS X 10.8 would be the base OS with Xcode 4.6.1 (current) with clang as the officially supported compiler and with an option to use gcc. I don't see why that would't last at least the public lifecycle of JDK8. What I would be more concerned with is the apparent drift from what we know as Mac OS X towards something more iOS-like, that could mean libraries and frameworks we depend on no longer being available, but at that point it wouldn't be the same OS and we'd have to re-evaluate anyways. Sort of like what's happening with Windows 8 right now. -DrD- > One reason to use gcc instead of clang would be to have one less difference > between platforms. It's always annoying when different compilers have a > different set of warnings (even if the warnings are correct and useful) and > you try to get something to compile on all platforms. > > I don't know if there is any performance difference between the two - either > in compile time or runtime performance of the generated code. > > /Staffan > > On 11 maj 2013, at 00:16, Tim Bell wrote: > >> All- >> >> The question of what toolchain to use on MacOS when building JDK8 is in play. >> >> This is important because the decisions we make in the next few weeks will >> be in place for the lifetime of JDK8, including all future JDK8 update >> releases. >> >> I have a few different pieces of feedback at this point, and (due to my own >> ignorance of the developer environment choices on MacOS), I'd like to throw >> the discussion out to a larger audience of MacOS developers. >> >> 1) Use gcc as the build does today. >> >> 2) Use Clang. >> >> 3) Support both (since they should both compile the same source) but >> identify Clang as the official tool. >> >> 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if >> I am mistaken here) >> >> >> As part of the build-infrastructure team, my #1 concern is getting solid, >> repeatable builds from the toolchain, every time, that that's what I mean by >> 'official'. >> >> If developers feel adventurous and want to run out ahead using bleeding edge >> tools, good for them - have fun. >> >> What we would like to define here is a solid baseline of what we use to run >> the official from-scratch JDK8 builds. That said, I'd like to nail down the >> tools used, and the specific version of the tools. >> >> Thanks in advance for any feedback. >> >> Tim Bell >> Java Platform Group Infrastructure >> >
Re: Please review changes for JDK-8012975: Remove rhino from jdk8
On 13/05/2013 16:40, A. Sundararajan wrote: I agree that it is better to remove com.sun.script.util package as well. It is not used elsewhere and was never declared as supported API. I've removed the same and re-generated webrev. http://cr.openjdk.java.net/~sundar/8012975/webrev.03/ I ran NEWBUILD=false as well as NEWBUILD=true to make sure build finishes fine. Please review. Looks good to me. -Alan
Re: MacOS build tool selections for JDK8
On May 10 2013, at 15:16 , Tim Bell wrote: > All- > > The question of what toolchain to use on MacOS when building JDK8 is in play. > > This is important because the decisions we make in the next few weeks will be > in place for the lifetime of JDK8, including all future JDK8 update releases. > > I have a few different pieces of feedback at this point, and (due to my own > ignorance of the developer environment choices on MacOS), I'd like to throw > the discussion out to a larger audience of MacOS developers. > > 1) Use gcc as the build does today. Does this mean the gcc+clang provided by XCode or some random port of GCC (fink/macports)? I would be concerned with using "cygwin quality" (if that doesn't make you cringe you haven't been using cygwin long enough) GCC port rather than the Apple port. > 2) Use Clang. Is there any way to get clang for MacOS other than via XCode? Like using macports or fink GCC port I would be concerned about quality, stability and updates. > 3) Support both (since they should both compile the same source) but identify > Clang as the official tool. We're currently using the gcc front end. I think it would take signifiant work to switch to the clang front end. > 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if > I am mistaken here) This seems to be the only supported option. For Java 8 we have a mandate to support 10.7 which the current XCode tools allow us to do. I assume that the requirement to support 10.7 will remain through all of Java 8's support lifetime. It's unclear when XCode will stop supporting 10.7 though it would seem that when/if that happens we will be stuck with the last-supporting-10.7 version. > As part of the build-infrastructure team, my #1 concern is getting solid, > repeatable builds from the toolchain, every time, that that's what I mean by > 'official'. > > If developers feel adventurous and want to run out ahead using bleeding edge > tools, good for them - have fun. > > What we would like to define here is a solid baseline of what we use to run > the official from-scratch JDK8 builds. That said, I'd like to nail down the > tools used, and the specific version of the tools. > > Thanks in advance for any feedback. > > Tim Bell > Java Platform Group Infrastructure >
Re: Disable overrides during jdk build
Failure to have proper equals / hashCode behaviors can create hard to discover bugs if such objects are ever put in collections. By default, I would categorize these as real problems to be fixed and for a @SuppressWarning annotation to be wrong approach to resolve the warning. Since its initial implementation, the javac warning generation has been tuned to be smarter; it only reports a problem if hashCode isn't overridden anywhere in the superclass chain. (It is often possible to have more sharing among hashCode implementation than among equals implementations.) Regards, -Joe On 5/13/2013 8:36 AM, Chris Hegarty wrote: I have no objection to someone fixing these warnings. They are across a number of different areas, and could take an amount of time to resolve. If we are to have a concerted effort, I'm not sure that I would start with these warnings. I too feel the pain, and it does appear that we are moving backwards on this problem, I just don't see that this is the right place to start. I'm just after a slightly easier life here, but I understand that this is a hot topic ;-) -Chris. On 13/05/2013 16:08, Alan Bateman wrote: No objection although it feels like we are going backwards rather than forwards. I submitted a few bugs on this topic recently as it seems to me that there aren't too many override warnings to kill off. Daniel Fuchs has a patch out for review today that fixes these warnings in the jaxp repository. The overrides warnings were also fixed in the jaxws repository as part of the bulk update a few weeks ago. That leaves 12 for the corba repository and about 29 in the jdk repository (29 on Linux at least, it varies by platform). I completely agree with you that the noise is high. On several occasions I've had to edit the build log to find the errors when they get lots in the warnings. I just wonder whether we should just fix what seems like a small number of warnings. -Alan On 13/05/2013 14:53, Chris Hegarty wrote: Please hold your fire! This is not a suggestion to about general handling of warnings during the build, just a specific gripe I have when trying to find genuine build failures among the noise. Would there be any objection to adding '-overrides' to the jdk build? This lint warning was added after the new build was introduced. I suspect it would have been suppressed originally if it was supported at the time. diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk --- a/makefiles/Setup.gmk +++ b/makefiles/Setup.gmk @@ -23,7 +23,7 @@ # questions. # -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides # The generate old bytecode javac setup uses the new compiler to compile for the # boot jdk to generate tools that need to be run with the boot jdk. -Chris. P.S. how to handle warnings generally will have to be addressed at some point, but I am not making any proposal at this time.
Re: MacOS build tool selections for JDK8
>> 1) Use gcc as the build does today. > > Does this mean the gcc+clang provided by XCode or some random port of GCC > (fink/macports)? I would be concerned with using "cygwin quality" (if that > doesn't make you cringe you haven't been using cygwin long enough) GCC port > rather than the Apple port. GCC as provided by Apple in Xcode. >> 2) Use Clang. > > Is there any way to get clang for MacOS other than via XCode? Like using > macports or fink GCC port I would be concerned about quality, stability and > updates. Not with any assurance of quality. I would not condone the use of any tools outside of what Apple delivers, just as you don't condone the use of Cygwin tools on Windows :) As was said before, if someone wants to use a different compiler they're free to, but they're entirely on their own. >> 3) Support both (since they should both compile the same source) but >> identify Clang as the official tool. > > We're currently using the gcc front end. I think it would take signifiant > work to switch to the clang front end. In my experience it takes no work at all... > 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if > I am mistaken here) > > This seems to be the only supported option. For Java 8 we have a mandate to > support 10.7 which the current XCode tools allow us to do. I assume that the > requirement to support 10.7 will remain through all of Java 8's support > lifetime. It's unclear when XCode will stop supporting 10.7 though it would > seem that when/if that happens we will be stuck with the last-supporting-10.7 > version. The way Apple has developed their Mac OS X SDK, they never stop "supporting" a specific version of an OS. You can still build code that will run on 10.4 and later even with the 10.8 SDK (if targeting Intel), so ensuring our code will continue to work on 10.7 should not be a huge concern. That's what the -mmacosx-version-min argument is for. -DrD-
Re: MacOS build tool selections for JDK8
On 5/13/2013 1:21 PM, David DeHaven wrote: 3) Support both (since they should both compile the same source) but identify Clang as the official tool. We're currently using the gcc front end. I think it would take signifiant work to switch to the clang front end. In my experience it takes no work at all... Anyone attempted to build/test hotspot using clang rather than gcc? 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if I am mistaken here) This seems to be the only supported option. For Java 8 we have a mandate to support 10.7 which the current XCode tools allow us to do. I assume that the requirement to support 10.7 will remain through all of Java 8's support lifetime. It's unclear when XCode will stop supporting 10.7 though it would seem that when/if that happens we will be stuck with the last-supporting-10.7 version. The way Apple has developed their Mac OS X SDK, they never stop "supporting" a specific version of an OS. You can still build code that will run on 10.4 and later even with the 10.8 SDK (if targeting Intel), so ensuring our code will continue to work on 10.7 should not be a huge concern. That's what the -mmacosx-version-min argument is for. Does this imply the underlying version of macosx doesn't matter, as long as you're using Xcode 4.6.1 (or what ever we have standardized upon for JDK8) with -mmacosx-version-min=10.7? That would solve our new machines always having the latest macosx issue, that is as long as our instance of Xcode is supported. (the iOS-ifying of macosx) Thanks Dave
XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it
Trivial fix for the open arm.make files - we should only update the LIBS variable when EXT_LIBS_PATH is defined. webrev: http://cr.openjdk.java.net/~dholmes/8014460/webrev/ Pushing to hotspot-emb. Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM builds Thanks, David
Re: XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it
Hi David: Trivial fix for the open arm.make files - we should only update the LIBS variable when EXT_LIBS_PATH is defined. webrev: http://cr.openjdk.java.net/~dholmes/8014460/webrev/ Pushing to hotspot-emb. Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM build Looks good from the build side. Tim
RFR: 8014461 genstubs creates default native methods
genstubs is a utility used to help javac through the bootstrap process. It needs to be updated to strip the default modifier and method body from default methods in interfaces. I'm not sure if this should be a build-dev review or a compiler-dev review. -- Jon
Re: RFR: 8014461 genstubs creates default native methods
On 05/13/2013 06:23 PM, Jonathan Gibbons wrote: genstubs is a utility used to help javac through the bootstrap process. It needs to be updated to strip the default modifier and method body from default methods in interfaces. I'm not sure if this should be a build-dev review or a compiler-dev review. -- Jon Oops, I guess this would help: http://cr.openjdk.java.net/~jjg/8014461
Re: XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it
Looks good.. Don't think I count though Gary Sent from my iPad On May 13, 2013, at 5:35 PM, Tim Bell wrote: > Hi David: > >> Trivial fix for the open arm.make files - we should only update the LIBS >> variable when EXT_LIBS_PATH is defined. >> >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/8014460/webrev/ >> >> Pushing to hotspot-emb. >> >> Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM build > > Looks good from the build side. > > Tim >
Re: XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it
Looks good. /Staffan On 14 maj 2013, at 02:19, David Holmes wrote: > Trivial fix for the open arm.make files - we should only update the LIBS > variable when EXT_LIBS_PATH is defined. > > webrev: > > http://cr.openjdk.java.net/~dholmes/8014460/webrev/ > > Pushing to hotspot-emb. > > Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM builds > > Thanks, > David
Re: XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it
Thanks Staffan, and Gary and Tim. Unfortunately I still need a hsx Reviewer - thanks. David On 14/05/2013 3:14 PM, Staffan Larsen wrote: Looks good. /Staffan On 14 maj 2013, at 02:19, David Holmes wrote: Trivial fix for the open arm.make files - we should only update the LIBS variable when EXT_LIBS_PATH is defined. webrev: http://cr.openjdk.java.net/~dholmes/8014460/webrev/ Pushing to hotspot-emb. Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM builds Thanks, David
