Thanks Amy,
The updates look good to me. Just to confirm, have you verified that the
tests actually pass now?
-Chris.
On 05/11/2013 09:26, Amy Lu wrote:
Following bugs have been fixed, related tests should be removed from
ProblemList:
8021230 (CODETOOLS-7900208
On 05/11/2013 03:20, Mandy Chung wrote:
David,
Rereading your comment and I think you misread the switch statement (see
my comments below). In any case, I revisited ThreadStateController.java
and looked int the potential races and have done further cleanup. Here
is the updated webrev.
On 05/11/2013 10:59, Paul Sandoz wrote:
On Nov 5, 2013, at 8:26 AM, Peter Levartpeter.lev...@gmail.com wrote:
P.S. I'm curious about the strange seemingly unneeded code fragments in
FinalizerThread and both Runnables. For example:
169 forkSecondaryFinalizer(new Runnable() {
Thanks Amy,
I can sponsor this change for you.
-Chris.
On 05/11/2013 11:09, Amy Lu wrote:
On 11/5/13 6:01 PM, Alan Bateman wrote:
On 05/11/2013 09:26, Amy Lu wrote:
:
Please review ProblemList.txt changes:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html
Changeset: f37d62e295c0
Author:chegar
Date: 2013-11-07 08:04 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f37d62e295c0
8027822: ProblemList.txt Updates (11/2013)
Reviewed-by: chegar, alanb
Contributed-by: Amy Lu amy...@oracle.com
! test/ProblemList.txt
Sorry for the delay Amy.
Trivially, 'windows-amd64, solaris-amd64, linux-amd64, macosx-all' was
not matching the 64bit versions of these OSes, neither was s/amd64/x64/.
So I changed it to generic-all for now. I did run into this myself a
while back, but can't remember the correct labels. Not
Changeset: 82b276590b85
Author:chegar
Date: 2013-11-07 08:23 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82b276590b85
8027961: Inet[4|6]Address native initializing code should check field/MethodID
values
Reviewed-by: michaelm, rriggs
!
Virus checkers and, on more modern Windows OSes, Windows Experience
Service, and other external processes, have been causing trouble when it
comes to tests deleting files.
On a number of occasions in the past retry logic has been added to tests
that need to delete files. Also, the jtreg
the difference between these
methods and regular delete. So maybe move to public deleteWithRetry?
-Chris.
Michael
On 07/11/13 10:05, Chris Hegarty wrote:
Virus checkers and, on more modern Windows OSes, Windows Experience
Service, and other external processes, have been causing trouble when
SimpleFileVisitor, rather than FileVisitor
Thanks,
-Chris.
On 11/07/2013 01:24 PM, Alan Bateman wrote:
On 07/11/2013 11:34, Chris Hegarty wrote:
:
I've also received another comment offline about the method names.
They should be more descriptive, and highlight the difference between
these methods and regular
Looks fine to me Roger.
-Chris
On 7 Nov 2013, at 22:29, roger riggs roger.ri...@oracle.com wrote:
Please review this straightforward typo correction:
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-doc-readlong-8024458/
Thanks, Roger
Looks good to me. It should have been this way from day one.
-Chris.
On 08/11/2013 03:02, Stuart Marks wrote:
Hi all,
Please review this quick one-liner to change the serialver tool so that
it emits a serialVersionUID declaration with the 'private' modifier,
which comports with the
/
Thanks,
-Chris.
On 08/11/2013 02:26, Dan Xu wrote:
On 11/07/2013 11:04 AM, Alan Bateman wrote:
On 07/11/2013 14:59, Chris Hegarty wrote:
Given both Michael and Alan's comments. I've update the webrev:
http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/
1) more descriptive method names
2
Changeset: 3112729d6b74
Author:tyan
Date: 2013-11-08 15:12 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3112729d6b74
8022963: java/net/NetworkInterface/Equals.java fails equality for Windows
Teredo Interface
Reviewed-by: chegar
!
Changeset: 771c77b49bb6
Author:chegar
Date: 2013-11-08 15:15 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/771c77b49bb6
8019834: InetAddress.getByName hangs for bad IPv6 literals
Reviewed-by: alanb
! src/share/classes/java/net/InetAddress.java
!
Changeset: 46982ca895b4
Author:tyan
Date: 2013-11-08 18:54 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46982ca895b4
8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on
slow/single core machine
Reviewed-by: chegar
!
Recent changes to jdk/test/Makefile, in TL, causes all test batches to
fail on Windows. I would like to propose a temporary measure to get the
tests running again. This will give us the time to come up with a better
longer term solution.
From what I can tell cygpath, with '-s', fails when the
Changeset: b48eded97dff
Author:chegar
Date: 2013-11-11 10:33 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b48eded97dff
8028102: All test targets, jdk/test/Makefile, fail on Windows
Reviewed-by: mduigou
! test/Makefile
Looks ok to me Joe.
-Chris.
On 12/11/13 09:28, Joe Darcy wrote:
Hello,
Please review the patch below which would remove another batch of raw
type javac lint warnings from the core libraries.
No signatures of public or protected methods in the Java SE
specification have been modified.
The changes look fine to me.
Since Martin has already brought the changes into the JSR166 CVS, Joe
you can go ahead and push these changes to jdk8.
Thanks,
-Chris.
On 11/12/2013 10:52 PM, Joe Darcy wrote:
Hello concurrency maestros,
I submit for your consideration a simple patch to silence
Changeset: 70f1bed5e7fd
Author:chegar
Date: 2013-11-13 16:44 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70f1bed5e7fd
8022213: Intermittent test failures in java/net/URLClassLoader
Reviewed-by: dxu, alanb
! test/java/net/URLClassLoader/closetest/CloseTest.java
!
Looks good to me Sean, thanks for adding deleteFileIfExistsWithRetry.
Trivially, you can replace oneLoopRun with a do {} while loop.
-Chris.
On 11/19/2013 01:31 PM, Seán Coffey wrote:
Looking to add two helper methods to the OpenJDK test libraries. I'm
looking to clean up a closed src test
Look ok to me Balchandra. I can sponsor this for you.
-Chris.
On 11/19/2013 02:07 PM, Balchandra Vaidya wrote:
Hi,
Here is one possible solution for the issue JDK-8028094.
http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/
I am not sure pkill is available in all Unix flavor at /usr/bin
Looks good to me Alan. It will be nice to see why this test is actually
failing.
-Chris.
On 11/19/2013 02:43 PM, Alan Bateman wrote:
The test tools/jar/JarEntryTime.java has been failing intermittently
(but very rarely) for some time. The failure seems to be that the
extracted time it out by
The change looks ok to me. If for no reason other than to eliminate the
timeout if this tests fails again in the future.
-Chris.
On 11/19/2013 02:28 PM, Rob McKenna wrote:
Hi folks,
Looking for a quick review for a test failure we're encountering.
Seemingly no bar is too high for our test
Changeset: cfbee8ee71bf
Author:bvaidya
Date: 2013-11-19 15:31 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfbee8ee71bf
8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves sleep
processes behind
Reviewed-by: chegar
!
Looks ok to me.
-Chris.
On 11/19/2013 03:58 PM, Seán Coffey wrote:
Hope this is a simple one. This issue is a rare intermittent one :
- port 48250 is free
- exported registry: RegistryImpl[UnicastServerRef [liveRef:
[endpoint:[10.169.79.100:48250](local),objID:[0:0:0, 0
- port 48250 is in
On 20/11/13 05:00, Mandy Chung wrote:
Thanks for the details Dan [1]. It is useful. The reason why I was
wondering the difference with temp dir is that the test workdir might be
excluded from the anti-virus scanner on that test machine. Now you have
explained it.
Right, this would be my
Changeset: 2972241cf7eb
Author:tyan
Date: 2013-11-21 13:37 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2972241cf7eb
703: test/com/sun/net/httpserver/Test9a.java fails intermittently
Summary: Additional stacktrace information is printed on failure
Reviewed-by: alanb,
Look good to me Paul.
-Chris
On 22/11/13 11:24, Paul Sandoz wrote:
Hi,
https://bugs.openjdk.java.net/browse/JDK-8028516
An attendee of the Devoxx lambda hackathon spotted some doc bugs in code
samples of the stream peek methods.
I updated those samples to be stand alone samples and
Tristan,
The removal of this test from the ProblemList.txt looks like the right thing to
do. I can push this for you.
-Chris.
On 26 Nov 2013, at 12:47, Tristan Yan wrote:
Hi Alan
Could you sponsor this small change for me if you're ok with this change.
Thank you very much.
Tristan
On
Looks good to me Paul.
-Chris.
On 27/11/13 11:02, Paul Sandoz wrote:
Hi,
https://bugs.openjdk.java.net/browse/JDK-8029164
http://cr.openjdk.java.net/~psandoz/tl/JDK-8029164-thenCompose-async/webrev/
This fixes an issue with CompletableFuture.thenCompose.
If the composing future is already
Changeset: 5bcaf730ceb8
Author:tyan
Date: 2013-11-29 09:29 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bcaf730ceb8
8029348: ProblemList.txt updates (11/2013)
Reviewed-by: chegar
! test/ProblemList.txt
:
Thank you. Chris.
Tristan
On 11/26/2013 11:16 PM, Chris Hegarty wrote:
Tristan,
The removal of this test from the ProblemList.txt looks like the right thing
to do. I can push this for you.
-Chris.
On 26 Nov 2013, at 12:47, Tristan Yan wrote:
Hi Alan
Could you sponsor
Looks good to me Mark.
-Chris.
On 02/12/13 12:35, Mark Sheppard wrote:
Hi
based on feedback the changes for issue:
https://bugs.openjdk.java.net/browse/JDK-8025211
have been amended to the following:
http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/
please oblige and review
Looks fine to me Joe.
-Chris.
On 3 Dec 2013, at 17:49, Joe Darcy wrote:
Hello,
Please review the patch before which addresses a handful of doclint issues in
javax.script.
Thanks,
-Joe
diff -r c11553506228 src/share/classes/javax/script/ScriptEngineFactory.java
---
On 04/12/13 10:31, Paul Sandoz wrote:
I have reviewed Doug's code, just need someone to quickly review the test code.
The tests look pretty comprehensive to me. I see no issues with them.
-Chris.
Paul.
On Dec 2, 2013, at 5:29 PM, Paul Sandoz paul.san...@oracle.com wrote:
Hi,
A trivial one on our JDK8 list. Doug has already accepted this into the
166 CVS.
Stuart brought this up a while back, and given our short deadline to get
doc changes into jdk8. I'll just go ahead with the review now on his
behalf. I have already review this.
The @FunctionalInterface
On 26 Nov 2013, at 18:08, Iris Clark wrote:
So overall it looks good to me and should be pushed to the staging forest
once you hear from others that commented previously.
I think that means Chris Hegarty, Michael McMahon, and Sergey Bylokhov.
Alan, please correct me if I'm wrong.
I'm
Changeset: 2a6611ebfb6c
Author:smarks
Date: 2013-12-04 18:02 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a6611ebfb6c
8029141: Add @FunctionalInterface annotation to Callable interface
Reviewed-by: chegar, alanb
! src/share/classes/java/util/concurrent/Callable.java
On 5 Dec 2013, at 14:40, roger riggs roger.ri...@oracle.com wrote:
Hi Rob,
Looks fine. (Not a Reviewer).
+1. Looks ok to me too.
-Chris.
Thanks for doing the legwork, Roger
On 12/5/2013 9:19 AM, Rob McKenna wrote:
This failure cropped up again and Roger Riggs spotted that I was
On 5 Dec 2013, at 19:18, Martin Buchholz marti...@google.com wrote:
You guys are way too trigger-happy.
I guess the reason for this is that there was a deadline today to get changes
into tl before the b120 snapshot. This is one of the final chances to get
non-showstopper changes into JDK
On 06/12/13 08:38, Paul Sandoz wrote:
On Dec 5, 2013, at 9:29 PM, Doug Lea d...@cs.oswego.edu wrote:
On 12/05/2013 03:18 PM, Brent Christian wrote:
I'm curious about why this was done:
*** 4452,4462
public final boolean removeAll(Collection? c) {
!
On 10 Dec 2013, at 09:10, Alan Bateman alan.bate...@oracle.com wrote:
On 08/12/2013 17:29, Dan Xu wrote:
Hi All,
Please review the fix towards the intermittent test failure in
java/util/zip/ZipFile. It is a similar failure that I encountered before,
due to the interferences from other
Roger,
The source changes look good to me, and in line with the Serialization proxy
idiom (ignoring the Externalizable stuff).
-Chris.
On 16 Dec 2013, at 17:02, roger riggs roger.ri...@oracle.com wrote:
Please review these changes to java.time serialization.
The format of the serialized
On 18 Dec 2013, at 14:35, roger riggs roger.ri...@oracle.com wrote:
Thanks Alan,
I corrected the webrev to link both locations that refer to ProxySelector.
http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/
Looks good. Thanks Roger.
-Chris.
Roger
On 12/18/2013 6:23
Looks good to me Joe.
This change, to me at least, demonstrates the power of the ProblemList.txt. It
is a really useful mechanism.
-Chris.
On 19 Dec 2013, at 07:59, Joe Darcy joe.da...@oracle.com wrote:
Hello,
Already out for review on the build-dev list is a change to increment
Changeset: e2bdddb8bedf
Author:dl
Date: 2013-12-19 10:31 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2bdddb8bedf
8026155: Enhance ForkJoin pool
Reviewed-by: chegar, alanb, ahgross
! src/share/classes/java/util/concurrent/ForkJoinPool.java
!
I looked over the patch files, and they look good to me.
Limiting each webrev to a single language feature makes reviewing quite
straight forward.
-Chris.
On 19 Dec 2013, at 14:51, Paul Sandoz paul.san...@oracle.com wrote:
Hi,
Here are some patches that migrate some code to use more up to
On 20 Dec 2013, at 04:33, Mandy Chung mandy.ch...@oracle.com wrote:
Hi Srikalyan,
Maybe you can get add an uncaught handler to see if you can get
any information.
+1. With this, at least the next time we see this failure we should have a
better idea where the OOM is coming from.
Hi Doug,
I agree with your changes to AbstractMap. I’ve taken your patch, removed the
superfluous paragraph tags, and generated a webrev.
http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/
I also ran specdiff to see what else may be impacted by this. It shows that the
only
and risk.
-Chris.
On Thu, Jan 2, 2014 at 8:03 AM, Chris Hegarty chris.hega...@oracle.com
wrote:
Hi Doug,
I agree with your changes to AbstractMap. I’ve taken your patch, removed the
superfluous paragraph tags, and generated a webrev.
http://cr.openjdk.java.net/~chegar
/browse/JDK-8031142
-Chris.
On Thu, Jan 2, 2014 at 3:48 PM, Chris Hegarty chris.hega...@oracle.com
wrote:
On 2 Jan 2014, at 22:02, Martin Buchholz marti...@google.com wrote:
As the subject says, these changes should be applied to all of the so-called
skeletal implementations in java.util
Changeset: 18080cca998a
Author:dl
Date: 2014-01-03 06:22 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18080cca998a
8031133: AbstractMap should specify its default implementation using @implSpec
Reviewed-by: chegar, alanb
! src/share/classes/java/util/AbstractMap.java
On 6 Jan 2014, at 17:25, Martin Buchholz marti...@google.com wrote:
On Mon, Jan 6, 2014 at 9:19 AM, Mike Duigou mike.dui...@oracle.com wrote:
If you navigate through
http://cr.openjdk.java.net/~chegar/8031142/specdiff/java/util/package-summary.html
it shows just the relevant diffs. It
On 6 Jan 2014, at 17:05, Martin Buchholz marti...@google.com wrote:
On Mon, Jan 6, 2014 at 8:47 AM, Chris Hegarty chris.hega...@oracle.com
wrote:
Part 2...
JDK 9 RFR - 8031142: AbstractCollection and AbstractList should specify their
default implementation using @implSpec
http
in late but this looks like a very good change to me as well.
Mike
On Jan 2 2014, at 23:06 , Chris Hegarty chris.hega...@oracle.com wrote:
On 3 Jan 2014, at 02:14, Martin Buchholz marti...@google.com wrote:
OK, as you wish - this change is clear progress!
Thanks Martin.
I pushed the AbstractMap
The test sets a security manager to ensure that appropriate permission
checks are performed. It expects to be denied reflective access to a
private field in a different package. Access, to this field, is granted
if the code has RuntimePermission accessDeclaredMembers. This
permission is not
On 6 Jan 2014, at 18:11, Chris Hegarty chris.hega...@oracle.com wrote:
On 6 Jan 2014, at 17:05, Martin Buchholz marti...@google.com wrote:
……..
In a sane language, the AbstractFoo classes would be traits - they should
never contribute to the *specification* of a concrete class, only
On 15 Dec 2013, at 10:29, Robert Stupp sn...@gmx.de wrote:
Hi,
I digged through the object serialization code and found some lines that
could be optimized to reduce the number of calls to System.arraycopy() and
temporary object allocations especially during string (de)serialization.
In
On 6 Jan 2014, at 22:29, Dan Xu dan...@oracle.com wrote:
Hi All,
Please review the simple fix for JNI pending exceptions in
FileSystemPreferences.c. Thanks!
Bug: https://bugs.openjdk.java.net/browse/JDK-8028726
Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/
Looks good to me
On 6 Jan 2014, at 21:19, Martin Buchholz marti...@google.com wrote:
Your change looks good, except there's one more trailing p to remove.
Thanks for the review. I found the trailing p and removed it.
-Chris.
On 8 Jan 2014, at 20:04, Mandy Chung mandy.ch...@oracle.com wrote:
On 1/8/2014 11:30 AM, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.01/
The fix looks fine. The WeakReference and System.gc() call was to help
reproduce the test failure. I
Looks ok to me.
I presume getThreadStateValues is simply no longer needed.
-Chris.
On 10 Jan 2014, at 06:31, Dan Xu dan...@oracle.com wrote:
Hi All,
Please review the fix for JNI pending exception issues reported in
jdk-8029007. Thanks!
Webrev:
Looks fine to me. I don't think AtomicLong was ever needed here.
-Chris.
On 10/01/14 10:01, Paul Sandoz wrote:
Hi,
A small tweak is required to a recent Stream-based test i added to stop some
internal lambda-based ser/derialization (SAND) tests barfing since the test is
hostile to
Thank you Roger, much appreciated.
I think Dan has a change in flight that could be simplified a bit by
using these.
-Chris.
On 10/01/14 15:37, roger riggs wrote:
Please review:
To enable native code checking consistently for thrown exceptions,
the macros in net_util.h and
Looks good to me Daniel.
-Chris.
On 10 Jan 2014, at 17:47, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi,
Please find below a trivial fix for
8031525: Logger created in test/tools/jar/UpdateManifest.java might
get gc'ed too early.
On 10 Jan 2014, at 18:05, Dan Xu dan...@oracle.com wrote:
Hi Roger,
My macro is a little different from yours, which compares with -1 instead of
NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are
useful when I cannot decide the pending exception state by just using
Looks ok to me Kumar.
-Chris.
On 11 Jan 2014, at 00:55, Kumar Srinivasan kumar.x.sriniva...@oracle.com
wrote:
Hi,
Please review fixes for launcher correctness wrt. JNI calls.
http://cr.openjdk.java.net/~ksrini/8031494/webrev.0/
Thanks
Kumar
)-GetStaticFieldID will throw a same exception if the
field cannot be found.
Here is the new webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.01/.
Thanks!
Looks good to me Dan.
-Chris.
-Dan
On 01/10/2014 10:21 AM, Mike Duigou wrote:
On Jan 10 2014, at 10:09 , Chris Hegarty
Since Martin has removed completely the '@compile -source 1.5 XXX’ lines from
the 166 CVS, you can amend your patch to do the same, or we can file a separate
bug to bring in these change. Whatever suits you, just let me know.
-Chris.
On 14 Jan 2014, at 02:30, Martin Buchholz
A recent change, JDK-8029007 introduced JNU_ThrowOutOfMemoryError into
MessageUtils. The Windows x86 build subsequently fails as follows:
Warning (shows the root cause):
c:/jprt/T/P1/113753.chhegar/s/jdk/src/share/native/sun/misc/MessageUtils.c(58)
: warning C4013: 'JNU_ThrowOutOfMemoryError'
On 14 Jan 2014, at 14:03, Alan Bateman alan.bate...@oracle.com wrote:
On 14/01/2014 13:56, Chris Hegarty wrote:
A recent change, JDK-8029007 introduced JNU_ThrowOutOfMemoryError into
MessageUtils. The Windows x86 build subsequently fails as follows:
Warning (shows the root cause):
c:/jprt
a bug and bring in these changes.
-Chris.
Thanks,
-Joe
On 01/14/2014 03:27 AM, Chris Hegarty wrote:
Since Martin has removed completely the '@compile -source 1.5 XXX’ lines
from the 166 CVS, you can amend your patch to do the same, or we can file a
separate bug to bring
It is good to clarify that the streams are closed.
I find the following updated wording a little odd, If a mapped stream
is {@code null} then it treated as if it was an empty stream. I thought
the previous wording was better, but that could be just me.
-Chris.
On 20/01/14 10:38, Paul Sandoz
On 20 Jan 2014, at 15:18, Paul Sandoz paul.san...@oracle.com wrote:
On Jan 20, 2014, at 3:18 PM, Chris Hegarty chris.hega...@oracle.com wrote:
It is good to clarify that the streams are closed.
I find the following updated wording a little odd, If a mapped stream is
{@code null
On 22/01/14 13:57, Florian Weimer wrote:
On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote:
Posted: http://openjdk.java.net/jeps/187
There's another aspect of the current approach to serialization that is
not mentioned: the type information does not come from the calling
context, but
On 23 Jan 2014, at 08:53, Martin Grebac martin.gre...@oracle.com wrote:
Hi Miran, did you get any response on this yet?
MartiNG
On 17/01/14 10:57, Miroslav Kos wrote:
Hi Steve and Alan,
I just reminding this issue - I have no response from anybody yet and it
would really simplify our
On 22 Jan 2014, at 15:14, Florian Weimer fwei...@redhat.com wrote:
On 01/22/2014 03:47 PM, Chris Hegarty wrote:
On 22/01/14 13:57, Florian Weimer wrote:
On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote:
Posted: http://openjdk.java.net/jeps/187
There's another aspect of the current
Hi David,
This is a nice summary of how object deserialization is working today, and some
interesting ideas around serialisation-aware constructors.
It seems there is just too much magic in the construction of deserialized
objects. All the field values required to fully construct the object
be in the past) would be imported
correctly:
copyrights-2012-v02.patch: -d 2012-12-30
copyrights-2013-v02.patch: -d 2013-12-30
Thanks
Miran
On 23/01/14 10:07, Chris Hegarty wrote:
On 23 Jan 2014, at 08:53, Martin Grebac martin.gre...@oracle.com wrote:
Hi Miran, did you get any response on this yet
The change looks good to me Alan.
-Chris.
On 24/01/14 11:00, Alan Bateman wrote:
I need a reviewer to fix an issue with the changes in JDK 8 to support
statically linked JNI libraries. The issue arises with tests that have
both JNI_OnLoad and JNI_OnLoad_libname functions defined, and code
Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the
case where the fromIndex is greater that the toIndex.
http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/
-Chris.
choices, like sharing
test infrastructure with Guava e.g. ListTestSuiteBuilder. More generally,
openjdk core libraries can benefit from all the great testing work that guava
folk have done.
On Fri, Jan 31, 2014 at 8:23 AM, Chris Hegarty chris.hega...@oracle.com
wrote:
Trivial change
trancate - truncate . Other cleanups look good too.
-Chris.
On 31 Jan 2014, at 18:33, roger riggs roger.ri...@oracle.com wrote:
Please review a typo and javadoc cleanup for java.util.Date
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/
Thanks, Roger
Forwarding to correct core-libs-dev list.
-Chris.
On 31 Jan 2014, at 14:22, Chris Hegarty chris.hega...@oracle.com wrote:
Hi Robert,
I think your patch can be split into two logical, independent, parts. The
first is the use of unsafe to access the String UTF length. The seconds
: Freitag, 31. Januar 2014 um 15:22 Uhr
Von: Chris Hegarty chris.hega...@oracle.com
An: Robert Stupp sn...@gmx.de, core-libs-dev-request
core-libs-dev-requ...@openjdk.java.net
Betreff: Re: Aw: Re: ObjectIn/OutputStream improvements
Hi Robert,
I think your patch can be split into two logical
On 31 Jan 2014, at 19:07, Stuart Marks stuart.ma...@oracle.com wrote:
On 1/31/14 10:46 AM, Chris Hegarty wrote:
I think your patch can be split into two logical, independent, parts. The
first is the use of unsafe to access the String UTF length. The seconds is
to reuse, where possible
Looks good to me. Thanks Roger.
-Chris.
On 01/02/14 18:58, Lance @ Oracle wrote:
Looks fine
Which releases are you think of including this in if any besides 9?
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Hi,
An old issue has resurfaced because of a change in AWT. AWT, now, on Mac
OS X, attaches a system graphics thread to the running VM, using
JNI_AttachCurrentThread. This change can result in a NPE, if a security
manager is installed, and the security manager tries to print the name
of the
Looks good Roger.
-Chris.
On 3 Feb 2014, at 20:17, roger riggs roger.ri...@oracle.com wrote:
Please re-review.
I missed a warning that the CHECK_NULL macros was being redefined.
Retaining the previous changes to java/util/jar/pack that removed the
redefinition
addresses the issue.
Nice work. Looks good to me.
-Chris.
On 02/04/2014 10:35 AM, Alan Bateman wrote:
There are a number of places in the native methods where there are
sequences of JNI calls and where we don't check for errors or pending
exceptions. This patch fixes up a number of these issues in the
java.lang
Looks good to me. Thanks Sean.
-Chris.
On 02/04/2014 01:31 PM, Seán Coffey wrote:
Looking to correct some JNI handling code in java/util/zip for jdk9-dev.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8029020/webrev/
http://cr.openjdk.java.net/%7Ecoffeys/webrev.8029020/webrev/
regards,
Looks good to me Roger.
-Chris.
On 02/04/2014 02:33 PM, roger riggs wrote:
Please review these cleanups to check for JNI pending exceptions in
jni_util.c.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/
Thanks, Roger
Thanks stuart, Mike, and Paul.
- Why not have getClassSignature() return an interned string? (that's if
interning is actually essential. Are we sure it's not just overhead?)
I didn’t want to change the existing use of interning here, just refactor the
code a little to make it cleaner.
I
Thanks Peter, this is a nice improvement. I’ll incorporate your changes before
pushing.
-Chris.
On 5 Feb 2014, at 16:39, Peter Levart peter.lev...@gmail.com wrote:
On 02/05/2014 04:11 PM, Chris Hegarty wrote:
Thanks stuart, Mike, and Paul.
- Why not have getClassSignature() return
On 07/02/14 15:24, Dmitry Samersoff wrote:
Staffan,
FileInputStream.java
55: It's better to initialize path with null.
I'm afraid I disagree with this. The default value is already null, why
set it to null again? I see this pattern all over the code, but it seems
completely redundant to
David,
... undefined in cases where the ObjectInputStream cannot resolve the
class which defined the writeObject method in question.
I'm not clear as to what this statement is about?
I'm sure you already know this, and maybe in your environment do not
care much about it, but having a
Looks good to me Joe.
-Chris.
On 4 Feb 2014, at 06:09, Joe Darcy joe.da...@oracle.com wrote:
Hello,
Please review this small fix to address
JDK-803352: Fix raw type lint warning in sun.nio.ch
--- a/src/share/classes/sun/nio/ch/Reflect.javaMon Feb 03 16:58:02 2014
-0500
+++
Looks good to me Alan.
-Chris.
On 11 Feb 2014, at 10:31, Alan Bateman alan.bate...@oracle.com wrote:
Interruptible I/O was a (mostly Solaris only) mis-feature that we've been
eradicating over a number of releases. In JDK 6 the VM option
UseVMInterruptibleIO was added to allow it be
1 - 100 of 2067 matches
Mail list logo