On 2/12/15 3:15 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
OK, overall looks pretty good. Two minor comments on Matcher.java:
1202 if (expectedCount >= 0 && expectedCount != matchOrResetCount)
1203 return tr
On 2/11/15 12:45 PM, Paul Sandoz wrote:
On Feb 11, 2015, at 8:23 PM, Stuart Marks wrote:
That "matches" my original thinking on the matter and is reflected in the patch. It's
very simple to support. If the method was named "findAll" then it would be misleading and
On 2/11/15 1:54 AM, Paul Sandoz wrote:
On Feb 11, 2015, at 12:02 AM, Stuart Marks wrote:
Hi Paul,
On 2/3/15 5:48 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
This patch adds a new flat mapping collector to Collectors. This can
chResults aren't passed around,
they're created from Patterns/Matchers and processed within the same code, so in
practice this won't be a problem.
s'marks
Paul.
On Feb 11, 2015, at 2:02 AM, Stuart Marks wrote:
Hi Paul,
I spent some time looking at this API. Over
Hi Paul,
I spent some time looking at this API. Overall it seems to me that things work a
bit more nicely when these methods are added to Pattern instead of Matcher.
Unfortunately there are some odd things with the existing API that make this
tradeoff not so obvious.
First, here's what a sim
Hi Paul,
On 2/3/15 5:48 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
This patch adds a new flat mapping collector to Collectors. This can be useful
if one needs to map 0 or more items into a downstream collector.
Mostly pretty good
On 2/3/15 4:01 PM, Brent Christian wrote:
The code in bug 8071667 [1] passes a mappingFunction to computeIfAbsent() which
itself put()s a sufficient number of additional entries into the HashMap to
cause a resize/rehash. As a result, computeIfAbsent() doesn't add the new entry
at the proper plac
On 1/28/15 7:07 AM, Alan Bateman wrote:
On 27/01/2015 04:37, Mandy Chung wrote:
System.runFinalizationOnExit has been deprecated since 1998 (JDK 1.2)
and this method is inherently unsafe. I am thinking to propose this method
in JDK 9 to throw UnsupportedOperationException.
I believe it's rare
On 1/26/15 2:15 PM, Remi Forax wrote:
On 01/26/2015 07:42 PM, Alan Bateman wrote:
On 26/01/2015 18:32, Paul Sandoz wrote:
On Jan 20, 2015, at 7:05 PM, Paul Sandoz wrote:
Hi,
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8050819-Stream-ofNullable/webrev/
Stream.ofNullable can make it easier
Hi all,
Could I get a review for this? (Serves me right for posting this just before the
holidays.)
Turns out this is the root cause of some test failures.
Thanks,
s'marks
P.S. Happy new year, everyone!
On 12/23/14 5:24 PM, Stuart Marks wrote:
Hi all,
Please review this change,
k.java.net/~xiaofeya/8066085/webrev.02/. Please sponsor this
changeset for me.
Thank you very much,
-Felix
On 12/24/2014 1:01 PM, Stuart Marks wrote:
Hi Felix,
Good improvements. I think this is pretty close; I have just a few minor
comments.
* The test is named IIOPSanityTest but it's in a
Hi Ivan,
It's not clear to me that quoting should be applied at this level. On Unix,
quotes are stripped by the shell at the time the command line is split into
arguments, so the values should be treated literally without further quote
processing.
The referenced blog post at MSDN talks about
an sponsor this changeset for you if you need a sponsor.
Thanks,
s'marks
On 12/19/14 1:56 AM, FELIX YANG wrote:
Hi Stuart,
please review the updated webrev:
http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.01/
Thanks,
-Felix
On 12/12/2014 4:08 PM, Stuart Marks wrote:
On 12/11/
Hi all,
Please review this change, which adds handling of the test.timeout.factor
property to the RMI tests. These tests have a fair number of internal timeouts;
this change multiplies the timeout values by test.timeout.factor so that
timeouts will be less likely on slow systems, where a timeo
PM, Stuart Marks <mailto:stuart.ma...@oracle.com>> wrote:
Hi, any reviewers for this changeset?
Thanks,
s'marks
On 12/12/14 12:05 PM, Stuart Marks wrote:
Hi all,
Please review this small fix and cleanup to this test. The old version would
force garbage collection of an un
Hi, any reviewers for this changeset?
Thanks,
s'marks
On 12/12/14 12:05 PM, Stuart Marks wrote:
Hi all,
Please review this small fix and cleanup to this test. The old version would
force garbage collection of an unreferenced RMI object by allocating lots and
lots of memory until OO
On 12/12/14 7:54 AM, Chris Hegarty wrote:
On 12/12/14 15:40, Pavel Rappo wrote:
Could you please review my change for JDK-8066642?
http://cr.openjdk.java.net/~prappo/8066642/webrev.00/
The first change, to remove SocketSecurityException seems benign.
SocketSecurityException is a subclass of
Hi all,
Please review this small fix and cleanup to this test. The old version would
force garbage collection of an unreferenced RMI object by allocating lots and
lots of memory until OOME is received, which takes a long time and could cause a
timeout. The better approach is simply to unexport
On 12/11/14 8:41 PM, FELIX YANG wrote:
Hi all,
please review the fix to add a sanity checking for rmic -iiop compiling.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8066085
Webrev:
http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.00/
Hi Felix,
Thanks for picking up t
Hi all,
Please review this tiny fix to remove the source of a deprecation warning and to
remove the now-unnecessary suppression of deprecation warnings from its context.
There are other deprecated usages mentioned in this bug report but for a variety
of reasons they either cannot be removed o
I broke RMIConnector_NPETest again. This time it was passing a timeout value
that caused some time calculations to overflow, causing the RMI test library to
time out prematurely.
Please review this fix, which is to limit timeout values to something reasonable
and to change the test to use the
Hi all,
Moar RMI test cleanups!
The main issue is that the timing loop that waits for rmid to start will now
check to make sure the process hasn't exited prematurely.
I've also taken the opportunity to simplify this and other timing loops in the
RMI test library and to make their elapsed-tim
On 12/3/14 6:41 AM, Alan Bateman wrote:
On 03/12/2014 14:40, Chris Hegarty wrote:
diff --git
a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
---
a/test/javax/management/remote/mandatory/c
Hi Lance,
Overall, looks fine.
Typo "earleir" at line 569.
I agree with having two separate init methods, since initDriversIfNeeded()
conveniently separates the (safe) double-checked locking idiom from the actual
initialization legwork in loadInitialDrivers().
I'm not entirely convinced, ho
Great, this sounds fine.
s'marks
On 12/2/14 6:03 AM, Miroslav Kos wrote:
Hi Stuart,
minor stuff like invalid characters and copyright years I can fix before push,
the rest will leave for next integration which should be soon.
Thanks!
Miran
On 01/12/14 20:35, Stuart Marks wrote:
Hi
Thanks Lance, I knew you'd come through. :-)
On 12/1/14 10:53 AM, Lance Andersen wrote:
Sorry Stuart, I looked at this last week but guess I forgot to reply.
It looks fine and a nice clean up :-)
Best
Lance
On Dec 1, 2014, at 1:50 PM, Stuart Marks <mailto:stuart.ma...@oracle.com
Hi Miran,
I'm pretty distant from the JAX-WS code, but I looked through all of the files
and most of the changes seem sensible. There are a few things that are
questionable though.
**
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
The catch-
Hi all, any reviewers for this one?
s'marks
On 11/24/14 6:26 PM, Stuart Marks wrote:
Hi all,
Here's another test cleanup fix. Basically this normalizes the shutdown/destroy
policy for rmid processes that are started by RMI's test library in support of a
few dozen of the RMI a
Hi all,
Here's another test cleanup fix. Basically this normalizes the shutdown/destroy
policy for rmid processes that are started by RMI's test library in support of a
few dozen of the RMI activation tests. The previous implementation was, well,
confused, and it had a redundant timing loop th
Hi Patrick,
Good to meet you in Antwerp!
On 11/20/14 10:30 AM, Patrick Reinhart wrote:
Am 20.11.2014 um 10:22 schrieb Pavel Rappo :
There is at least one method in the JDK with similar characteristics:
java.nio.file.Files#copy(java.io.InputStream, java.io.OutputStream)
But, (1) it has a priva
Hi all,
Here's a small test cleanup fix for review. This test fails rarely but often
enough to be annoying. The cause is one or more of the following: a memory
visibility issue (unsafe read/write to non-volatile fields), a race condition
(fixed Thread.sleep(500) wait time), and potential failu
On 10/30/14 2:21 AM, Chris Hegarty wrote:
On 30 Oct 2014, at 07:31, David Holmes wrote:
On 30/10/2014 4:00 PM, Stanimir Simeonoff wrote:
It could be defense vs Thread.currentThread().run() in finalizer that
would cause calling run() of Thread.target. I am not sure if that would
cause invocatio
On 10/29/14 7:22 PM, David Holmes wrote:
Hi Stuart,
You're a brave man! :)
:-)
Right - there is no change in behaviour with your change other than fixing the
problem with the cleared interrupt bit. That's the best you can do in my
opinion.
OK, after thinking about it, I was starting to le
Hi all,
Please review this small change that fixes this bug in System.runFinalization()
and Runtime.runFinalization().
Bug: https://bugs.openjdk.java.net/browse/JDK-4354680
Webrev: http://cr.openjdk.java.net/~smarks/reviews/4354680/webrev.0/
This is probably the simplest approach, which
Hi all,
Quick addition to the problem list. This test has been failing intermittently
for a while, but for some reason it seems to be failing a bit more often
recently. Please review the patch below.
Thanks,
s'marks
# HG changeset patch
# User smarks
# Date 1414457168 25200
# Mon Oct
Hi Ivan,
Sorry for not having gotten back to you earlier about this.
I'm uncomfortable with pushing in such a fix in the absence of a reproducer
and/or a test case. Although the change itself seems sensible, the fact that we
lack a reproducer means that we might not actually understand the pro
On 7/19/14 2:04 AM, Remi Forax wrote:
You can combine these 2 approachesi using a Ruby like builder approach with a
lambda,
which provide a builder object (so static method call are replaced by instance
method call) avoiding the creation of too many entry objects
Map.of(b -> b
.entry(k
On 7/18/14 4:41 PM, David M. Lloyd wrote:
On 07/18/2014 06:36 PM, Stuart Marks wrote:
Map.of()
.add(k0, v0)
.add(k1, v1)
...
.add(kN, vN);
this would result in O(N^2) performance and space allocation, though
most of the allocated space is garbage
On 7/18/14 2:17 AM, Michael Kay wrote:
On 18 Jul 2014, at 10:09, Wang Weijun wrote:
A .with(k, v) to create a new immutable map with an extra pair.
Yes, that's the same as my A.add(k,v) -> A proposal.
Works whether A is mutable or immutable.
I don't think we want to have a Map.add(k,v) ins
o, if it's different.
- There might be some use cases for Iterator; likely doesn't carry its weight,
though.
Yes, interesting. Most collection implementations have special features that
apply to mutability. The Sorted (or maybe Navigable) variations of Set or Map
could be useful though.
s&
On 7/17/14 10:17 AM, Steven Schlansker wrote:
This is fantastic, I think a large number of developers will cheer as more and
more of Guava
makes it into core libs :)
Great!
One thing I notice is that you take a lot of care to not specify how the Map or
Set will be implemented.
This could
On 7/17/14 12:46 AM, Tom Hawtin wrote:
I note that with the basic proposal, HashSet.of and indeed NavigableSet.of still
work. They just do the wrong thing.
I should have made more clear in the JEP that the proposed APIs are static
methods on the List/Map/Set interfaces, not default methods. Th
und N = 5. But maybe it's a bit higher.
The tradeoff here is that we are willing to put up with a certain amount of API
ugliness in order to make people's programs nicer. If we can cover a vast
majority of people's cases, that's just fine, even if it's not fully general.
s&
On 7/16/14 6:03 PM, Remi Forax wrote:
On 07/17/2014 02:46 AM, Stuart Marks wrote:
Please review this draft JEP for Convenience Factory Methods for Collections:
https://bugs.openjdk.java.net/browse/JDK-8048330
Brief background: several times over the years there have been proposals to
add
Hi all,
Please review this draft JEP for Convenience Factory Methods for Collections:
https://bugs.openjdk.java.net/browse/JDK-8048330
Brief background: several times over the years there have been proposals to add
"collection literals" to the language. The most recent round of this was in
Hi all,
Please review this small patch to fix one of the old RMI tests that has started
failing. This simply removes a couple test cases that use the (hidden,
unsupported) -Xnew option of rmic, which relies on support for old -source and
-target values that were recently removed from javac by
On 7/3/14 5:03 AM, Paul Sandoz wrote:
On Jul 3, 2014, at 1:05 PM, Ivan Gerasimov wrote:
Paul, would you please include a few more typo fixes, if it's not too late?
Thanks for doing this, the changes look good.
Unfortunately it's too late for this bug, but i will merge it into the patch
f
On 7/2/14 1:25 AM, Paul Sandoz wrote:
Stuart, are you planning to back port your doc fix to 8u-dev? If so we could do
all three in one go.
Hm, it might be a good idea to do so, in case we refresh the published javadoc
in one of the 8-updates. That way the corrections will get out there sooner
Please review this small patch to fix some errors in the examples in the docs
for java.util.stream.Collectors. Thanks to Raoul Urma for pointing these out.
s'marks
# HG changeset patch
# User smarks
# Date 1404256293 25200
# Tue Jul 01 16:11:33 2014 -0700
# Node ID 5b6a12d8a26e96052bc1c3ff
On 6/30/14 8:17 AM, Henry Jen wrote:
On 06/30/2014 12:18 AM, Alan Bateman wrote:
On 30/06/2014 02:30, Henry Jen wrote:
On 06/20/2014 02:28 PM, Henry Jen wrote:
Please review a trivial webrev for jdk9/corba that do the same @since
tag normalization as in jdk9/jdk.
http://cr.openjdk.java.net/~h
On 7/1/14 1:34 AM, Alan Bateman wrote:
On 01/07/2014 02:21, Jeremy Manson wrote:
diff --git a/src/share/classes/java/io/File.java
b/src/share/classes/java/io/File.java
--- a/src/share/classes/java/io/File.java
+++ b/src/share/classes/java/io/File.java
@@ -1998,7 +1998,8 @@
throws IOE
On 6/26/14 7:23 AM, roger riggs wrote:
On 6/26/2014 4:55 AM, Peter Levart wrote:
- Will there be a guarantee that ProcessHandle objects returned from factory
methods: [...]
representing those processes that were started by ProcessBuilder API are
actually the same Process objects that were return
On 6/16/14 9:33 PM, huizhe wang wrote:
It's not xhmtl, but I would think closing tags is a good practice. Being
explicit is always a good thing to do.
Being explicit sounds good, but in this case it leads to errors; see below.
The problem with using the end tag is that it's easy for addition
l/core-libs-dev/2013-July/thread.html#19269
Cheers,
Paul
On Mon, Jun 16, 2014 at 11:33 PM, huizhe wang <mailto:huizhe.w...@oracle.com>> wrote:
On 6/16/2014 5:35 PM, Stuart Marks wrote:
This is somewhat moot at this point, but
I'd recommend against u
This is somewhat moot at this point, but
I'd recommend against using paragraph end tags . Paragraph end tags really
are optional in HTML. I've heard some advocates of end tags, such as commenters
on the linked web page, say that end tags are somehow "more correct" (wrong) or
that end tags
Hi Martin,
Thanks for augmenting my patch and pushing it into the JSR166 repo. Here's the
patch rebased against jdk9-dev. Please review.
s'marks
# HG changeset patch
# User smarks
# Date 1402960663 25200
# Mon Jun 16 16:17:43 2014 -0700
# Node ID c8c2d902f3f1338b8074607367e7af8e294ae1c
Hi all,
Here's a draft JEP for stabilizing the core libraries regression test suite,
that is, fixing up the spuriously failing tests. Please review and comment.
Thanks!
s'marks
Title: JDK Core Libraries Test Stabilization
Author: Stuart Marks
Organization: Oracle
Discussion:
On 4/21/14 1:58 PM, Lance Andersen wrote:
Need a reviewer for some additional updates of the SQLException tests I pushed
on Friday so that they play nicer WRT clean up on windows with some tools.
Did some minor refactoring as part of this to address some of Roger's earlier
comments seeing I
On 4/15/14 1:46 AM, Alan Bateman wrote:
On 15/04/2014 09:05, Richard Warburton wrote:
The only issue that I'm aware of that is related to this kind of change is
the requirement to recompile all the classes in the hierarchy when making a
change [0]. If you don't do this its possible for an infini
On 3/5/14 4:57 PM, David Holmes wrote:
On 6/03/2014 8:05 AM, Stuart Marks wrote:
Please review this fix to change RMI's test library to pass through
vmoptions and javaoptions to rmid and other JVM subprocesses.
Are you sure you want to do that? Run everything with -Xcomp for example?
Hi all,
Please review this fix to change RMI's test library to pass through vmoptions
and javaoptions to rmid and other JVM subprocesses.
I've marked this as a "small" review because the changes of substance are
confined to the first four files in the webrev, and they're pretty small. The
re
Hi Joe,
Fix looks good. I confirmed that the svuid value in your patch is the right one
to be compatible with 6 and 7, at least for all the versions of those releases
that I have at my fingertips (which is several). And yes, we need to figure out
how best to fix this in the 8 release family.
On 02/28/2014 08:58 AM, Stuart Marks wrote:
On 2/27/14 12:11 PM, Joe Darcy wrote:
I am trying hard to remain blissfully ignorant of any more low-level details of
the serialization format; however, I might not be successful on that goal much
longer ;-)
I believe your latter statement is correct. :
at 1:09 PM, Stuart Marks wrote:
Just a couple small items.
At line 4203, the type of magnitude should be byte[] instead of int[]. Whoops,
I could have sworn I wrote that in my previous review, but it must have gotten
dropped while I was editing. Sorry about that.
I caught that myself and fixed
r "thumbs up" as this has changed since Paul's approval
was posted.
On Feb 28, 2014, at 5:35 PM, Stuart Marks wrote:
Thanks, Paul. I refreshed the webrev
http://cr.openjdk.java.net/~bpb/8035279/webrev.01/ with the agreed upon version.
This is pretty good. After this long, strange t
entries in this array describe the field names that are used in the serialized
output, which is essential for remaining compatible with older versions of
BigInteger. I checked an old version of BigInteger from 1998 and the field names
used here match the actual, serialized fields from that old
On 2/27/14 12:14 PM, Brian Burkhalter wrote:
On Feb 27, 2014, at 12:17 AM, Paul Sandoz wrote:
So may I obtain a +1 from a JDK 9 Reviewer now?
Indeed you may.
Thanks, Paul. I refreshed the webrev
http://cr.openjdk.java.net/~bpb/8035279/webrev.01/ with the agreed upon version.
Hi Brian,
On 2/26/14 11:34 AM, Brent Christian wrote:
File under "chipping away at test stabilization issues."
https://bugs.openjdk.java.net/browse/JDK-6835233
I would like to resolve this bug by removing the "@ignore" tag for JDK 9, and
bring the test back into rotation. If the failure comes back, I'll
On 2/27/14 12:11 PM, Joe Darcy wrote:
I am trying hard to remain blissfully ignorant of any more low-level details of
the serialization format; however, I might not be successful on that goal much
longer ;-)
I believe your latter statement is correct. :-)
My preference in a case like this is
Hi all,
Any takers for this review?
s'marks
On 2/18/14 6:47 PM, Stuart Marks wrote:
Hi all,
Please review this change to remove a redundant timing-retry loop from the
rmidRunning() routine of the RMI test library. It is replaced with a simple rmid
registry lookup that returns s
On 2/25/14 12:34 AM, Tristan Yan wrote:
Could you please help to review code fix for JDK-8035388.
http://cr.openjdk.java.net/~tyan/JDK-8035388/webrev.00/
Description:
method inactiveObject in ActivationGroupImpl.java, release lock happen before
checkInactiveGroup. This makes groupInactive reset
ame way, an int size followed by all the
elements in iterator order. There should have been a utility method to help
do that. Compare and contrast with the reliable "serialization" provided by
Collection.toString.
On Mon, Feb 24, 2014 at 10:53 PM, Stuart Marks <mailto:stuart.ma...@
On 2/24/14 8:22 PM, Joe Darcy wrote:
On 02/20/2014 12:49 PM, Paul Benedict wrote:
Joe, I find it interesting that you suppressed the serial warning on an
abstract class. I'd like to know more about that. Is this a universal rule?
Are serial uids not important for abstract classes?
I wouldn't
so that the test can
test the tool with different options in the same VM and avoid launching another
VM. In any case, I agree these 2 tests are not as useful.
Mandy
On 2/20/2014 6:02 PM, Stuart Marks wrote:
Hi all,
There are a couple of RMI tests that do nothing except check the usage message
em
Hi all,
There are a couple of RMI tests that do nothing except check the usage message
emitted by the 'rmiregistry' and 'rmid' commands when given invalid command-line
options. Since two bugs have occurred in these tests, I have determined that the
overhead of maintaining these tests outweighs
On 2/20/14 9:55 AM, Peter Levart wrote:
On 02/20/2014 11:20 AM, David Holmes wrote:
re: volatile
The basic approach being taken with these primitive fields is lazy
initialization to a value that will always be the same if recomputed. If the
variables are not volatile then in the worst-case (thi
eird but I didn’t figure out the
right solution. Also I wasn’t so sure why we print out so many messages now
it’s clear to me.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.05/
I’m sorry I have to ask you review this again.
regards
Tristan
On Feb 15, 2014, at 9:47 AM, Stuart Marks mailto
Hi all,
Please review this change to remove a redundant timing-retry loop from the
rmidRunning() routine of the RMI test library. It is replaced with a simple rmid
registry lookup that returns status immediately, without retries.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8034999
Web
On 2/14/14 9:43 AM, David M. Lloyd wrote:
On 02/14/2014 09:56 AM, David M. Lloyd wrote:
In the JDK, java.util.Date does not read/write fields. Perhaps others
as well. Given that the behavior is presently undefined, that means the
serialized representation of java.util.Date (and any other such
d. I put
TestLibrary.bomb in the bottom of the main method which only shows test fail
message.
Could you review it again
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.04/
Tristan
On 02/13/2014 05:29 AM, Stuart Marks wrote:
Hi Tristan,
JavaVM.waitFor looks mostly fine. The indentation of the s
On 2/14/14 10:31 AM, Michael McMahon wrote:
Also, I think mercurial won't delete the empty directory after the file is gone
- not that that matters very much.
If you delete the last file in a directory, the empty dir might stay around in
your working copy. But the directory will be absent from
d try both ways. Adopt your fix doesn't seem
work for me. It still doesn't generate changeset. But without -r option works.
http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.02/
Could you push it for me?
Tristan
On 02/13/2014 03:48 AM, Stuart Marks wrote:
Hi Tristan,
Changes look good.
Thanks guys.
And Joe, you know that I *always* look good! :-)
s'marks
On 2/12/14 11:31 PM, Joe Darcy wrote:
Look good Stuart,
-Joe
On 02/12/2014 11:08 PM, Stuart Marks wrote:
Hi all,
The RMI test directories were removed from TEST.ROOT's othervm.dirs by
JDK-8031179 so that indi
Hi all,
The RMI test directories were removed from TEST.ROOT's othervm.dirs by
JDK-8031179 so that individual RMI tests could opt-in to othervm themselves.
Unfortunately, some tests needed othervm but didn't get it, causing them to fail.
This adds othervm to some failing tests, and adds a not
ciate you can review this again.
Regards
Tristan
On Feb 11, 2014, at 8:32 AM, Stuart Marks mailto:stuart.ma...@oracle.com>> wrote:
Hi Tristan,
Sorry about my recurring delays.
Several comments on these changes.
JavaVM.java --
The waitFor(timeout) method is mostly ok. The new thread star
n 2/11/14 6:59 PM, Tristan Yan wrote:
Thank you Stuart
http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.01/
Regards
Tristan
On Feb 12, 2014, at 10:06 AM, Stuart Marks mailto:stuart.ma...@oracle.com>> wrote:
Hi, yes, I'll take this one.
It's slightly odd that this is creating filenames that a
Hi, yes, I'll take this one.
It's slightly odd that this is creating filenames that already have "/" in them
(as opposed to File.separator) but since these files don't actually have to
exist, I suppose it doesn't really matter.
I'm not convinced that we actually have any evidence that /home/~
icky. I think we should just
destroy JVM once exception is thrown. So I move the wait logic into try block
instead keep them in finally block.
Can you receive it again.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.02/
Thank you
Tristan
On 01/29/2014 03:16 PM, Stuart Marks wrote:
Hi Tristan,
n but
to allocate, it's nice to have collectors that can handle those necessary
allocations well. Otherwise, if it's a perf sensitive area and avoiding
allocations doesn't obfuscate or make the code significantly less
maintainable, it's usually better to avoid allocations.
Just
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, the existing StringBuilder instances, skipping of
primitive/object reading/writi
On 1/30/14 3:13 AM, Paul Sandoz wrote:
On Jan 30, 2014, at 3:57 AM, Stuart Marks wrote:
Then, awaitInitialized seems straightforward until you see that the
condition is waiting for the value of a final variable to change! JLS sec
17.5 [1] allows all sorts of optimizations for final fields
On 1/30/14 1:09 AM, Daniel Fuchs wrote:
I wonder whether you should replace the assert in the
constructor by an explicit null check:
- assert systemStub != null
+ if (systemStub == null) throw new NullPointerException();
The reason I see is that before your change, an object constructed
with a
On 1/30/14 2:35 AM, David Holmes wrote:
On 30/01/2014 5:34 PM, Tristan Yan wrote:
Hi Stuart
I didn’t make my comment clear. You set interrupted as true when thread
gets interrupted. Here it's still going to wait until systemStub is not
null. Why do you still need interrupt current thread in th
On 1/29/14 8:50 PM, Tristan Yan wrote:
Looks like in you new webrev. The wait will continue to go loop until
systemStub is not null. If it’s what you meant to do that?
Yes. In the previous webrev, systemStub started off as null and made a single
transition to non-null. The boolean 'initialize
on your comments. Can you please review again? Thanks
a lot!
http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.01/
<http://cr.openjdk.java.net/%7Eewang/JDK-8031179/webrev.01/>
Eric
On 2014/1/25 8:53, Stuart Marks wrote:
Hi Eric,
OK, overall this looks good. There are a few adjustments I'd l
Hi all, wow, lots of comments on this. Let me see if I can tackle them in one
message.
Quick aside before I get to the issues: my priorities for this code are
correctness and maintainability, possibly at the expense of performance. In
other words I'm willing to make the code more complex so th
ActivationSystem. Also
I did some cleanup if you don't mind. Add a waitFor(long timeout, TimeUnit
unit) for JavaVM. Which we can have a better waitFor control.
I appreciate you can review the code again.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.01/
Thank you
Tristan
On 01/25/20
Hi all,
Please review this fix to a race condition in rmid initialization. Briefly, rmid
subclasses the RMI registry implementation and provides special handling for its
own stub. Unfortunately the registry is exported in the super() call, making
remote calls possible before rmid's stub initia
On 1/23/14 10:34 PM, Tristan Yan wrote:
Hi All
Could you review the bug fix for JDK-8032050.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/
Description:
This rare happened failure caused because when RMID starts. It don't guarantee
sun.rmi.server.Activation.startActivation finishes.
Fi
another bug https://bugs.openjdk.java.net/browse/JDK-8032629 for
exclusiveAccess.dirs
Thanks,
Eric
On 2014/1/18 8:45, Stuart Marks wrote:
Hi Eric,
Thanks for doing the analysis of the tests that need /othervm. The list of
tests that don't need /othervm looks good. One subtlety is th
1001 - 1100 of 1414 matches
Mail list logo
