Thanks for the comments Alan…
On 30 Jan 2015, at 14:32, Alan Bateman alan.bate...@oracle.com wrote:
On 30/01/2015 13:36, Chris Hegarty wrote:
This is phase 1, of getting java.net.URL work with modules.
Being able to effectively specify URL protocol handler factories as fully
qualified
Please review this clarification to the optional behavior of
java.lang.Runtime and java.lang.ProcessBuilder
on platforms that don't support process creation.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-8055330/
Issue:
8055330 https://bugs.openjdk.java.net/browse/JDK-8055330
On 01/29/2015 12:44 PM, Brent Christian wrote:
Hi,
I ran my updated test through our automated testing system, and it
failed *on Windows only*. The toURI() call I added came back with an
AccessControlException due to not being able to read the test.classes
directory. The test uses its own
Looks good to me Roger.
-- daniel
On 30/01/15 16:58, Roger Riggs wrote:
Please review this clarification to the optional behavior of
java.lang.Runtime and java.lang.ProcessBuilder
on platforms that don't support process creation.
Webrev:
On 1/30/15 3:04 AM, Florian Weimer wrote:
On 01/27/2015 05:37 AM, 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
On 30/01/2015 15:58, Roger Riggs wrote:
Please review this clarification to the optional behavior of
java.lang.Runtime and java.lang.ProcessBuilder
on platforms that don't support process creation.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-8055330/
One suggest is to move this
Looks OK and easier to read now
Best
Lance
On Jan 30, 2015, at 5:25 PM, Roger Riggs roger.ri...@oracle.com wrote:
Please review this correction of a JapaneseEra range check in java.time.
The error was discovered during development of additional conformance tests
(to be delivered
On 30/01/2015 15:35, Chris Hegarty wrote:
:
Update webrev and spec diffs:
http://cr.openjdk.java.net/~chegar/8064924/01/
I think the javadoc looks much better now, thanks.
-Alan
On 1/30/15 2:25 PM, Roger Riggs wrote:
Please review this correction of a JapaneseEra range check in java.time.
The error was discovered during development of additional conformance
tests (to be delivered separately).
Webrev:
http://cr.openjdk.java.net/~rriggs//webrev-era-8068278
Looks
Please review this correction of a JapaneseEra range check in java.time.
The error was discovered during development of additional conformance
tests (to be delivered separately).
Webrev:
http://cr.openjdk.java.net/~rriggs//webrev-era-8068278
Issue:
Ship it :-)
On Jan 30, 2015, at 3:26 PM, Roger Riggs roger.ri...@oracle.com wrote:
Please review corrections for editorial issues in java.time javadoc.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-time-editorial-8068284/
Issues:
8062803: 'principal' should be 'principle' in
On 1/30/15 12:26 PM, Roger Riggs wrote:
Please review corrections for editorial issues in java.time javadoc.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-time-editorial-8068284/
Looks fine.
Mandy
Issues:
8062803: 'principal' should be 'principle' in java.time package
description
Hi Frank
Looks fine
best
lance
On Jan 30, 2015, at 12:59 AM, Frank Yuan frank.y...@oracle.com wrote:
Hi Lance
Changed the comment to '/*', could you have a check?
http://cr.openjdk.java.net/~fyuan/8051709/webrev.03/
Best Regards
Frank
From: Lance Andersen
Hi,
That does read better.
As in this webrev:
http://cr.openjdk.java.net/~rriggs/webrev-process-8072034/
Roger
On 1/30/2015 4:30 PM, Alan Bateman wrote:
On 30/01/2015 15:58, Roger Riggs wrote:
Please review this clarification to the optional behavior of
java.lang.Runtime and
Hi Mandy,
Thanks for the review.
I wrote the test (and it passed) but since the JCK folks are providing
the tests it seemed
undesirable to have duplicate tests.
Roger
On 1/30/2015 5:27 PM, Mandy Chung wrote:
On 1/30/15 2:25 PM, Roger Riggs wrote:
Please review this correction of a
Hello,
I was concerned about the special cases handling in javac might be
problematic and made sure to do a build before I pushed the change.
Since pushing the change yesterday, all the internal builds have been
fine so I think we are in the clear :-)
Thanks,
-Joe
On 1/30/2015 11:58 AM,
Hi
Good question, but javac should be fine. I had to look it up, but there is
logic to omit super() when generating the default ctor for Object
(TypeEnter::DefaultConstructor), and also logic for omitting super() if we are
compiling an explicit ctor for Object (Attr::visitMethodDef).
Looks
Hi Martin,
Since very few developers will care about this case, it doesn't seem
necessary to
repeat the javadoc unless consistency is more important than readability.
In Runtime, the change is in the full exec method; all of the other
exec methods are
described as convenience methods and
Please review corrections for editorial issues in java.time javadoc.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-time-editorial-8068284/
Issues:
8062803: 'principal' should be 'principle' in java.time package
description
8068285: Missing @throws in
Seems OK, but:
UOE should be specified in ProcessBuilder if and only if it is also
specified for the Runtime.exec family of methods, since they are wrappers
around ProcessBuilder.
Because there are so many methods, it may be better to have a blanket UOE
disclaimer added to the class descriptions
It often happens that some ancient thought was in my head 10 years ago, and
it takes a day or two to get paged back in.
Now I think that 10 years ago I definitely considered the possibility of an
OS that had no subprocess support at all, and I was comfortable with simply
throwing IOException,
On 1/30/15 2:33 PM, Roger Riggs wrote:
Hi Mandy,
Thanks for the review.
I wrote the test (and it passed) but since the JCK folks are providing
the tests it seemed
undesirable to have duplicate tests.
JDK developers don't run JCK tests and I think it'd be nice to have a
regression test to
On 30/01/2015 13:36, Chris Hegarty wrote:
This is phase 1, of getting java.net.URL work with modules.
Being able to effectively specify URL protocol handler factories as fully
qualified class names, through the 'java.protocol.handler.pkgs' system property
is problematic. It requires the
On 08/20/2014 06:43 PM, Andrew Haley wrote:
On 08/20/2014 04:10 PM, Florian Weimer wrote:
Is there already a way to compute the expression in the subject without
the ByteBuffer allocation? I saw quite a few equivalent formulations in
the OpenJDK sources, and perhaps it's time to add a
On 01/30/2015 01:02 AM, joe darcy wrote:
Hello,
Please review the patch below to fix
JDK-8071959: java.lang.Object uses implicit default constructor
diff -r 458adf31ad5b src/java.base/share/classes/java/lang/Object.java
--- a/src/java.base/share/classes/java/lang/Object.javaThu Jan 29
On 01/29/2015 09:53 PM, joe darcy wrote:
+ * As much as is reasonably practical, the hashCode method defined
+ * by class {@code Object} does return distinct integers for
+ * distinct objects. (The hashCode may or may not be implemented
+ * as some function of an object's
This is phase 1, of getting java.net.URL work with modules.
Being able to effectively specify URL protocol handler factories as fully
qualified class names, through the 'java.protocol.handler.pkgs' system property
is problematic. It requires the protocol handler factory implementation class
On 01/29/2015 04:38 AM, Peter Levart wrote:
*
* pIf hook or callback methods throw exceptions, internal worker
* threads may in turn fail and abruptly terminate./dd
The last paragraph could explicitly spell-out what are the callback methods.
That would be enough, I think.
Good idea;
On 01/27/2015 05:37 AM, 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 for existing applications using
Perhaps the authors in question would be happy to have a publicly hosted
snippet of that useful information? I have both books but can appreciate
that there's a *large* number of Java devs who can't afford or get access
to those.
Cheers,
Martijn
On 29 January 2015 at 21:03, Roger Riggs
30 matches
Mail list logo
