Hello,
I'm fine with version 1 as well.
Cheers,
-Joe
On 1/29/2015 1:07 PM, Roger Riggs wrote:
Hi Brian,
#1, The current webrev is fine as is. (Perhaps with a 2015 copyright
update).
Since the methods are abstract, the general description is sufficient and
the subclass would have more det
I don't think that usage would be inappropriate, but I don't think it is
called for here either.
Thanks,
-Joe
On 1/29/2015 1:01 PM, Brian Burkhalter wrote:
Would it be appropriate to put the parenthetic information in the new
lines 91-93 in an @implSpec or other such section?
Brian
On Jan
+1
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
> On Jan 29, 2015, at 7:02 PM, joe darcy wrote:
>
> Hello,
>
> Please review the patch below to fix
>
>JDK-80
Hello,
Please review the patch below to fix
JDK-8071959: java.lang.Object uses implicit default constructor
diff -r 458adf31ad5b src/java.base/share/classes/java/lang/Object.java
--- a/src/java.base/share/classes/java/lang/Object.javaThu Jan 29
15:14:44 2015 -0800
+++ b/src/java.base/s
Hi Brian,
#1, The current webrev is fine as is. (Perhaps with a 2015 copyright
update).
Since the methods are abstract, the general description is sufficient and
the subclass would have more detail if specified.
Roger
On 1/29/2015 3:53 PM, Brian Burkhalter wrote:
On Jan 19, 2015, at 12:32
Hi Joe,
Looks fine (though I don't have the books to verify the references).
Roger
On 1/29/2015 3:53 PM, joe darcy wrote:
Hello,
Please review a few doc updates for java.lang.Object:
JDK-8071434: doc updates for java.lang.Object
http://cr.openjdk.java.net/~darcy/8071434.0/
Patch be
Would it be appropriate to put the parenthetic information in the new lines
91-93 in an @implSpec or other such section?
Brian
On Jan 29, 2015, at 12:53 PM, joe darcy wrote:
> Please review a few doc updates for java.lang.Object:
>
> JDK-8071434: doc updates for java.lang.Object
>http
Hello,
Please review a few doc updates for java.lang.Object:
JDK-8071434: doc updates for java.lang.Object
http://cr.openjdk.java.net/~darcy/8071434.0/
Patch below.
Thanks,
-Joe
--- old/src/java.base/share/classes/java/lang/Object.java 2015-01-29
12:50:41.099429597 -0800
+++ new/sr
On Jan 19, 2015, at 12:32 AM, Andreas Lundblad
wrote:
>> http://cr.openjdk.java.net/~bpb/8067669/webrev.01/
>>
>> Note that the change at line 40 should be made even if the other diffs are
>> rejected.
>
> This patch is an improvement in my opinion since it does not indicate that
> any effo
Thanks, John!
Best regards,
Vladimir Ivanov
On 1/29/15 6:10 AM, John Rose wrote:
Good. Consider fixing the typo in 'makeBlockInlningWrapper'. — John
On Jan 28, 2015, at 9:12 AM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8071787/webrev.00/
https://bugs.openjdk.java.net/b
Thanks, John!
Best regards,
Vladimir Ivanov
On 1/29/15 6:11 AM, John Rose wrote:
Good.
On Jan 28, 2015, at 9:22 AM, Vladimir Ivanov
mailto:vladimir.x.iva...@oracle.com>> wrote:
The fix is to use adapted MethodHandle to construct LambdaForm.
Hi,
I ran my updated test through our automated testing system, and it
failed *on Windows only*. The toURI() call I added came back with an
AccessControlException due to not being able to read the "test.classes"
directory. The test uses its own security policy.
I added
permission java.i
On 29/01/2015 14:51, Aleksej Efimov wrote:
Hi,
Can I have a review for a bulk update of JAX-B/WS from upstream
projects -
webrev: http://cr.openjdk.java.net/~aefimov/8071585/webrev/
more details in JBS: https://bugs.openjdk.java.net/browse/JDK-8071585
There is a lot of changes (947 lines) but
Hi,
Can I have a review for a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~aefimov/8071585/webrev/
more details in JBS: https://bugs.openjdk.java.net/browse/JDK-8071585
There is a lot of changes (947 lines) but almost all of them are minor
(comments change
Hi Frank,
I see you decided to use documentation comments (/** vs /*) I would use '/*'
otherwise you need to at missing javadoc tags (param, exception) to quiet
IDEs and -Xdoclint
The update comments are OK
Best
Lance
On Jan 29, 2015, at 3:37 AM, Frank Yuan wrote:
> Hi Lance
>
> I have c
I decided to sample cpu load (see attached), with debugging enabled for
the validating ObjectInputStream and JERI, so heaps of output to the
console.
There are no performance optimisations with stream validation, I've just
focused on correctness and security.
Thank you HotSpot developers, ni
Hi Amy,
Thanks - appreciate you digging into the history!
Cheers,
Martijn
On 29 January 2015 at 11:51, Amy Lu wrote:
> Thank you Martijn for looking into this.
>
> The code will be reexamined and fixed later in
> JDK-8071911: Fix deprecation warnings in jdk.rmic module
>
> See more bac
Thank you Martijn for looking into this.
The code will be reexamined and fixed later in
JDK-8071911: Fix deprecation warnings in jdk.rmic module
See more background (which I should have given):
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html
Thanks,
Amy
On 1
Two examples:
1. of a child class with super class invariants and
2. Checking List and Map contents for type correctness.
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional
Hi Amy,
Idle curiosity here - are the warnings being suppressed because there is no
way of 'resolving' them?
Cheers,
Martijn
On 29 January 2015 at 03:09, Amy Lu wrote:
> I updated the webrev, suppress deprecation warnings for
> jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered.
For the sharper eyed, you'll have noticed the readObjectNoData() method
I forgot to check:
private static boolean check(GetArg arg) throws IOException{
// If this class is not in the heirarchy of classes the stream
// may have been tampered with, see the Serialization Specification
/
Another example of intra dependencies, turns out we have a lot of these
intra class dependencies in our project.
Cheers,
Peter.
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for a
Logging output from failed validation:
NonActGrp-out: Jan 29, 2015 7:36:16 PM
net.jini.jeri.BasicInvocationHandler invoke
NonActGrp-out: Jan 29, 2015 7:36:16 PM
net.jini.jeri.BasicInvocationHandler invoke
NonActGrp-out: FAILED: outbound call
net.jini.core.event.RemoteEventListener.notify remot
On 01/28/2015 06:35 PM, Martin Buchholz wrote:
It's hard for me to think of something we could add to the javadoc that
would actually help future users enough to offset the confusion of adding
subtleties of rarely encountered behavior. I also don't see an easy way to
improve the pool's reaction
Le 29/01/15 04:43, Mandy Chung a écrit :
> Throwing UOE is intentional so that applications depending on existing
> behavior will be modified not to use this deprecated method. Making
> it a no-op makes it harder to diagnose for applications depending on
> the finalizers to be invoked on exit to
On 01/29/2015 08:34 AM, David Holmes wrote:
Wouldn't it be possible to make the method safe?
Finalizers are usually run against un-reachable objects. If the Shutdown
sequence made sure all threads are stopped except the thread executing
How do you propose to make sure all threads are "stopped"
Just a quick note, to avoid stream corruption, object that aren't
instantiated are replaced by an enum marker, Reference.DISCARDED, and
null is returned in their place, fields are read and any trailling
writeObject data is discarded. Object that are not allowed to be
deserialized are still re
Although not directly relevant to this discussion, here are some
functional examples of deserialization constructors, I now have a fully
functional validating ObjectInputStream.
Unfortunately in our project we have intra object dependencies as
demonstrated by this example; a static validator,
28 matches
Mail list logo
