About the rwarning field, if it's removed, would it break anything if
it's filled with the default value when deserializing the new version on
an older version? It seems okay for this case and you should verify.
Otherwise, looks okay.
Mandy
On 9/29/14 3:08 PM, Lance Andersen wrote:
Thank yo
Thank you Mandy
I made the change you suggested
http://cr.openjdk.java.net/~lancea/8059411/webrev.01/
and verified all is still good as expected with the tests.
Best
Lance
On Sep 29, 2014, at 5:48 PM, Mandy Chung wrote:
> On 9/29/14 2:21 PM, Lance Andersen wrote:
>> Hi all,
>>
>>
>> Need a
On Sep 29, 2014, at 5:51 PM, Claes Redestad wrote:
> Hi,
>
> the rwarning field seems to be unused after these changes, remove?
It is but given the class is Serializable, it should stay
>
> Also a System.out.println in test09 which seems excessively verbose.
I removed it.
http://cr.openjdk
Hi,
the rwarning field seems to be unused after these changes, remove?
Also a System.out.println in test09 which seems excessively verbose.
Otherwise it looks good.
/Claes
On 2014-09-29 23:21, Lance Andersen wrote:
Hi all,
Need a reviewer for 8059411 which is a simple fix & test for the fa
On 9/29/14 2:21 PM, Lance Andersen wrote:
Hi all,
Need a reviewer for 8059411 which is a simple fix & test for the fact
RowSetWarning does not properly chain warnings.With the fix, the JCK still
passes.
The webrev can be found at http://cr.openjdk.java.net/~lancea/8059411/webrev.00/
Lo
Hi all,
Need a reviewer for 8059411 which is a simple fix & test for the fact
RowSetWarning does not properly chain warnings.With the fix, the JCK still
passes.
The webrev can be found at http://cr.openjdk.java.net/~lancea/8059411/webrev.00/
Best,
Lance
Lance Andersen| Principal Member
Bytecode isn't that interesting when discussing peak performance of jit'd
code. Do you have assembly dumps?
The only noteworthy aspect of the bytecode is that the enhanced for loop
version is slightly bigger, and combined with other code in some method,
may inhibit inlining.
Speaking of which,
Bytecode output courtesy of Mikael Ståldal:
With standard loop:
private static boolean contains(org.apache.logging.log4j.Marker,
org.apache.logging.log4j.Marker...);
Code:
0: iconst_0
1: istore_2
2: aload_1
3: arraylength
4: istore_3
5: iload_2
On 09/29/2014 05:31 PM, Vitaly Davidovich wrote:
> I think Paul's email already has jmh output.
Oh duh, sorry Paul.
Andrew.
I think Paul's email already has jmh output.
I looked at the generated asm on 7u60 x64 linux, and didn't see any
material difference.
Paul, have you or anyone else looked at the machine code diffs between the
two? Looking at timing is useful, but it's possible to get caught up in
noise; the gener
On 09/29/2014 03:29 PM, Paul Benedict wrote:
> Open JDKers, I am forwarding an email to get some clarification. It's been
> a common understanding that foreach should perform no differently than the
> equivalent for-loop . However, some fellow developers claim there is a
> noticable difference in t
Open JDKers, I am forwarding an email to get some clarification. It's been
a common understanding that foreach should perform no differently than the
equivalent for-loop . However, some fellow developers claim there is a
noticable difference in their microbenchmarking. Can you help explain what
is
On 29/09/14 15:12, Alan Bateman wrote:
On 29/09/2014 13:53, Daniel Fuchs wrote:
- 233 FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE);
- 234 FileChannel.open(Paths.get(file + ".1.lck"), CREATE_NEW, WRITE);
+ 233 FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE)
On 29/09/2014 13:53, Daniel Fuchs wrote:
Do you mean that calling delete() will not close the file?
That's right.
:
- 233 FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE);
- 234 FileChannel.open(Paths.get(file + ".1.lck"), CREATE_NEW, WRITE);
+ 233 FileChannel.open(Paths.
On 29/09/14 13:42, Alan Bateman wrote:
On 29/09/2014 09:51, Daniel Fuchs wrote:
The files created by the test (both log files and lock files) will be
removed by the finally block at lines 150 - 174 - so the test shouldn't
leave any files open (which I verified by running the test on a JDK that
On 29/09/2014 09:51, Daniel Fuchs wrote:
The files created by the test (both log files and lock files) will be
removed by the finally block at lines 150 - 174 - so the test shouldn't
leave any files open (which I verified by running the test on a JDK that
does not have the fix).
It's the lock fi
Hi,
On 09/22/2014 01:25 PM, Richard Warburton wrote:
Hi all,
A long-standing issue with Strings in Java is the ease and performance of
creating a String from a ByteBuffer. People who are using nio to bring in
data off the network will be receiving that data in the form of bytebuffers
and conver
On 29/09/14 05:01, Alan Bateman wrote:
On 26/09/2014 19:33, Daniel Fuchs wrote:
Hi,
Please find below a patch for [1]
8059269: FileHandler may throw NPE if pattern is a simple name and
the lock file already exists
[1] https://bugs.openjdk.java.net/browse/JDK-8059269
The webrev is he
18 matches
Mail list logo
