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 tests could opt-in to othervm
themselves. Unfortunately, some tests needed othervm but didn't get
it, causing
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
Thank you Stuart
This is a very nice tutorial. I did 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, Stu
On 02/13/2014 02:35 AM, Alan Bateman wrote:
The changes look okay to me. I see you decided to ignore the javac
usages but that is okay and can be done another time.
Also thanks for fixing lookup.sh. I don't personally mind lines > 80
but that one was >180 which make it difficult to look at sid
On 02/12/2014 05:36 PM, Henry Jen wrote:
On 02/12/2014 07:05 AM, Wang Weijun wrote:
This line does not compile
Files.list(Paths.get("/secret")).forEach(x -> Files.write(x, new
byte[Files.size(x)]);
because Files.write() and Files.size() throw IOE. Then what's the
best way to make it wor
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 to be made in
ShutdownGracefully.java. Both have to do with the case where the last
registration suc
Hi Tristan,
Changes look good. Unfortunately the webrev doesn't contain an actual changeset;
it just contains a patch. In the webrev header there is the line "Patch of
Changes". Instead it should say "Changeset". Like this one:
http://cr.openjdk.java.net/~smarks/reviews/7900311/webrev.1/
Unf
On 12/02/2014 04:26, huizhe wang wrote:
Hi Lance, Daniel,
I suggest we take this incompatibility and document it in the release
notes (we'll likely have more). I reversed DurationImpl and then
realized why the Xerces engineers made the incompatibility change when
I started on XMLGregorianCale
On 12/02/2014 12:59, michael cui wrote:
On 02/10/2014 05:36 PM, Alan Bateman wrote:
A minor comment on test/java/net/URLPermission/nstest/lookup.sh is
that the resulting line length is 182 characters and this will likely
be annoying for future side-by-side views. So I think I'd split this
whil
This looks good to me too.
Mandy
On 2/12/2014 10:10 AM, roger riggs wrote:
Hi Phil,
The changes look fine. (Not a "Reviewer").
Thanks for doing the backport,
Roger
On 2/11/2014 6:42 PM, Phil Race wrote:
Here's a JDk8u webrev : -http://cr.openjdk.java.net/~prr/8031737.8u/
-phil.
On 2/11/
Ok, understand.
Thanks,
Joe
On 2/11/2014 11:40 PM, Schreiber, Steffen wrote:
Hi Joe,
Yes, that's certainly true, if the test is only to show the issue.
We intended the test to work as a regression test as well and wanted to check the
effects of the buffer boundaries on more possible places, i
This looks fine.
On Feb 11 2014, at 15:42 , Phil Race wrote:
> Here's a JDk8u webrev : -http://cr.openjdk.java.net/~prr/8031737.8u/
>
> -phil.
>
> On 2/11/14 2:28 PM, Phil Race wrote:
>> So since hg export/import doesn't apply cleanly and the dependency
>> chain seems, long and in order to ha
On 12/02/2014 17:46, Mandy Chung wrote:
This patch cleans up a few trivial native warnings (mainly remove
local unreferenced variable)
https://bugs.openjdk.java.net/browse/JDK-8030010
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8030010/webrev.00/
This patch was contributed by
Hi Phil,
The changes look fine. (Not a "Reviewer").
Thanks for doing the backport,
Roger
On 2/11/2014 6:42 PM, Phil Race wrote:
Here's a JDk8u webrev : -http://cr.openjdk.java.net/~prr/8031737.8u/
-phil.
On 2/11/14 2:28 PM, Phil Race wrote:
So since hg export/import doesn't apply cleanly
Hi Mandy
This looks OK to me
On Feb 12, 2014, at 12:46 PM, Mandy Chung wrote:
> This patch cleans up a few trivial native warnings (mainly remove local
> unreferenced variable)
> https://bugs.openjdk.java.net/browse/JDK-8030010
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs
This patch cleans up a few trivial native warnings (mainly remove local
unreferenced variable)
https://bugs.openjdk.java.net/browse/JDK-8030010
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8030010/webrev.00/
This patch was contributed by Francis Andre [1] and I fixed a couple
On 12/02/2014 16:36, Henry Jen wrote:
I am not sure there is a "recommended" way. Depends on how you need to
handle those exceptions, I'll put the lambda in a private function to
take care those exception, and surpress them in a UncheckedIOException.
Yes, I think it depends on whether he want
On Feb 12, 2014, at 4:05 PM, Wang Weijun wrote:
> This line does not compile
>
> Files.list(Paths.get("/secret")).forEach(x -> Files.write(x, new
> byte[Files.size(x)]);
>
> because Files.write() and Files.size() throw IOE. Then what's the best way to
> make it work?
>
It depends...
Some
On 02/12/2014 07:05 AM, Wang Weijun wrote:
This line does not compile
Files.list(Paths.get("/secret")).forEach(x -> Files.write(x, new
byte[Files.size(x)]);
because Files.write() and Files.size() throw IOE. Then what's the best way to
make it work?
(I find some old threads on this on lam
On 2/12/2014 4:47 AM, Alan Bateman wrote:
On 11/02/2014 11:44, Paul Sandoz wrote:
:
Scrub it!
AFAICT it is not widely used (looking at the use of s.m.Service
static methods on grep code there are only a handful of dependent
artifacts). And the upgrade is quite easy.
I didn't see any more c
That's a quote from the serialization spec. I take it to mean, "Don't
write fields and everything might go to hell". In practice, if the
reading side doesn't read fields, things end up more or less OK, as
evidenced by various classes in the wild. But it's not hard to imagine
a scenario in wh
On 02/12/2014 04:47 AM, Alan Bateman wrote:
On 11/02/2014 11:44, Paul Sandoz wrote:
:
Scrub it!
AFAICT it is not widely used (looking at the use of s.m.Service
static methods on grep code there are only a handful of dependent
artifacts). And the upgrade is quite easy.
I didn't see any more
David, others?
I'm afraid I'm still not clear what is mean by:
" ... undefined in cases where the ObjectInputStream cannot resolve
the class which defined the writeObject method in question."
This does not seem directly related to the issue we are discussing (
whether to invoke default re
This line does not compile
Files.list(Paths.get("/secret")).forEach(x -> Files.write(x, new
byte[Files.size(x)]);
because Files.write() and Files.size() throw IOE. Then what's the best way to
make it work?
(I find some old threads on this on lambda-dev. Maybe we have a recommended way
now?)
Hi,
Please review two suggested fixes for
https://bugs.openjdk.java.net/browse/JDK-8031563
Root cause: selectNow is called right after 50 milliseconds sleep in
write1 method which may not be sufficient to make the socket channel
readable in some situation. Since selectNow called only once and
+1
On Feb 12, 2014, at 8:19 AM, Alan Bateman wrote:
>
> I need a reviewer for a trivial change to remove a tiny number of unused
> imports. The motive is experimental compilation of the JDK as modules rather
> than one big compilation unit. I've no doubt that there is other code that
> has un
On 2/12/14 2:19 PM, Alan Bateman wrote:
I need a reviewer for a trivial change to remove a tiny number of unused
imports. The motive is experimental compilation of the JDK as modules
rather than one big compilation unit. I've no doubt that there is other
code that has unused imports but it's not
+1
-Sundar
On Wednesday 12 February 2014 06:49 PM, Alan Bateman wrote:
I need a reviewer for a trivial change to remove a tiny number of
unused imports. The motive is experimental compilation of the JDK as
modules rather than one big compilation unit. I've no doubt that there
is other code
Looks good to me Alan.
-Chris.
On 12/02/14 13:19, Alan Bateman wrote:
I need a reviewer for a trivial change to remove a tiny number of unused
imports. The motive is experimental compilation of the JDK as modules
rather than one big compilation unit. I've no doubt that there is other
code that
++1
-Chris.
On 12/02/14 13:15, Lance Andersen wrote:
+1
On Feb 12, 2014, at 7:47 AM, Alan Bateman wrote:
On 11/02/2014 11:44, Paul Sandoz wrote:
:
Scrub it!
AFAICT it is not widely used (looking at the use of s.m.Service static methods
on grep code there are only a handful of dependent ar
I need a reviewer for a trivial change to remove a tiny number of unused
imports. The motive is experimental compilation of the JDK as modules
rather than one big compilation unit. I've no doubt that there is other
code that has unused imports but it's not the goal of this exercise to
identif
+1
On Feb 12, 2014, at 7:47 AM, Alan Bateman wrote:
> On 11/02/2014 11:44, Paul Sandoz wrote:
>> :
>> Scrub it!
>>
>> AFAICT it is not widely used (looking at the use of s.m.Service static
>> methods on grep code there are only a handful of dependent artifacts). And
>> the upgrade is quite eas
On 02/10/2014 05:36 PM, Alan Bateman wrote:
A minor comment on test/java/net/URLPermission/nstest/lookup.sh is
that the resulting line length is 182 characters and this will likely
be annoying for future side-by-side views. So I think I'd split this
while you are there.
Please review the updat
Looks good.
-Sundar
On Wednesday 12 February 2014 06:17 PM, Alan Bateman wrote:
On 11/02/2014 11:44, Paul Sandoz wrote:
:
Scrub it!
AFAICT it is not widely used (looking at the use of s.m.Service
static methods on grep code there are only a handful of dependent
artifacts). And the upgrade i
On 11/02/2014 11:44, Paul Sandoz wrote:
:
Scrub it!
AFAICT it is not widely used (looking at the use of s.m.Service static methods
on grep code there are only a handful of dependent artifacts). And the upgrade
is quite easy.
I didn't see any more comments on this and I agree there isn't much
On 02/11/2014 09:46 PM, Martin Buchholz wrote:
> On Mon, Feb 10, 2014 at 3:43 PM, Mike Duigou wrote:
>
>> On Feb 10 2014, at 04:33 , Doug Lea wrote:
>>
>>> Among the constraints on solution is that several of these
>>> methods compile down to no-ops on many common platforms.
>>
>> This is interp
36 matches
Mail list logo