Thank you for your thorough mail. This is very educational. I took you advice
and generated a new webrev for this.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.03/
I appreciate you can review this again.
Regards
Tristan
On Feb 11, 2014, at 8:32 AM, Stuart Marks wrote:
> Hi Tristan,
>
Hi Lance, Daniel,
I suggest we take this incompatibility and document it in the release
notes (we'll likely have more). I reversed DurationImpl and then
realized why the Xerces engineers made the incompatibility change when I
started on XMLGregorianCalendarImpl. It was because
XMLGregorianCal
Thank you Stuart
http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.01/
Regards
Tristan
On Feb 12, 2014, at 10:06 AM, Stuart Marks wrote:
> Hi, yes, I'll take this one.
>
> It's slightly odd that this is creating filenames that already have "/" in
> them (as opposed to File.separator) but sin
Hi, yes, I'll take this one.
It's slightly odd that this is creating filenames that already have "/" in them
(as opposed to File.separator) but since these files don't actually have to
exist, I suppose it doesn't really matter.
I'm not convinced that we actually have any evidence that /home/~
Here's a JDk8u webrev : -http://cr.openjdk.java.net/~prr/8031737.8u/
-phil.
On 2/11/14 2:28 PM, Phil Race wrote:
So since hg export/import doesn't apply cleanly and the dependency
chain seems, long and in order to have some consistency across the
releases,
I think I should prepare a webrev wh
yes
On 2/11/2014 5:28 PM, Phil Race wrote:
So since hg export/import doesn't apply cleanly and the dependency
chain seems, long and in order to have some consistency across the
releases,
I think I should prepare a webrev which essentially backports 8031737
including its small changes to Versio
So since hg export/import doesn't apply cleanly and the dependency
chain seems, long and in order to have some consistency across the releases,
I think I should prepare a webrev which essentially backports 8031737
including its small changes to Version.c, if only because otherwise
I'd have to have
Hi Phil,
On 2/11/2014 5:09 PM, Phil Race wrote:
Are we talking about the same changesets ?
a09982d91fab/8030993 has no change to the macros
right (I didn't think this was topic of this conversation)
fb89dc4fe8da/8031737 is the one that reimplemented the macros
and is the version I'd want. It
Are we talking about the same changesets ?
a09982d91fab/8030993 has no change to the macros
fb89dc4fe8da/8031737 is the one that reimplemented the macros
and is the version I'd want. Its the last 'edit' of those macros in that
file.
c58c6b0fbe34/8030875 is the original addition of these :-
..
Changeset: 950921234b10
Author:katleman
Date: 2014-01-22 12:53 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/950921234b10
Added tag jdk8-b125 for changeset 790bbd46b201
! .hgtags
Changeset: 1b5d578f93ef
Author:katleman
Date: 2014-01-22 14:06 -0800
URL: http://hg
Hi Volker,
I agree with the approach below and jdk9/dev is the better forest.
For the test itself, I would suggest reducing the following loop to 1 or
2 cases:
for (int i = 0; i < testString.length(); i++) {
test(createDocument(testString.toString(), i), ""+ i);
}
Hi Phil,
The later changeset picked up the recommended style of implementing the
macros
but I don't think it was substantive. You can probably do without it.
Version.c had some changes in a different changeset to address
the omission of checking for exceptions after some JNI calls.
Roger
On
Changeset: 75cf17ceb6d1
Author:katleman
Date: 2014-01-22 12:54 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75cf17ceb6d1
Added tag jdk8-b125 for changeset ae303640bc1c
! .hgtags
Changeset: 95410515ba5f
Author:katleman
Date: 2014-01-22 14:08 -0800
URL: http:
Changeset: 16e0c6c84a91
Author:amurillo
Date: 2014-01-13 16:00 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16e0c6c84a91
8031553: new hotspot build - hs25-b67
Reviewed-by: jcoomes
! make/hotspot_version
Changeset: 12ad8db39f76
Author:roland
Date: 2014-01-14 0
Changeset: c0040f0b75e2
Author:katleman
Date: 2014-01-22 12:53 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c0040f0b75e2
Added tag jdk8-b125 for changeset ef71ecbcd7bc
! .hgtags
Changeset: 7193a007a159
Author:katleman
Date: 2014-01-22 14:07 -0800
URL: htt
Changeset: 6a5af8a36aaf
Author:katleman
Date: 2014-01-22 12:53 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6a5af8a36aaf
Added tag jdk8-b125 for changeset 83bb924238f8
! .hgtags
Changeset: 390cc275c04c
Author:katleman
Date: 2014-01-22 14:07 -0800
URL: http
Changeset: d336209a0e45
Author:katleman
Date: 2014-01-22 12:54 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d336209a0e45
Added tag jdk8-b125 for changeset 7346abe2ea03
! .hgtags
Changeset: 095263db862d
Author:katleman
Date: 2014-01-22 14:00 -0800
URL: h
Changeset: 18c4d03cf516
Author:katleman
Date: 2014-01-22 12:53 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/18c4d03cf516
Added tag jdk8-b125 for changeset 7b45151c7a05
! .hgtags
Changeset: 8ceb68fd9e10
Author:katleman
Date: 2014-01-22 14:06 -0800
URL: htt
Changeset: 9a4dbfe11ed1
Author:katleman
Date: 2014-01-22 12:54 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9a4dbfe11ed1
Added tag jdk8-b125 for changeset 436176151e85
! .hgtags
Changeset: ba24b6304362
Author:katleman
Date: 2014-01-22 14:09 -0800
URL:
Roger,
That later one seems to be using the macros. I don't see any update to
the macros.
So I'm not sure why I'm need it .. since I'm not using those calls and
neither
are the macros.
-phil.
On 2/11/14 12:28 PM, roger riggs wrote:
Hi Phil,
Yes, it ended up in two change sets in jdk 9, you
8030875 applied but 8031737 will not apply for me, presumably
because Version.c had a number of changes under bug 8029007.
And the version from 8031737 is the one that I want.
-phil.
On 2/11/14 12:04 PM, Alan Bateman wrote:
On 11/02/2014 19:57, Phil Race wrote:
Roger,
Yes, I can do that.
I
Hi Phil,
Yes, it ended up in two change sets in jdk 9, you should take both to be
up to date.
changeset: 9245:a09982d91fab
user:rriggs
date:Wed Feb 05 10:59:53 2014 -0500
files: src/share/native/common/jni_util.c
description:
8030993: Check jdk/src/share/native/common/j
Thanks all for the responses. It is an ABA problem.
I changed my code so that it creates new StackEntries if multiple threads
attempt to pop the stack at the same time. This relies on getAndSet to
obtain exclusive access to the stack contents, rather than using
compareAndSet to update the stack.
On 11/02/2014 19:57, Phil Race wrote:
Roger,
Yes, I can do that.
I see here
http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that
1) There was a previous version of these macros.
Looks like no need to worry about that I just need the latest version.
2) There was also a change
Roger,
Yes, I can do that.
I see here
http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that
1) There was a previous version of these macros.
Looks like no need to worry about that I just need the latest version.
2) There was also a change to Version.c. I can include that if yo
On 02/11/2014 01:41 PM, Peter Harvey wrote:
If multiple threads call AtomicReference.compareAndSet with the same pair
of values, it appears that multiple threads may succeed. For example, if
multiple threads call compareAndSet("Alpha", "Beta") then they may all
succeed. Is this the correct behavi
Hi Phil,
I see your point, there is nothing in the changes unique to 9.
Do you want to take care of the back point?
Roger
On 2/11/2014 2:04 PM, Phil Race wrote:
Roger,
Why not JDK 8u ? I've got a lot of changes that utilise these that will
backport cleanly to JDK 8u only if 8u includes thes
Roger,
Why not JDK 8u ? I've got a lot of changes that utilise these that will
backport cleanly to JDK 8u only if 8u includes these macros. And since
the changes are all over the place I don't fancy copy/pasting them
everywhere. I suspect I am not the only one who would like these in 8u ..
-phi
On 2/11/2014 9:05 AM, Daniel Fuchs wrote:
On 2/11/14 5:55 PM, Lance @ Oracle wrote:
Hi joe
It looks like you changed the serialversionuid in Durationimpl, did
it get changed incorrectly previously?
I noticed that as well, but I'm not sure it matters since Duration
uses writeReplace to seria
If multiple threads call AtomicReference.compareAndSet with the same pair
of values, it appears that multiple threads may succeed. For example, if
multiple threads call compareAndSet("Alpha", "Beta") then they may all
succeed. Is this the correct behaviour?
The documentation maybe should make this
This changeset was erroneously pushed to jdk8/tl/jdk:
Changeset: da4b0962ad11
Author:robm
Date: 2014-02-10 14:35 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da4b0962ad11
7152892: some jtreg tests fail with permission denied
Reviewed-by: coffeys
! test/java/
Hi Alan,
you're right. I initially didn't saw the test because I just looked at
the change in the jaxp repository.
If it will be approved, I'll put the test in the same directory like
the other test (i.e. test/javax/xml/jaxp/parsers/8027359).
And yes, my plan was to get approval for both, the te
On 2/11/14 5:55 PM, Lance @ Oracle wrote:
Hi joe
It looks like you changed the serialversionuid in Durationimpl, did it get
changed incorrectly previously?
I noticed that as well, but I'm not sure it matters since Duration
uses writeReplace to serialize itself as an instance of
SerializedDura
Hi joe
It looks like you changed the serialversionuid in Durationimpl, did it get
changed incorrectly previously?
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 F
On 11/02/2014 14:57, Volker Simonis wrote:
Hi,
after opening this bug yesterday for an issue found by my colleague
Steffen Schreiber we realized that this is actually a duplicate of
"8027359: XML parser returns incorrect parsing results"
(https://bugs.openjdk.java.net/browse/JDK-8027359).
While
I've been doing some upgrades on servers I run at home recently. One of
the upgrades I'd planned was to increase the key size of my internal CA
key and SSL keys to 8192 bits as a future-proofing measure (I use SSL
with client certificates for all service-to-service communication).
What I found wa
On 11/02/2014 15:52, Martin Buchholz wrote:
Thanks for doing this cleanup.
ThrowingTasks fiddles with uncaught exception handlers and security
managers, so should remain otherVM. Interrupt does not, but could use
a tiny bit of cleanup hygiene:
Probably best to create a separate issue for the
Hi,
after opening this bug yesterday for an issue found by my colleague
Steffen Schreiber we realized that this is actually a duplicate of
"8027359: XML parser returns incorrect parsing results"
(https://bugs.openjdk.java.net/browse/JDK-8027359).
While there's no need now to submit a patch anymor
+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 Feb 11, 2014, at 6:19 AM, Alan Bateman wrote:
>
> It was never meant to be used by anything outside of the JDK
On Feb 11, 2014, at 12:19 PM, Alan Bateman wrote:
>
> It was never meant to be used by anything outside of the JDK and there has
> been a standard API (java.util.ServiceLoader) since JDK 6 (released in 2006).
>
Scrub it!
AFAICT it is not widely used (looking at the use of s.m.Service static m
It was never meant to be used by anything outside of the JDK and there
has been a standard API (java.util.ServiceLoader) since JDK 6 (released
in 2006).
-Alan
On 11 Feb 2014, at 11:10, Alan Bateman wrote:
> On 11/02/2014 10:36, Chris Hegarty wrote:
>> Looks good to me Alan.
>>
>> -Chris.
>>
> I checked the jsr166 CVS and both of the j.u.concurrent tests also specify
> UseVMInterruptibleIO. I assume Martin will update these.
Yes, I see this too.
Ma
On 11/02/2014 10:36, Chris Hegarty wrote:
Looks good to me Alan.
-Chris.
I checked the jsr166 CVS and both of the j.u.concurrent tests also
specify UseVMInterruptibleIO. I assume Martin will update these.
-Alan
Looks good to me Alan.
-Chris.
On 11 Feb 2014, at 10:31, Alan Bateman wrote:
>
> Interruptible I/O was a (mostly Solaris only) mis-feature that we've been
> eradicating over a number of releases. In JDK 6 the VM option
> UseVMInterruptibleIO was added to allow it be disabled, in JDK 7 it was
Interruptible I/O was a (mostly Solaris only) mis-feature that we've
been eradicating over a number of releases. In JDK 6 the VM option
UseVMInterruptibleIO was added to allow it be disabled, in JDK 7 it was
switched to being disabled by default, in JDK 8 we removed the
dependency from the li
Hi Mike,
as described in the bug comments, I still think that correctly
handling a null Supplier is the cleanest and easiest solution. Without
the change our VM will throw the following NPE:
java.lang.NullPointerException: while trying to invoke the method
java.util.function.Supplier.get() of a n
Please, could you give me your opinions on the following ideas for a JDK9
RFE ?
Is it worth? Interesting or totally stupid with current hotspot / gc ?
How hard / long would it be to study and make a prototype ?
Any other ideas to improve array performance like improving again the array
bound che
47 matches
Mail list logo
