I'm not sure I'm convincing anyone other than myself, but here's another
try:
recover means taking any action at all, the most common of which is ...
nothing!
Perhaps a product feature simply becomes grayed out when running a
process fails.
From a WORA developer's point of view, it is irrelevant
This fix looks fine.
--Sean
On 02/20/2015 01:54 PM, Mandy Chung wrote:
This fixes a regression due to JDK-8057645 moving JAXB to ext loader
that was tested before the fix for JDK-8054367 went in jdk9. This
was uncovered after JDK-8057645and JDK-8054367 met.
The fix is simple.
On 24/02/2015 00:58, Mandy Chung wrote:
In fact, find another redundant in jdk.httpserver. I have updated
the synopsis of JDK-8073696 to remove redundant imports in java.corba
and jdk.httpserver
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073696/webrev.00/
Mandy
Looks okay to me.
On 24 Feb 2015, at 00:58, Mandy Chung mandy.ch...@oracle.com wrote:
In fact, find another redundant in jdk.httpserver. I have updated the
synopsis of JDK-8073696 to remove redundant imports in java.corba and
jdk.httpserver
Le 24/02/15 09:09, Alan Bateman a écrit :
Right, it has never supported multiple iterators but as it's an
Iterable then it should unless specified otherwise. So I think this is
a bug (although one could argue that the usage is unusual, almost a
mis-use).
One use case is that in a
On Feb 23, 2015, at 10:08 PM, Peter Levart peter.lev...@gmail.com wrote:
- We have to be careful with loosening of volatile writes to final fields
in custom readObject() methods (BigDecimal.intCompact for example) especialy
if they are writes to fields that are not serial fields in
On 23 February 2015 at 22:27, Peter Levart peter.lev...@gmail.com wrote:
What about the following idea:
- create a (maybe still package-private) instance method
ZoneId.getSystemClock() and cache the per-ZoneId Clock instance inside the
ZoneId.
- Clock.system(ZoneId) static method is then
Thanks for the change. This reviewer is happy.
Stephen
On 24 February 2015 at 10:59, Daniel Fuchs daniel.fu...@oracle.com wrote:
On 23/02/15 21:40, Stephen Colebourne wrote:
The rest of the java.time code tends to put the data provider method
before the test, and mostly uses a naming
I've updated summary and description.
Lev
On 02/23/2015 04:55 AM, David Holmes wrote:
On 20/02/2015 7:57 PM, Lev Priima wrote:
Functional is pretty same, but:
- make it run with a single argument '67108864' by moving @summary tag
strait down to line after the @run tag
- '-Xmx385'
On 02/24/2015 10:32 AM, Martin Desruisseaux wrote:
Le 24/02/15 09:09, Alan Bateman a écrit :
Right, it has never supported multiple iterators but as it's an
Iterable then it should unless specified otherwise. So I think this is
a bug (although one could argue that the usage is unusual, almost
Looks good Daniel.
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 Feb 24, 2015, at 5:59 AM, Daniel Fuchs daniel.fu...@oracle.com wrote:
On 23/02/15 21:40,
Hi Chris,
On 02/24/2015 11:53 AM, Chris Hegarty wrote:
Peter,
On 23 Feb 2015, at 21:08, Peter Levart peter.lev...@gmail.com wrote:
Hi Chris,
On 02/23/2015 12:01 PM, Chris Hegarty wrote:
Peter, David, Vitaly,
Can you please take a look at the latest version of this change:
On 02/24/2015 11:16 AM, Daniel Fuchs wrote:
Hi Peter,
On 24/02/15 10:00, Stephen Colebourne wrote:
On 23 February 2015 at 22:27, Peter Levart peter.lev...@gmail.com
wrote:
What about the following idea:
- create a (maybe still package-private) instance method
ZoneId.getSystemClock() and
Hi,
Here is a fix for an issue with repeating annotations when a security manager
is set.
Fix is to use the Proxy invocation handler to unwrap the array containing the
repeating annotations. In theory it might be possible to have instances of
Annotations that are not implemented using
On 02/24/2015 02:47 PM, Paul Sandoz wrote:
On Feb 24, 2015, at 2:48 PM, Andrew Haley a...@redhat.com wrote:
With that in mind is there any need to intrinsify the new methods
at all given those new Java methods can defer to the older ones
based on a constant check? Also should that anyway be
On Feb 24, 2015, at 3:59 PM, Andrew Haley a...@redhat.com wrote:
If we expose the endianness query via a new method in unsafe we
should reuse that in java.nio.Bits and get rid of the associated
static code block.
Sure, I already did that.
Locally i guess? (just in case i missed
On 02/24/2015 03:40 PM, Peter Levart wrote:
On 02/24/2015 02:48 PM, Andrew Haley wrote:
private static final boolean IS_UNALIGNED = theUnsafe.unalignedAccess();
public void putIntUnaligned(Object o, long offset, int x) { if
(IS_UNALIGNED || (offset 3) == 0) { putInt(o, offset, x); } else if
On 24 Feb 2015, at 11:45, Peter Levart peter.lev...@gmail.com wrote:
...
- You are tracking the requiresFreeze flag in readSerialData() method for
each class slot the deserialized object is composed of. This can be
optimized and the 'hasFinalField' flag pre-computed for the whole object
On 02/24/2015 02:48 PM, Andrew Haley wrote:
private static final boolean IS_UNALIGNED = theUnsafe.unalignedAccess();
public void putIntUnaligned(Object o, long offset, int x) { if (IS_UNALIGNED ||
(offset 3) == 0) { putInt(o, offset, x); } else if (byteOrder == BIG_ENDIAN) {
putIntB(o,
Hi,
On 02/24/2015 11:16 AM, Paul Sandoz wrote:
This looks like a good start.
Good, thanks.
On Feb 23, 2015, at 7:13 PM, Andrew Haley a...@redhat.com wrote:
I've been kicking around a few ideas for Unsafe access methods for unaligned
access to byte arrays and buffers in order to provide
Hello Peter
Le 24/02/15 13:49, Peter Levart a écrit :
You could synchronize on the entire loop and just copy over the
service objects to another collection (say ArrayList).
Right, but I would like to keep the laziness instantiation behaviour.
If you really must combine laziness of
On Feb 24, 2015, at 2:48 PM, Andrew Haley a...@redhat.com wrote:
I am all for keeping more code in Java if we can. I don't know enough about
assembler-based optimizations to determine if it might be possible to do
better on certain CPU architectures.
Me either, but I have tested this on
Hi David,
comments inlined.
Hi Kumar,
On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
Hello,
Please review the fix for the above issue.
Webrev:
http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
The fix is self explanatory, as for the test I have done the following:
I found the
Hi!
A typo populated over a few places.
Fix: s/StackOverflowException/StackOverflowError/g
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073779
WEBREV: http://cr.openjdk.java.net/~igerasim/8073779/0/webrev/
Sincerely yours,
Ivan
Approved!
On Tue, Feb 24, 2015 at 8:44 AM, Ivan Gerasimov ivan.gerasi...@oracle.com
wrote:
Hi!
A typo populated over a few places.
Fix: s/StackOverflowException/StackOverflowError/g
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073779
WEBREV:
Thanks!
pushed.
On 24.02.2015 19:46, Martin Buchholz wrote:
Approved!
On Tue, Feb 24, 2015 at 8:44 AM, Ivan Gerasimov
ivan.gerasi...@oracle.com mailto:ivan.gerasi...@oracle.com wrote:
Hi!
A typo populated over a few places.
Fix: s/StackOverflowException/StackOverflowError/g
On 24/02/2015 17:08, Ivan Gerasimov wrote:
Right. I shouldn't have pushed it that quick. Sigh
Nothing important. Just thought it might be a useful step while you were
there! It's something we can keep in mind for a later fix.
regards,
Sean.
On 24.02.2015 19:53, Seán Coffey wrote:
Nice
Nice catch Ivan. You could also clean up the typo in various test cases
relating to it also perhaps :
langtools/test/tools/javac/generics/inference/8043725/T8043725.java
jdk/test/java/util/Hashtable/SelfRef.java
jdk/test/javax/swing/border/Test6461042.java
Right. I shouldn't have pushed it that quick. Sigh
On 24.02.2015 19:53, Seán Coffey wrote:
Nice catch Ivan. You could also clean up the typo in various test
cases relating to it also perhaps :
langtools/test/tools/javac/generics/inference/8043725/T8043725.java
Can you add 5.1 to your list ? :)
If we had AOT, small methods will be inlined and sharing their profile in that
case seems just wrong.
As you said it will also make tiered compilation smarter.
Rémi
Le 22 février 2015 01:58:02 CET, John Rose john.r.r...@oracle.com a écrit :
All of the
Kumar,
This looks good to me. I didn't review all the changes in the test very
carefully, so someone else should vouch for that.
Thank you for fixing this!
Coleen
On 2/23/15, 9:09 PM, David Holmes wrote:
Hi Kumar,
On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
Hello,
Please review the
On Feb 23, 2015, at 10:13 AM, Andrew Haley a...@redhat.com wrote:
I've been kicking around a few ideas for Unsafe access methods for
unaligned access to byte arrays and buffers in order to provide
whatever second-best mechanism the platform offers. These would
provide the base for fast
Thumbs up!
Thanks,
David
On 25/02/2015 2:17 AM, Kumar Srinivasan wrote:
Hi David,
comments inlined.
Hi Kumar,
On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
Hello,
Please review the fix for the above issue.
Webrev:
http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
The fix is self
On Feb 24, 2015, at 7:49 AM, Andrew Haley a...@redhat.com wrote:
There will be only one runtime Unsafe sub-type ever observed in a
particular VM.
Oh, that's very nice.
That doesn't help with B accesses on L platforms and vice versa.
Having an optional boolean parameter (gating
34 matches
Mail list logo
