On 10/31/13 10:22 PM, Tristan Yan wrote:
I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based
on my research, it looks like the issue of fixed port was already addressed
by Stuart Marks in other RMI tests which are Java based. I would like to
reuse his solution, however
, Stuart Marks wrote:
On 10/31/13 10:22 PM, Tristan Yan wrote:
I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based
on my research, it looks like the issue of fixed port was already addressed
by Stuart Marks in other RMI tests which are Java based. I would like to
reuse his
Hi all,
Please review the following spec changes to java.lang.String.
In several places the specs mention returning new strings. This is
overspecified; it's sufficient to return a string that satisfies the required
properties. In some cases the current implementation doesn't create a new
On 11/6/13 6:15 PM, David Holmes wrote:
On 7/11/2013 11:31 AM, Stuart Marks wrote:
In several places the specs mention returning new strings. This is
overspecified; it's sufficient to return a string that satisfies the
required properties. In some cases the current implementation doesn't
create
On 11/7/13 12:12 AM, Stuart Marks wrote:
The concat() method is weird in that if the arg is empty, it requires returning
'this'; but if 'this' is empty, it requires creating a new String instead of
just returning the arg. I think this is overspecified. But the implementation
follows this exactly
On 11/7/13 2:13 PM, Brent Christian wrote:
I would change concat() to be similar:
Otherwise, a String object is returned that represents a character sequence
that is the concatenation of...
Yes, that's nice. Thanks for the suggestion. I'll put it in.
s'marks
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 recommendation in the java.io.Serializable page.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8028027
Patch
the class without package. Do
you have suggestion on that?
Thank you so much.
Tristan
On 11/06/2013 09:50 AM, Stuart Marks wrote:
/
/
/ /
On 11/1/13 9:18 AM, Tristan Yan wrote:
/
/Hi Everyone
http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/
/ /
Description:
1. Convert shell script test
On 11/8/13 7:20 AM, Yuri Gaevsky wrote:
Well, it would be more consistent to check for existence of protected or public
serialVersionUID with Reflection API and change the serialver output
accordingly.
Please see suggested fix and its output below.
This change isn't consistent with the
On 11/8/13 1:34 PM, Alan Bateman wrote:
On 08/11/2013 20:56, roger riggs wrote:
Please review this correction to the documentation of the serialized form of
String.
There is no change to the specification or behavior of the serialization of
strings.
It seemed safer to refer to the
want to put TestLibrary into a
named package right now.
Please let me know if you have objection on this.
Thank you
Tristan
On 11/09/2013 02:28 AM, Stuart Marks wrote:
Hi Tristan,
Yes, it's kind of a problem that the RMI TestLibrary is in the unnamed
package. Classes in a named package cannot
to Main class because they need get stub from server. I suggest we move the
benchmark tests to unnamed package unless we do want to put TestLibrary into a
named package right now.
Please let me know if you have objection on this.
Thank you
Tristan
On 11/09/2013 02:28 AM, Stuart Marks wrote:
Hi Tristan
there, unfortunately.
-Yuri
-Original Message-
From: Stuart Marks [mailto:stuart.ma...@oracle.com]
Sent: Friday, November 8, 2013 10:48 PM
To: Yuri Gaevsky
Cc: Alan Bateman; core-libs-dev
Subject: Re: 8028027: serialver should emit declaration with the 'private'
modifier
On 11/8/13 7:20 AM, Yuri Gaevsky
Changeset: f6012ca3bdd3
Author:smarks
Date: 2013-11-12 16:59 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6012ca3bdd3
8028027: serialver should emit declaration with the 'private' modifier
Reviewed-by: darcy, mchung, alanb, chegar
!
-summary.html
Thanks!
s'marks
On 11/7/13 2:31 AM, Stuart Marks wrote:
Hi all,
Please review the following spec changes to java.lang.String.
In several places the specs mention returning new strings. This is
overspecified; it's sufficient to return a string that satisfies the required
be to do something
like adding an @apiNote to String.subSequence() explaining why it's different
from CS.subSequence().
s'marks
Thanks,
David
On 12/11/2013 8:43 AM, Stuart Marks wrote:
Hi all,
Here's an updated version of the String spec change. Changes from the
previous version
Hi all,
Please review this small fix for an intermittent timeout. Nothing seems to be
going wrong except that if the machine running the test is exceptionally slow,
spurious timeouts will occur. The solution is to raise the timeout in the RMI
test infrastructure.
Bug:
Changeset: 19d2e9649138
Author:smarks
Date: 2013-11-19 15:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19d2e9649138
8028638:
java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails
Reviewed-by: lancea
! test/java/rmi/testlibrary/RMID.java
: Thursday, November 14, 2013 11:09 PM
收件人: Stuart Marks
抄送: core-libs-dev@openjdk.java.net
主题: 答复: RFR for JDK-7190106 RMI benchmark fails intermittently because of use
of fixed port
Thank you Stuart
It took me a little time to correct the code. sorry be late. This is new webrev
for the code
On 11/19/13 1:41 PM, Alan Bateman wrote:
On 19/11/2013 20:14, Martin Buchholz wrote:
In jsr166 tests we have mostly switched to 10 second timeouts to mean forever.
But in ProcessBuilder tests we are starting up new java processes with their
well-known startup problems, so using a much larger
On 11/19/13 9:40 AM, Mandy Chung wrote:
On 11/19/13 2:23 AM, Daniel Fuchs wrote:
Hi,
Please find below a webrev for:
8028185: XMLFormatter.format emits incorrect year
https://bugs.openjdk.java.net/browse/JDK-8028185
The fix is trivial:
On 11/15/13 8:36 AM, Alan Bateman wrote:
On 14/11/2013 23:56, Stuart Marks wrote:
On 11/14/13 2:04 AM, David Holmes wrote:
Sorry for the delay (been enroute). Only issue I have remains the subSequence
change - you can't weaken the post-condition of CharSequence.subSequence without
breaking
testlibrary invokes JVM subprocesses using
java.home.)
Thanks,
s'marks
On 11/20/13 1:49 PM, Stuart Marks wrote:
Hi, sorry about the delay, I'm still backlogged from traveling. I'll get to this
soon.
s'marks
On 11/19/13 6:27 PM, Tristan Yan wrote:
Hi Stuart
Did you get chance to review it again.
Let
was talking about.)
s'marks
On 11/25/13 9:12 PM, Tristan Yan wrote:
Hi Stuart
Thanks for your code review. I updated the webrev according your suggestion.
Could you review it again?
http://cr.openjdk.java.net/~ewang/tristan/JDK-7190106/webrev.00/
Tristan
On 11/26/2013 10:36 AM, Stuart Marks wrote
Hi all,
Please review this small change to the subSequence() method specs of
CharSequence and String. Essentially this removes the requirement of returning a
new character sequence at each call. This brings the spec in line with
String's implementation, which will return 'this' in appropriate
Changeset: accd6ffd4b3f
Author:smarks
Date: 2013-12-03 15:52 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/accd6ffd4b3f
8028757: CharSequence.subSequence improperly requires a new CharSequence be
returned
Reviewed-by: alanb, darcy, mduigou
!
Hi all,
Please review the following small javadoc change. The StringJoiner doc for a
couple methods uses i.e. in the first sentence, which screws up the javadoc
logic that pulls the first sentence into the Method Summary. This is an
editorial change to fix this up; there is no actual
Changeset: c6b6b515cf4f
Author:smarks
Date: 2013-12-03 18:19 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6b6b515cf4f
8029489: StringJoiner spec for setEmptyValue() and length() is malformatted
Reviewed-by: darcy, lancea, mduigou
!
Hi Joe,
The changes look sensible to me. Funnily enough, when I read the next, the voice
echoing in my head sounds like Alex's
A small clarification:
+ * li The addition of the additional annotations is both source
+ * compatible and binary compatible. That is, the source containing
+ *
I see this was pushed already. Good, quick work guys!
Yes, there are a couple other RMI test failures caused by aggressive GC of
loggers (or possibly other objects). I know the Hotspot folks have filed a
couple already. But we should keep an eye out for them.
s'marks
On 12/4/13 7:44 AM,
On 12/4/13 11:30 AM, Alex Buckley wrote:
On 12/3/2013 9:23 PM, Joe Darcy wrote:
+ * li The addition of the additional annotations is both source
+ * compatible and binary compatible. That is, the source containing
+ * the element and its annotations will still compile and the class
+ * file
or suggestions.
/ /
Thank you
Tristan
On 12/05/2013 09:02 AM, Stuart Marks wrote:
/
/On 12/3/13 11:05 PM, Tristan Yan wrote:
/
/I am working on https://bugs.openjdk.java.net/browse/JDK-7168267. This bug is
asking performance improvement for RMI test. Because this would involve
different RMI
Hi all,
Just one more deprecation task for JDK 8
Please review the following change to rmic to add a warning message that's
emitted when static stubs are generated:
http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/
https://bugs.openjdk.java.net/browse/JDK-8027536
Thanks,
On 12/11/13 2:37 PM, Mandy Chung wrote:
The change looks okay. The error(...) method is called to print warnings
seems to be confusing. Perhaps better to call output(getText()) directly?
Yeah, it's confusing. I'll change it.
One other note: AFAIK the last message drop for jdk8
like javac and
now rmic, but using the deprecated features will still work. (For the time
being, heh heh heh.)
s'marks
On 12/11/13 3:39 PM, Darryl Mocek wrote:
Should this be a warning or error?
Darryl
On 12/11/2013 01:53 PM, Stuart Marks wrote:
Hi all,
Just one more deprecation task
Changeset: 6c343d3d2721
Author:smarks
Date: 2013-12-13 18:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c343d3d2721
8027536: rmic: add deprecation warning message when generating JRMP static
stubs/skeletons
Reviewed-by: mchung, dmocek
!
for bug JDK-7168267
http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.01/
http://cr.openjdk.java.net/%7Etyan/JDK-7168267/webrev.01/
This is a cleanup for RMI tests. trying to use real timeout to replace a fixed
number of loop.
Thank you
Tristan
On 12/12/2013 05:33 AM, Stuart Marks wrote
On 12/18/13 10:25 PM, Tristan Yan wrote:
Hi Everyone
Please help to review the fix for JDK-8030284.
http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/
http://cr.openjdk.java.net/%7Etyan/JDK-8030284/webrev.00/
This is a one line fix that add -Xss to prevent StackOverflowError.
Hi, I
On 12/20/13 2:03 PM, Joe Darcy wrote:
On 12/20/2013 01:21 PM, Mandy Chung wrote:
--- a/src/share/classes/java/lang/reflect/Method.javaFri Dec 20 08:59:52
2013 -0800
+++ b/src/share/classes/java/lang/reflect/Method.javaFri Dec 20 10:26:17
2013 -0800
@@ -251,7 +251,8 @@
}
/**
-
part. Please review.
http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.02/
Thank you
Tristan
On 12/20/2013 10:47 AM, Stuart Marks wrote:
Hi Tristan,
Changes mostly look good.
There is an ignored InterruptedException in both versions of
UseCustomSocketFactory.java, but that was there already
On 12/19/13 8:29 PM, David Holmes wrote:
If you were always one frame from the end then it is not so surprising that a
simple change pushes you past the limit :) Try running the shell test with
additional recursive loads and see when it fails.
David doesn't seem surprised, but I guess I still
Hi Tristan,
First of all, these are two completely separate changes. They're sort-of related
in that they involve replacing sleep() loops and polling with different
constructs, but other than that, they're completely independent. As you'll see
from my review comments, there are different
Hi all,
A simple change to the RMI test library: remove a callback-based mechanism,
which is no longer used by any tests. A bit of associated cleanup is included as
well.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8007256
Webrev:
AM, Stuart Marks wrote:
On 12/19/13 8:29 PM, David Holmes wrote:
If you were always one frame from the end then it is not so surprising that a
simple change pushes you past the limit :) Try running the shell test with
additional recursive loads and see when it fails.
David doesn't seem
On 1/7/14 2:26 PM, Joe Darcy wrote:
public abstract class Ref {
So the type has been deprecated for at least 10 years. Rather than fixing the
warning in the class, I think the best course of action is to remove the file in
JDK 9. A build of OpenJDK without this file builds fine; if a build of
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 this one:
java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName
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.
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
) 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/2014 10:20 AM, Stuart Marks wrote:
On 1/23/14 10:34 PM, Tristan Yan wrote:
Hi All
Could you review the bug fix
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
://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 like you to make
before I push it for you. Part of this is to get you to do a more
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
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
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
On 1/30/14 3:13 AM, Paul Sandoz wrote:
On Jan 30, 2014, at 3:57 AM, Stuart Marks stuart.ma...@oracle.com 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
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
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 my $.02
Sent from my phone
On Jan 31, 2014 2:06 PM, Stuart Marks stuart.ma...@oracle.com
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,
I don't want to put the workaround
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
/~tyan/JDK-8030844/webrev.01/
Regards
Tristan
On Feb 12, 2014, at 10:06 AM, Stuart Marks stuart.ma...@oracle.com
mailto:stuart.ma...@oracle.com wrote:
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
, 2014, at 8:32 AM, Stuart Marks stuart.ma...@oracle.com
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 started at line 208
and following seems unnecessary
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
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 individual RMI
. 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. Unfortunately the webrev
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
://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 start of the
waitFor(timeout) javadoc comment is a bit off, though; please fix.
There are still some adjustments that need
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
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
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 stuart.ma
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
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
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
emitted by the 'rmiregistry
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
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 stuart.ma...@oracle.com
mailto:stuart.ma
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
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 status
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
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,
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 version.
s'marks
On 2/28/14 5:35 PM, Stuart Marks wrote
, 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 trip through the JMM, restoring
the sentinel values to zeroes and renaming the fields to be explicit
, 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
/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. :-)
My
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.
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
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
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
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
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: core-libs
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
This is somewhat moot at this point, but
I'd recommend against using paragraph end tags /p. 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
/thread.html#19269
Cheers,
Paul
On Mon, Jun 16, 2014 at 11:33 PM, huizhe wang huizhe.w...@oracle.com
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 using paragraph end
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 /p end tag is that it's easy for
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
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
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.
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
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
On 7/3/14 5:03 AM, Paul Sandoz wrote:
On Jul 3, 2014, at 1:05 PM, Ivan Gerasimov ivan.gerasi...@oracle.com 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
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
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
1 - 100 of 1347 matches
Mail list logo