On 28/02/2014 07:51, huizhe wang wrote:
Hi,
This is a fix to the license header for class
jdk/test/javax/xml/jaxp/transform/8004476/TestBase.java.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8036004
Webrev:
http://cr.openjdk.java.net/~joehw/jdk9/8036004/webrev/
Looks okay,
Hi all,
Currently, configure script can accept --disable-debug-symbols and
--disable-zip-debug-info as controlling to generate debug information.
However, current makefiles cannot build ELF binaries which is contained
debug information with images target.
Some Linux distros use RPM as package
On Feb 27, 2014, at 3:51 PM, Dr Heinz M. Kabutz he...@javaspecialists.eu
wrote:
I have never used this in the wild, but rather have moved over to the
ReentrantLock when I needed that particular functionality.
However, I do see a place for this ability. As I wrote in here:
Looks good to me!
Thanks,
/Staffan
On 27 feb 2014, at 16:34, roger riggs roger.ri...@oracle.com wrote:
Hi Mandy,
I updated the webrev:
http://cr.openjdk.java.net/~rriggs/webrev-testlibrary-asserts-8035889/
Alan suggested copying serviceability-dev so they have a chance to review if
Hi,
As I put in the bug report this seems way too complicated. Seems to me
all you need to do to get what you want is not use FDS and not strip the
symbols from the binary. The former is trivial. The latter is more
awkward as the strip policy stuff does not work as I would want it to
work, but
The proper way to fix this is to disable FDS. We should not need
yet another option to control debug info.
Dan
On 2/28/14 4:13 AM, David Holmes wrote:
Hi,
As I put in the bug report this seems way too complicated. Seems to me
all you need to do to get what you want is not use FDS and not
Thanks for review, John!
Best regards,
Vladimir Ivanov
On 2/28/14 12:39 AM, John Rose wrote:
On Feb 26, 2014, at 3:44 AM, Vladimir Ivanov
vladimir.x.iva...@oracle.com mailto:vladimir.x.iva...@oracle.com wrote:
Maybe use invokeWithArguments with target and catcher? That at least is
a
The proper way to fix this is to disable FDS.
Does this mean I have to pass --disable-debug-symbols to configure ?
I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols
to configure, gcc/g++ is not passed -g option. -g is needed to generate
debuginfo.
Thanks,
Yasumasa
On 2/28/2014 12:01 AM, Alan Bateman wrote:
On 28/02/2014 07:51, huizhe wang wrote:
Hi,
This is a fix to the license header for class
jdk/test/javax/xml/jaxp/transform/8004476/TestBase.java.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8036004
Webrev:
Am 28.02.2014 17:36, schrieb Peter Levart:
[...]
The other use of
getEnumConstantsShared() is to support the Enum.valueOf(Class, String)
method which already throws IllegalArgumentException if the 1st
parameter does not represent an enum class, so there's no compatibility
concerns about that
On 02/28/2014 04:56 PM, Jochen Theodorou wrote:
Hi,
we stumbled here about a strange error involving enums generated from
our compiler and that did make me see getEnumConstantsShared() in
java.lang.Class.
Now the implementation more or less says, that if calling values()
fails in any way,
On 2/27/14 12:11 PM, Joe Darcy wrote:
I am trying hard to remain blissfully ignorant of any more low-level details of
the serialization format; however, I might not be successful on that goal much
longer ;-)
I believe your latter statement is correct. :-)
My preference in a case like this is
Changeset: 183a8c520b4a
Author:rfield
Date: 2014-02-28 10:43 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/183a8c520b4a
8035777: Consistent Lambda construction
Reviewed-by: ahgross, briangoetz, dlsmith
!
On 2/28/14 9:27 AM, Stuart Marks wrote:
I guess there is some risk of adding new intermittent failures, but
tackling @ignore'd tests is important too.
Right - the main risk is that we will see this test fail again at some
point in the future. I'll be keeping an eye out for that.
Thanks
On Feb 25, 2014, at 3:13 AM, Ali Ebrahimi ali.ebrahimi1...@gmail.com wrote:
I know, this is too late, but I want to share my suggestion:
public T extends AccessibleObjectAnnotatedElement T reflectAs(Class?
super T expected, MethodHandles.Lookup lookup)
Isn't this the same as
public T
On Feb 28, 2014, at 1:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
But chances are, the day after I take it off, I will need it.
tryMonitorEnter() does no harm and it is out of reach of most programmers.
I think your analogy to a spare wheel is misleading. Continuing with the car
Please review a typo correction in java.time.format.Parsed.
The exception message is corrected.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-parsed-typo-8035106/
Thanks, Roger
Please review this bug fix from Steve Colebourne for java.time parsing of
fixed width adjacent values. The patch includes new tests.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-parse-adjacent-8032491/
Thanks, Roger
Looks Ok. Kind of surprised the tck tests have no assertion details in the
tests. Minor nit would have been nice to have even a minor comment for the new
method DateTimeFormatterBuilder though that seems to be the norm in some
scenarios for the smaller methods.
On Feb 28, 2014, at 4:48 PM,
Hi,
This is an update from Xerces for a fixed encoding map entry in file
EncodingMap.java. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8035469
Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035469/webrev/
(I don't have a openjdk username yet, so Joe Wang
Except that Lock has features that are not supported by intrinsic locks
(timed wait, interruptible wait.) So the Lock returned would not
conform to Lock's contract, and attempting to call these methods would
probably throw UOE.
On 2/27/2014 6:12 AM, Stephen Colebourne wrote:
On 26 February
Hi Lance,
I'll see if I can add some comments.
The style for tests in java.time is less focused on statements in the
spec due to
the way the API developed. Perhaps the tests should have been just
regular unit tests.
Thanks, Roger
On 2/28/2014 5:05 PM, Lance Andersen - Oracle wrote:
Looks
Looks good. I'll sponsor the change.
Thanks,
Joe
On 2/28/2014 2:16 PM, Lance Andersen - Oracle wrote:
Looks fine.
On Feb 28, 2014, at 5:11 PM, David Li wrote:
Hi,
This is an update from Xerces for a fixed encoding map entry in file
EncodingMap.java. For details, please refer to:
Please review this fix for a broken link in the javadoc.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-link-broken-8035813/
Thanks, Roger
On 03/01/2014 02:29 AM, Martin Buchholz wrote:
Are word-size reads in ByteBuffer actually intrinsified? I could find no
evidence for that. Perhaps this is an important missing optimization for
hotspot to make?
It is a missing optimization, and we will get to that:
On 02/28/2014 10:29 PM, Martin Buchholz wrote:
Are word-size reads in ByteBuffer actually intrinsified?
No.
Andrew.
On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote:
The proper way to fix this is to disable FDS.
Does this mean I have to pass --disable-debug-symbols to configure ?
I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols
to configure, gcc/g++ is not passed -g option. -g is
On 2/27/14 12:14 PM, Brian Burkhalter wrote:
On Feb 27, 2014, at 12:17 AM, Paul Sandoz wrote:
So may I obtain a +1 from a JDK 9 Reviewer now?
Indeed you may.
Thanks, Paul. I refreshed the webrev
http://cr.openjdk.java.net/~bpb/8035279/webrev.01/ with the agreed upon version.
Hi Brian,
Woops, I forgot a couple points.
The @serial for the 'signum' field at line 130 should be removed. Note that even
though this has the same name as the field that appears in the serialized form,
the text from the @serialField tag for 'signum' that's part of the
serialPersistentFields doc
Hi Stuart
On Feb 28, 2014, at 5:35 PM, Stuart Marks wrote:
This is pretty good. After this long, strange trip through the JMM, restoring
the sentinel values to zeroes and renaming the fields to be explicit about
how they represent the actual values seems to be the best approach. Paul's
On Feb 28, 2014, at 5:54 PM, Stuart Marks wrote:
Woops, I forgot a couple points.
The @serial for the 'signum' field at line 130 should be removed. Note that
even though this has the same name as the field that appears in the
serialized form, the text from the @serialField tag for
31 matches
Mail list logo
