On 02/13/2014 10:26 PM, roger riggs wrote:
Having folks stumbling over process creation and problems of quoting,
especially on windows, it seems useful to log the native commands and
arguments.
They are proposed to be logged using the PlatformLogger at Level.FINE
which will not be logged by
On 14/02/2014 10:26, Florian Weimer wrote:
It may make sense to expose something like getProcessID() to the
public because it is independently useful on systems with /proc.
Yes, this has been asked for many times. We have JEP 102 [1] that lists
this and other Process topics that we'd like to
Hi Roger,
I agree with Paul that using Objects.toString(environment) would be
cleaner.
Concerning the test, you may want to modify CheckHandler.publish to
filter out any log record that doesn't come from your ProcessImpl
classes. Something like:
175 @Override
176 public void
Approved for pushing to jdk8u-dev.
regards,
Sean.
On 14/02/14 01:38, Phil Race wrote:
Yeah sorry about that. It built on Windows and Mac but not Linux as i
found out today.
-phil.
On 2/13/14 5:36 PM, Mandy Chung wrote:
Looks good. Sorry I didn't catch this earlier and I was counting on
I'm sure there was a discussion somewhere in JDK mailing lists, but I couldn't
find. Please, give me a link.
I've tried to ask on SO:
http://stackoverflow.com/questions/21758081/why-many-methods-in-jcf-interfaces-not-made-default-in-java-8,
proved that JDK developers don't read SO :)
On Feb 14, 2014, at 2:13 PM, Roman Leventov leven...@ya.ru wrote:
I'm sure there was a discussion somewhere in JDK mailing lists, but I
couldn't find. Please, give me a link.
I cannot recall such discussion.
Generally we have only converted existing abstract methods on an interface to
On 02/13/2014 11:38 AM, David M. Lloyd wrote:
On 02/13/2014 10:29 AM, Chris Hegarty wrote:
On 12 Feb 2014, at 15:24, David M. Lloyd david.ll...@redhat.com
wrote:
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,
Thanks Paul, Daniel,
Thanks for the suggestions, I updated the webrev.
/othervm does seem to be needed to prevent this test from interfering or
being interfered wit.
Roger
On 2/14/2014 6:06 AM, Daniel Fuchs wrote:
Hi Roger,
I agree with Paul that using Objects.toString(environment) would
Hi Florian,
As for escaping, is there an existing API for encoding and decoding those?
A human won't have trouble figuring out the few cases where there might be
some ambiguity due to , in the string.
The test will be more complicated as well and I think added that the
extra complexity
is not
Hi David,
I would quibble that the serialized form of java.util.Date is defined.
The behavior is defined by the writeObject and readObject methods.
They write and read a time computed from and restored to the state of
the object.
Roger
On 2/14/2014 10:56 AM, David M. Lloyd wrote:
On
On 14/02/14 15:56, David M. Lloyd wrote:
On 02/13/2014 11:38 AM, David M. Lloyd wrote:
On 02/13/2014 10:29 AM, Chris Hegarty wrote:
On 12 Feb 2014, at 15:24, David M. Lloyd david.ll...@redhat.com
wrote:
That's a quote from the serialization spec. I take it to mean,
Don't write fields and
On 14/02/14 16:31, roger riggs wrote:
Hi David,
I would quibble that the serialized form of java.util.Date is defined.
The behavior is defined by the writeObject and readObject methods.
They write and read a time computed from and restored to the state of
the object.
Yes, but it falls foul if
Hi All,
I added a SerializationTest. The test contains a helper that can
generate serialization files for XMLGregorianCalendar and Duration. I've
created such files for jdk6,7,8 and 9, and manually run the test, that
is, read them back with JDK6, 7, 8 and 9. The test worked fine. In the
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8034853/webrev.1/
The change is to remove the class sun.misc.ClassLoaderUtil.
The functionality provided by this class is now in the public
java.net.URLClassloader.close() method.
Thanks
Michael
On 02/14/2014 09:56 AM, David M. Lloyd wrote:
On 02/13/2014 11:38 AM, David M. Lloyd wrote:
On 02/13/2014 10:29 AM, Chris Hegarty wrote:
On 12 Feb 2014, at 15:24, David M. Lloyd david.ll...@redhat.com
wrote:
That's a quote from the serialization spec. I take it to mean,
Don't write fields
Yes, however given that the lack of reading/writing fields makes it
undefined *in general*, you can only say the behavior is defined as
long as this undefined behavior is actually defined in this (risky) manner.
Put another way, since the behavior of not reading/writing fields is not
defined,
Hi Michael,
Good to see more of sun.misc go away :-)
For the test, I recommend updating the @summary and removing the comment
about the old API.
Thanks,
-Joe
On 02/14/2014 09:42 AM, Michael McMahon wrote:
Could I get the following change reviewed please?
Thanks Joe. Will do that.
Michael
On 14/02/14 18:09, Joe Darcy wrote:
Hi Michael,
Good to see more of sun.misc go away :-)
For the test, I recommend updating the @summary and removing the
comment about the old API.
Thanks,
-Joe
On 02/14/2014 09:42 AM, Michael McMahon wrote:
Could I get
On 14/02/2014 17:42, Michael McMahon wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8034853/webrev.1/
The change is to remove the class sun.misc.ClassLoaderUtil.
The functionality provided by this class is now in the public
On 14/02/14 18:20, Alan Bateman wrote:
On 14/02/2014 17:42, Michael McMahon wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8034853/webrev.1/
The change is to remove the class sun.misc.ClassLoaderUtil.
The functionality provided by this class is
Interestingly, if the behavior in this case was to write empty values on
the write side and read and discard on the read side, both the behavior
and the serialized format of java.util.Date would be identical to today;
though other pathological classes might be incompatible, they were
already
Looks good.
-Chris.
On 14 Feb 2014, at 17:42, Michael McMahon michael.x.mcma...@oracle.com
wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8034853/webrev.1/
The change is to remove the class sun.misc.ClassLoaderUtil.
The functionality
Hello!
May I please have a review of the fix?
It's not meant to be a proof reading, I only fixed some obvious typos.
Some of them were reported at the time of java 1.4, so it is probably
the time to have them fixed.
BUG: https://bugs.openjdk.java.net/browse/JDK-4682009
WEBREV:
Looks fine. assume the code/code will be addressed as part of a full sweep
of javax/naming
On Feb 14, 2014, at 2:48 PM, Ivan Gerasimov wrote:
Hello!
May I please have a review of the fix?
It's not meant to be a proof reading, I only fixed some obvious typos.
Some of them were reported
On 14/02/2014 18:10, Martin Buchholz wrote:
I'm not excited about having logging statements added throughout the jdk
implementation. PlatformLogger is an implementation detail, so real users
cannot benefit. Your OS should already provide facilities to let you trace
process creation. E.g. on
On 14/02/2014 18:31, Michael McMahon wrote:
I think I'd probably just delete the test since URLClassLoader.close
has its own tests,
I thought it might be useful as a point of reference
in case there could be someone still using the sun.misc API.
Also, I think mercurial won't delete the empty
On 14/02/2014 19:48, Ivan Gerasimov wrote:
Hello!
May I please have a review of the fix?
It's not meant to be a proof reading, I only fixed some obvious typos.
Some of them were reported at the time of java 1.4, so it is probably
the time to have them fixed.
BUG:
On 15.02.2014 0:13, Lance Andersen - Oracle wrote:
Looks fine. assume the code/code will be addressed as part of a full sweep
of javax/naming
On Feb 14, 2014, at 2:48 PM, Ivan Gerasimov wrote:
Thanks!
Yes, I didn't touch formatting, only typos.
Hello!
May I please have a review of the
On 2/14/14 10:31 AM, Michael McMahon wrote:
On 14/02/14 18:20, Alan Bateman wrote:
On 14/02/2014 17:42, Michael McMahon wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8034853/webrev.1/
The change is to remove the class sun.misc.ClassLoaderUtil.
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
Hi Tristan,
OK, we're getting close. Just a couple things about ShutdownGracefully.java.
It's a bit clumsy to have both a boolean and a message string to keep track of
the state of the test, but by itself this isn't such a big deal.
A bigger deal is the lack of exception chaining. If we
Thank you Stuart
This is nice. I thought two variables were weird 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.
32 matches
Mail list logo
