On 27 Dec 2012, at 00:31, Weijun Wang weijun.w...@oracle.com wrote:
The code changes look fine.
+1. Nice to see warnings being cleaned up.
-Chris
Thanks
Max
On 12/27/2012 07:06 AM, Joe Wang wrote:
Hi,
This is a patch to clean up compiling warnings in jaxp.
Bug:
On 12/27/2012 12:06 AM, Joe Wang wrote:
Hi,
This is a patch to clean up compiling warnings in jaxp.
Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473
Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005473/webrev/
Thanks,
Joe
Hi Joe,
Method method = clazz.getMethod(DOM_LEVEL3_METHOD);
is
Thanks all!
I've updated the webrev with Remi's suggestion.
-Joe
On 12/27/2012 5:25 AM, Remi Forax wrote:
On 12/27/2012 12:06 AM, Joe Wang wrote:
Hi,
This is a patch to clean up compiling warnings in jaxp.
Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473
Webrev:
Am 22.12.2012 00:38, schrieb Mandy Chung:
Ulf,
I actually prefer the current way, a separate implementation of the process method for each option
rather than having a single big switch on enum constants. I wrote my implementation of the
handleOptions method (the previous version is copied
Henry,
Please don't apply this patch. This patch and the suggested workarounds are
still an anti-pattern of the logging API. You don't want to encourage this
type of on the fly message construction because it can't be localized. Even
Netbeans has a code hint to undo this pattern
Looks very like dumb inlined java.util.Random?
Is there a security threat to use ThreadLocalRandom instead there?
-Aleksey.
On 27.12.2012, at 23:16, Zhong Yu zhong.j...@gmail.com wrote:
Reported by the SO question
http://stackoverflow.com/questions/14010906
the HashMap constructor
It looks like its just generating a unique random seed for each HashMap. It
seems like that could be made thread-local.
On Dec 27, 2012, at 2:16 PM, Zhong Yu zhong.j...@gmail.com wrote:
Reported by the SO question
http://stackoverflow.com/questions/14010906
the HashMap constructor
I am responding on the StackOverflow thread. I will look into using
ThreadLocalRandom.
The random.next() is clearly a potential bottleneck but given that this happens
only once per HashMap instance it is still unclear why a reasonable application
would want to create hundreds or thousands of
Transient HashMaps allocated on demand are actually quite often in user code. I
think at large enough machine you will hit the coherence wall much sooner than
the allocation wall. Pity I missed to review that code long before. Please let
me know if you need help figuring out another solution.
On Thu, Dec 27, 2012 at 1:55 PM, Mike Duigou mike.dui...@oracle.com wrote:
I am responding on the StackOverflow thread. I will look into using
ThreadLocalRandom.
The random.next() is clearly a potential bottleneck but given that this
happens only once per HashMap instance it is still
I think a significant fraction of the community would disagree with you.
We ran a survey where we collected suggestions for lambdafying API
methods, and this one came in top of the list.
There is a significant fraction of the developer community that uses the
logging API and doesn't care at
Method method = clazz.getMethod(DOM_LEVEL3_METHOD);
is equivalent to
Method method = clazz.getMethod(DOM_LEVEL3_METHOD, new Class?[0]);
so you allocate an empty array each time you call getMethod.
A better patch is to cast null to Class?[] (or Object[] for invoke)
Method method =
Changeset: 9d984ccd17fc
Author:chegar
Date: 2012-12-27 21:55 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d984ccd17fc
8003981: Support Parallel Array Sorting - JEP 103
Reviewed-by: chegar, forax, dholmes, dl
Contributed-by: david.hol...@oracle.com, d...@cs.oswego.edu,
On 12/27/2012 10:41 PM, Chris Hegarty wrote:
Method method = clazz.getMethod(DOM_LEVEL3_METHOD);
is equivalent to
Method method = clazz.getMethod(DOM_LEVEL3_METHOD, new Class?[0]);
so you allocate an empty array each time you call getMethod.
A better patch is to cast null to Class?[] (or
On 27 Dec 2012, at 22:26, Remi Forax fo...@univ-mlv.fr wrote:
On 12/27/2012 10:41 PM, Chris Hegarty wrote:
Method method = clazz.getMethod(DOM_LEVEL3_METHOD);
is equivalent to
Method method = clazz.getMethod(DOM_LEVEL3_METHOD, new Class?[0]);
so you allocate an empty array each time you
Brian,
It's on my list too for lambdafying I just disagree with current
implementation. I understand and agree that having to create a guard should
not be required. It's awful to have to do. The point is that patch is still
way too eager because you don't want to evaluate a message
What about the following API:
public class LogRecordFactory {
private final Level level;
public LogRecordFactory(Level level) {
this.level = level;
}
public LogRecord create(String msg) {
return new LogRecord(level, msg);
}
public LogRecord
And to save creation of a helper object, LogRecordFactory could be an
interface implemented by LogRecord...
Peter
On 12/28/2012 01:42 AM, Peter Levart wrote:
What about the following API:
public class LogRecordFactory {
private final Level level;
public LogRecordFactory(Level
Changeset: d4aea0225e80
Author:joehw
Date: 2012-12-27 18:17 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d4aea0225e80
8005473: Warnings compiling jaxp
Summary: clean up compiling warnings.
Reviewed-by: weijun, chegar, forax
!
As stated in the beginning of the review thread, the reason we don't have
Supplier version for other API is that a formatter is involved and can achieve
same laziness easily.
The key is MessageFormatter can take arguments, which will be used to generate
the output. As there is no directly
Changeset: 4ad38db38fff
Author:okutsu
Date: 2012-12-28 14:13 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad38db38fff
8005471: DateFormat: Time zone info is not localized when adapter is CLDR
Reviewed-by: peytoia
!
Changeset: 1da019e7999a
Author:peytoia
Date: 2012-12-28 15:07 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1da019e7999a
8005277: Regression in JDK 7 in Bidi implementation
Reviewed-by: okutsu
! src/share/classes/sun/text/bidi/BidiBase.java
!
Changeset: f3ac419e2bf0
Author:okutsu
Date: 2012-12-28 16:39 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3ac419e2bf0
8005561: typo in Calendar
Reviewed-by: peytoia
! src/share/classes/java/util/Calendar.java
23 matches
Mail list logo
