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 wh
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.
>
> Testin
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/~dh
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
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
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 fr
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
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 w
>> 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 Appl
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 init
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.
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 NEW
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
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
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
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
repo
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
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
tho
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 t
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 aft
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: "build-dev@openjdk.java.net"
Sent: Friday, May 10,
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 c
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
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
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 bel
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 chan
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
27 matches
Mail list logo
