On 27 Dec 2012, at 00:31, Weijun Wang 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: http://bugs.sun.com/vie
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: http://cr.openjdk.java.ne
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 fr
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 tha
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 wrote:
> Reported by the SO question
>
>http://stackoverflow.com/questions/14010906
>
> the HashMap constructor contains a CAS, whi
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 wrote:
> Reported by the SO question
>
>http://stackoverflow.com/questions/14010906
>
> the HashMap constructor contains a CAS, wh
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 ha
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 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 unclear why a reasonable
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 a
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 = clazz.getMethod(
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,
chr
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 Object[
On 27 Dec 2012, at 22:26, Remi Forax 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 c
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 u
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 create(Strin
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 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
! src/com/sun/org/apache/xalan/internal/xslt/Env
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 suppo
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
! src/share/classes/sun/util/resources/TimeZoneNamesBundle.
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
! test/java/text/Bidi/BidiConform
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
