I am still wondering if we need some sort of javadoc tag for default
implementations so that it will stand out better and allow us to be consistent
with how we specify this across Java SE and other APIs that leverage default
methods.
Has any thought been given to this?
Best
Lance
On Dec 5,
Java 7 introduced support for parallel classloading by adding to each
class loader a ConcurrentHashMap, referenced through a new field,
parallelLockMap. This contains a mapping from class names to Objects to
use as a classloading lock for that class name. This scheme has a number
of
On 12/5/12 3:45 PM, Alan Bateman wrote:
On 04/12/2012 15:55, Daniel Fuchs wrote:
So that would be the wording:
* Uses the service-provider loading facilities, defined by the
* {@link java.util.ServiceLoader} class, to attempt to locate
* and load an implementation of the
On 05/12/2012 14:56, Daniel Fuchs wrote:
Or maybe:
Otherwise, the default implementation, if present, is returned ?
I think the original intent was to make provision for the case where
the implementation module would not be installed
That is longer term intent, meaning when we go do
On 04/12/2012 20:15, Mandy Chung wrote:
Alan - thanks for the feedback. I have made several changes to the
jdeps tool. Here is the new webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003562/langtools-webrev.01/
I'll send out a formal code review request once I add the new unit
Hi,
Please find below a revised version of the changes for
the javax.xml.parsers package.
It hopefully incorporates all comments I have received so far.
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parsers/webrev.01/
* better wording/formating for Javadoc changes
* using for( : )
Thanks for the suggestions, Stuart. BTW printStackTrace() prints to
standard error by default -- that's why I don't explicitly have it in there.
Cheers,
Jim
On 12/04/2012 07:06 PM, Stuart Marks wrote:
Hi Jim,
(Looks like you're cleaning up warnings along the way. I guess that's
OK.)
On Dec 4 2012, at 22:10 , David Holmes wrote:
Hi Mike,
In multiple places:
+ * p/xxx ...
Should that be p tag? Is it actually needed? (my javadoc is a bit rusty).
Many of these were added/changed by NetBeans styler. I then added additional
instances. I have converted all of the p/ -
Hi Daniel,
Looks good to me!
-Joe
On 12/5/2012 8:17 AM, Daniel Fuchs wrote:
Hi,
Please find below a revised version of the changes for
the javax.xml.parsers package.
It hopefully incorporates all comments I have received so far.
A while back [1], I brought up the issue of the Properties
storeToXML/loadFromXML methods being problematic for our efforts to
modularize the JDK and also the Compact Profiles effort. At the time I
mentioned that we were thinking of including a small footprint XML
parser that we could use in
This patch adds a constructor to ThreadLocal to supply initial values
using the new Supplier functional interface. Please review. This work
was done by Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
Thanks
On 12/5/12 8:41 AM, Jim Gish wrote:
BTW printStackTrace() prints to standard error by default -- that's why I don't
explicitly have it in there.
Oh yes, so it does. Sorry, I was confused.
s'marks
Looks good to me.
Mike
On Dec 5 2012, at 11:39 , Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values using
the new Supplier functional interface. Please review. This work was done by
Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
On 12/05/12 14:39, Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values using the
new Supplier functional interface. Please review. This work was done by Jim
Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
On 12/05/2012 08:51 PM, Doug Lea wrote:
On 12/05/12 14:39, Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values
using the
new Supplier functional interface. Please review. This work was done
by Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
Here's a new version for your consideration :-)
http://cr.openjdk.java.net/~jgish/Bug8004317-TestLibrary-getUnusedRandomPort-Failure/
http://cr.openjdk.java.net/%7Ejgish/Bug8004317-TestLibrary-getUnusedRandomPort-Failure/
Thanks,
Jim
On 12/05/2012 02:45 PM, Stuart Marks wrote:
On 12/5/12
Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/
- delegate to Math.min/max for int/long/float/double
- rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor
- removed Character variants of min/max/sum
On 12/02/2012 05:50 PM, David Holmes wrote:
Hi Akhil,
Is it really
Regarding Character methods; it's unorthodox but some people use them as
fake unsigned shorts. Whether that's enough to justify adding
sum/max/min, I don't know.
Sent from my phone
On Dec 5, 2012 4:28 PM, Akhil Arora akhil.ar...@oracle.com wrote:
Updated -
Hi Daniel,
Looks good to me. One question - the last bullet in the search order
covers the default implementation case:
Platform default codeDocumentBuilderFactory/code instance.
Would it make sense to merge the statement Otherwise, the default
implementation, if present, is returned with
Yeah, this is a great tool.
Does it also help to find the need to recompile a class if the source of a inlined referred static
final constant has changed?
-Ulf
Am 28.11.2012 00:18, schrieb Mandy Chung:
As part of prepare for modules [1], this RFE is to provide a command-line tool in JDK8 so
A fix for intermittent test failures causing grief on Windows, particularly
Windows 7 and 2008 systems:
http://cr.openjdk.java.net/~ddehaven/8004042/webrev.1/
The underlying cause is as of yet unknown, but I was able to create an
environment that caused similar failures by running watch -n 0.2
Akhil,
In javadoc like this
298 * as {@code BinaryOperatorlt;Booleangt;}.
you don't have to use lt; and the like inside {@code}; please change to
298 * as {@code BinaryOperatorBoolean}.
As a general comment, if the operations for primitive type Foo are put
into java.lang.Foo, then
OK, looks better, more explicit so that we can find out why this is failing.
There's still a subtle issue in the reporting though. Consider if on attempt N
the ServerSocket call gets a valid port but it's one of the reserved ports.
Then, unusedRandomPort will be = 0 and isReservedPort() will
Thanks Stuart. Sure - go ahead and make the change and do the push.
Maybe we'll get lucky with the nightlies!
Thanks again,
Jim
On 12/05/2012 06:54 PM, Stuart Marks wrote:
OK, looks better, more explicit so that we can find out why this is
failing.
There's still a subtle issue in the
This review request (add a new jdeps tool in the JDK) include changes in
langtools and the jdk build. I would need reviewers from the langtools
and the build-infra team.
Webrev for review:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/langtools-webrev.02/
On 6/12/2012 5:39 AM, Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values
using the new Supplier functional interface. Please review. This work
was done by Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
Changeset: a971516029ab
Author:jgish
Date: 2012-12-05 21:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a971516029ab
8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception
not reported
Reviewed-by: alanb, dmocek, smarks
!
Pushed:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a971516029ab
I couldn't resist doing a couple more fixups. (Man, there is a lot more
cleaning up that could be done in here.)
I don't know if I got this in time for tonight's nightly. Well, get it in there
and see if it falls over sooner or
On 12/5/12 2:44 PM, David DeHaven wrote:
A fix for intermittent test failures causing grief on Windows, particularly
Windows 7 and 2008 systems:
http://cr.openjdk.java.net/~ddehaven/8004042/webrev.1/
The underlying cause is as of yet unknown, but I was able to create an environment that
On 6/12/2012 4:20 AM, Mike Duigou wrote:
I have updated webrev again to fix some reported javadoc technical issues and
added null handling specification to the {Int|Double|Long}Supplier.
http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/
Hi,
This update reflect changes based on feedbacks for last version, the
changes are
- rename reverse() to reverseOrder()
- rename Comparator.compose to Comparator.thenComparing
- add 4 Comparator.thenComparing methods take [Int|Long|Double]Function
to enable fluent syntax like this example,
31 matches
Mail list logo
