Thanks Chris,
WRT circular references, is it possible to detect and delay setting these until
after all verifiers run?
An option might be to provide a protected method in ObjectInputStream to opt
out or switch off support for circular references.
Apart from Serialization, another common use fo
On 01/14/2015 10:50 AM, Peter Levart wrote:
Hi,
Loosely related to this topic, there is some local variable caching of
comparableClassFor() result already being performed inside iterative/recursive
methods of TreeNode, but this caching is just positive caching, meaning that
null return is not ca
On 15 Jan 2015, at 12:25, Peter Firmstone wrote:
> Chris,
>
> Can you explain some of the detail in your failure atomicity work?
Certainly.
The current implementation of defaultReadObject sets non-primitive field values
one at a time, without first checking that all their types are assignable
On 15 January 2015 at 13:01, Peter Firmstone
wrote:
> A third option that hasn't yet been considered would be to investigate an
> api that various already existing frameworks can implement providers for, so
> they no longer need to find creative ways to construct instances of java
> platform class
Hi Joe,
Nits,
152 * "void". If this {@code Class} object presents an array type,
153 * this method returns "class " followed by {@code getName}.
line 152, presents or represents?
Personally I would add a test for a 2-dim array of a generic type.
cheers
/Joel
> On 15 jan 2015, at 0
Looks good.
cheers
/Joel
> On 15 jan 2015, at 13:32, Claes Redestad wrote:
>
> Hi,
>
> please review this patch to use double-checked locking to avoid
> synchronization overhead on repeated access to the
> declaredAnnotations field in Executable and Field.
>
> webrev: http://cr.openjdk.java.n
On Jan 15, 2015, at 1:32 PM, Claes Redestad wrote:
> Hi,
>
> please review this patch to use double-checked locking to avoid
> synchronization overhead on repeated access to the
> declaredAnnotations field in Executable and Field.
>
> webrev: http://cr.openjdk.java.net/~redestad/8068736/webrev
On Jan 15, 2015, at 2:03 AM, joe darcy wrote:
> Hello,
>
> Please review these changes to address
>
>JDK-8060077 : Class.toGenericString specification doesn't mention array
> types
>http://cr.openjdk.java.net/~darcy/8060077.0/
>
+1.
Paul.
Thanks everybody for the feedback! :)
Claes, we were deliberately trying to avoid the "Apache commons" solution.
It looks perfectly fine outside of the JDK. But our wild guess was that as
we have access to the Throwable private methods, we can do something more
elegant. The fact is (and I shared i
On 13/01/2015 1:56 AM, Chris Hegarty wrote:
On 10/01/15 07:00, Peter Firmstone wrote:
As shown in my earlier example, intra class invariants can be enforced
using Serialization constructors, from which static methods are called
to check invariants prior to super class constructors being called.
Hi,
please review this patch to use double-checked locking to avoid
synchronization overhead on repeated access to the
declaredAnnotations field in Executable and Field.
webrev: http://cr.openjdk.java.net/~redestad/8068736/webrev.00
bug: https://bugs.openjdk.java.net/browse/JDK-8068736
Testing:
On 15/01/2015 6:34 AM, Ivan St. Ivanov wrote:
Hi Remi,
I tried it and, well, the JDK image now does not even compile classes that
contain lambda expressions:
javac -cp . ./LambdaMetaFactoryTester.java
Exception in thread "main"
Exception: java.lang.BootstrapMethodError thrown from the
UncaughtE
Hi,
anything directly used by the LambdaMetafactory itself would
of course be impossible to add lambdas to, and as Remi points
out, this makes lambdaified utilities unusable from that subsystem
unless there are ways around them, e.g., exposing a desugared
method along with the lambdaified API (wh
Chris,
Can you explain some of the detail in your failure atomicity work?
Thanks,
Peter.
On Jan 14, 2015, at 5:31 PM, Chris Hegarty wrote:
> On 14/01/15 16:18, Mandy Chung wrote:
>> On 1/14/2015 8:04 AM, Chris Hegarty wrote:
>>>
>>> http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/
>>
>> Looks okay to me.
>>
>> In CallerSensitiveFinder.java line 57, 80, 137 - not sure
Felix,
On 15 Jan 2015, at 07:15, FELIX YANG wrote:
> Chris,
> excuse me, I'm not a reviewer but have some questions.
All comments and questions are welcome.
> at line 209, classes is actually trying to resolve a path like
> "c:\jdk1.9.0\modules", which never exists in JDK director
16 matches
Mail list logo
