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 's
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
>
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 commen
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,
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. "
On 02/28/2014 10:29 PM, Martin Buchholz wrote:
> Are word-size reads in ByteBuffer actually intrinsified?
No.
Andrew.
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:
https://bugs.openjdk.jav
Please review this fix for a broken link in the javadoc.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-link-broken-8035813/
Thanks, Roger
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:
https://
+1
On Feb 28, 2014, at 5:25 PM, roger riggs wrote:
> Please review this fix for a broken link in the javadoc.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-link-broken-8035813/
>
> Thanks, Roger
>
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java En
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
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 2
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:
> https://bugs.openjdk.java.net/browse/JDK-8035469
>
> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/803
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 uploaded
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, r
looks fine. Took me a moment to figure out the change but makes sense :-)
On Feb 28, 2014, at 4:45 PM, roger riggs wrote:
> 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-80351
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
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
On Feb 28, 2014, at 1:38 AM, Paul Sandoz 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
> theme i liken
On Feb 25, 2014, at 3:13 AM, Ali Ebrahimi wrote:
> I know, this is too late, but I want to share my suggestion:
>
> public T reflectAs(Class super T> expected, MethodHandles.Lookup lookup)
Isn't this the same as
public T reflectAs...
?
I think we considered AccessibleObject but rejected i
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 for
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
! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory
On 2/26/14 11:34 AM, Brent Christian wrote:
File under "chipping away at test stabilization issues."
https://bugs.openjdk.java.net/browse/JDK-6835233
I would like to resolve this bug by removing the "@ignore" tag for JDK 9, and
bring the test back into rotation. If the failure comes back, I'll
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
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, r
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 use
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:
http://cr.openjdk.java.n
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, return null and ignore the exception. But why is t
> 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,
Yasumas
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
mailto:vladimir.x.iva...@oracle.com>> wrote:
Maybe use invokeWithArguments with target and catcher? That at least is
a one-liner, and probably more effic
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
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 sti
Looks good to me!
Thanks,
/Staffan
On 27 feb 2014, at 16:34, roger riggs 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
> desired.
>
>
On Feb 27, 2014, at 3:51 PM, Dr Heinz M. Kabutz
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:
> http://www.javaspecialists.eu/arc
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 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, ju
36 matches
Mail list logo
