Adding core-libs as this is actually a launcher change.
David
On 21/05/2013 4:36 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
http://bugs.sun.com/view_bug.do?bug_id=8009911
The webrev is available at:
http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/
The
Changeset: 37b73984640a
Author:joehw
Date: 2013-05-20 23:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/37b73984640a
8012683: Remove unused, obsolete ObjectFactory classes
Reviewed-by: lancea
- src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java
- src/com/
On 21/05/2013 4:32 PM, Florian Weimer wrote:
On 05/21/2013 07:07 AM, Mike Duigou wrote:
Since the char array is never modified it could use the String(char[],
boolean) constructor. This has advantages for cases such as logging
which may read the thread name very many times.
Couldn't we store t
On 05/21/2013 07:07 AM, Mike Duigou wrote:
Since the char array is never modified it could use the String(char[], boolean)
constructor. This has advantages for cases such as logging which may read the
thread name very many times.
Couldn't we store the original string instead?
--
Florian Weim
Approved.
-Joe
On 05/20/2013 10:02 PM, David Holmes wrote:
Anybody? :(
David
On 20/05/2013 12:06 PM, David Holmes wrote:
The contents of the ARM jvm.cfg were put in place for the SE Embedded
product, but for the SE ARM implementation we want to enable ergonomics,
as we do on other platforms
Looks good.
Since the char array is never modified it could use the String(char[], boolean)
constructor. This has advantages for cases such as logging which may read the
thread name very many times.
Mike
On May 18 2013, at 00:57 , Chris Hegarty wrote:
> Thread getName and setName are not thre
Anybody? :(
David
On 20/05/2013 12:06 PM, David Holmes wrote:
The contents of the ARM jvm.cfg were put in place for the SE Embedded
product, but for the SE ARM implementation we want to enable ergonomics,
as we do on other platforms.
http://cr.openjdk.java.net/~dholmes/8014857/webrev/
--- ol
No surprise it is a thumbs up from me :)
Thanks,
David
On 18/05/2013 5:57 PM, Chris Hegarty wrote:
Thread getName and setName are not thread-safe. The "expected" usage is
to set a name before starting the thread and only read it thereafter.
It is desirable to support the setting of thread name
On 5/16/13 5:52 PM, Xuelei Fan wrote:
On 5/16/2013 5:22 PM, Weijun Wang wrote:
Hi Xuelei
I'm busy on something else, so probably have no time (or cannot
concentrate) to read in details.
Not urgent fix, so please review these request only when you available.
In my opinion, there are severa
So I propose to push ahead with this fix in my offered form.
I still need an official Review to do so, or else objections against the
proposal.
Thanks,
David
On 20/05/2013 10:17 PM, David Holmes wrote:
On 20/05/2013 5:44 PM, David Holmes wrote:
On 20/05/2013 4:25 PM, Martin Buchholz wrote:
Hi Remi,
On 5/20/2013 2:28 PM, Remi Forax wrote:
On 05/20/2013 11:10 PM, Joe Darcy wrote:
Hello,
Please review the patch below which implements
8014836: Have GenericDeclaration extend AnnotatedElement
All the existing implementations of GenericDeclaration in the JDK
already implement An
On Mon, May 20, 2013 at 5:30 PM, David Holmes wrote:
> On 21/05/2013 3:55 AM, Martin Buchholz wrote:
>
>> This is __the__ fundamental question of whether to add
>> CharSequence.getChars at all.
>>
>> If none of the objects in the jdk can trust any of the others, they will
>> spend all of their tim
Hi,
Please review this change to fix 718655. The bug complaints about continuous BackingStoreExceptions
printed on the console, the user is just seeing logged warnings from
BackingStoreExceptions raised in periodic attempts to sync
preferences. Preferences use sun.util.logging.PlatformLog
On 21/05/2013 3:45 AM, Alan Bateman wrote:
On 20/05/2013 14:49, David Chase wrote:
Suppose I split this bug (i.e., file a new bug) into the
Intel-acceleration part and the fork-join part.
:
This make sense.
I agree.
I also don't have an issue with eliding the optimization on Windows for
th
On 21/05/2013 3:55 AM, Martin Buchholz wrote:
This is __the__ fundamental question of whether to add
CharSequence.getChars at all.
If none of the objects in the jdk can trust any of the others, they will
spend all of their time making defensive copies and unmodifiable wrappers.
But you are not
+1
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
On May 20, 2013, at 7:26 PM, huizhe wang wrote:
> Hi,
>
> This is a quick fix to remove a copy of obsolete ObjectF
Hi,
This is a quick fix to remove a copy of obsolete ObjectFactory classes.
They should have been removed in a previous consolidation work (7053556)
but were mistakenly kept in the repo.
http://cr.openjdk.java.net/~joehw/jdk8/8012683/webrev/
Thanks,
Joe
Changeset: a7cec93e4682
Author:joehw
Date: 2013-05-20 16:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a7cec93e4682
8014891: Redundant setting of external access properties in setFeatures
Reviewed-by: lancea
! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderI
Thanks!
On 5/20/2013 2:59 PM, Lance Andersen - Oracle wrote:
looks fine Joe
On May 20, 2013, at 4:15 PM, huizhe wang wrote:
Hi,
This is a patch to remove redundant property settings. In the previous patch,
the new jaxp properties were set while copying features onto DOM/SAX parsers.
However
looks fine Joe
On May 20, 2013, at 4:15 PM, huizhe wang wrote:
> Hi,
>
> This is a patch to remove redundant property settings. In the previous patch,
> the new jaxp properties were set while copying features onto DOM/SAX parsers.
> However, this is already done during the initialization of DOM
On 05/20/2013 11:10 PM, Joe Darcy wrote:
Hello,
Please review the patch below which implements
8014836: Have GenericDeclaration extend AnnotatedElement
All the existing implementations of GenericDeclaration in the JDK
already implement AnnotatedElement. Some code in java.lang.Class
neede
Hello,
Please review the patch below which implements
8014836: Have GenericDeclaration extend AnnotatedElement
All the existing implementations of GenericDeclaration in the JDK
already implement AnnotatedElement. Some code in java.lang.Class needed
to be adjusted slightly since AnnotatedE
Hi,
This is a patch to remove redundant property settings. In the previous
patch, the new jaxp properties were set while copying features onto
DOM/SAX parsers. However, this is already done during the initialization
of DOM/SAX parsers (before setFeatures is called). It was removed in the
stan
Changeset: 6a9148865139
Author:sherman
Date: 2013-05-20 11:56 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a9148865139
8004789: (zipfs) zip provider doesn't work correctly with file systems
providers rather than the default
Summary: to use Files.createTempFile(...) to cre
Thought I sent this last week but it was saved in Drafts …
On May 16, 2013, at 10:48 PM, Alan Eliasen wrote:
> Yes, the extreme examples are ones like in the original bug report,
> which are literally millions of times faster. If the base contains a
> power of 2, (which is by far the most comm
This is __the__ fundamental question of whether to add
CharSequence.getChars at all.
If none of the objects in the jdk can trust any of the others, they will
spend all of their time making defensive copies and unmodifiable wrappers.
This is the reverse side of whether you can trust any collection
On 20/05/2013 14:49, David Chase wrote:
Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration
part and the fork-join part.
:
This make sense.
-Alan.
PS, the code generated by Visual Studio 2012 from the C version of the source
is nowhere near
as good as what comes from gcc 2.6 or clang. Getting good code would require
hand conversion
of 80 lines of assembler to the microsoft dialect, never mind the calling
conventions.
That suggests disabl
On 2013-05-20, at 11:28 AM, Vladimir Kozlov wrote:
> On 5/20/13 6:49 AM, David Chase wrote:
>> Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration
>> part and the fork-join part.
>
> Yes, please, do that.
And, before I waste more time tearing my hair out, suppose that
On 5/20/13 6:49 AM, David Chase wrote:
Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration
part and the fork-join part.
Yes, please, do that.
Does that makes this a hair easier? It will still contain the assembly
language, and I am still attempting to get anywhere
More ProblemList updates to remove three tests, the related issues have
been fixed.
Please review:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8014892/webrev/index.html
Thanks,
Changeset: 80d4db063d5a
Author:jlaskey
Date: 2013-05-14 11:15 -0300
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/80d4db063d5a
8014512: Exclude testing and infrastructure packages from code coverage
Reviewed-by: sundar
Contributed-by: james.las...@oracle.com
! make/code_cover
Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration
part and the fork-join part.
Does that makes this a hair easier? It will still contain the assembly
language, and I am still attempting to get anywhere at all on Windows (our
official instructions don't work, largely b
On 20/05/2013 5:44 PM, David Holmes wrote:
On 20/05/2013 4:25 PM, Martin Buchholz wrote:
Note that my pending change
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/getChars.patch
does the same kind of thing, but without recursive lock acquisitions.
I will take a look.
So it lo
Hi Martin,
I took a look at this in relation to the other StringBuffer bugs.
I have a concern. Looking at this:
@@ -453,12 +438,11 @@
public AbstractStringBuilder append(CharSequence s) {
if (s == null)
return appendNull();
-if (s instanceof String)
-
On 2013-05-20, at 3:33 AM, Alan Bateman wrote:
> I think we need to get more experience with parallel operations before
> considering changing the default behavior of long standing methods. This it
> why I am suggesting this should be opt-in, meaning you run with something
> like -Djdk.enable
On 05/09/2013 02:30 AM, Mike Duigou wrote:
Hi Martin;
Some notes from a non-exhaustive (ran out of time before dinner) review.
Mike
AbstractStringBuilder::
- The impls like insert(int dstOffset, CharSequence s) makes me slightly uneasy
because the private value field escapes to an unknown cl
On 20/05/2013 4:25 PM, Martin Buchholz wrote:
Note that my pending change
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/getChars.patch
does the same kind of thing, but without recursive lock acquisitions.
I will take a look.
I'm curious why a recursive lock acquisition would be
On 20/05/2013 02:24, David Chase wrote:
:
I don't like this approach for several reasons.
First, we're not done finding places that fork-join parallelism can make things go faster. If, each time we
find a new one, we must split it into the parallel and serial versions, we're going to get a ti
On 05/20/2013 09:16 AM, Peter Levart wrote:
On 05/20/2013 07:48 AM, David Holmes wrote:
The change put through for JDK-8013395 (StringBuffer toString cache)
has exposed a previously unnoticed bug in the
StringBuffer.append(CharSequence cs) method. That method claimed to
achieve synchronization
On 05/20/2013 07:48 AM, David Holmes wrote:
The change put through for JDK-8013395 (StringBuffer toString cache)
has exposed a previously unnoticed bug in the
StringBuffer.append(CharSequence cs) method. That method claimed to
achieve synchronization (and then correct toStringCache behaviour) b
41 matches
Mail list logo
