On 2/27/15 3:19 PM, Stuart Marks wrote:
On 2/27/15 12:40 PM, Xueming Shen wrote:
On 02/27/2015 11:21 AM, Xueming Shen wrote:
On 02/27/2015 10:55 AM, Paul Sandoz wrote:
What about a light wright immutable MatchResult? is that possible?
Should be possible. I can give it try.
too
On 02/10/2015 07:10 AM, Staffan Larsen wrote:
To clarify: The restriction in jtreg is that all tests are loaded in separate
class loaders (when running in samevm mode). A native library can only be
loaded in one class loader at a time. So if two tests tries to load the same
library we get
looks good.
-Sherman
On 2/27/2015 5:10 PM, Claes Redestad wrote:
On 2015-02-27 18:00, Xueming Shen wrote:
Any reason setlastModifiedTime() uses javaToDosTime()? maybe the
original
pair should be private?
Right, hiding the now internal methods and making the calls consistent
is a
better
On Feb 27, 9:34am, a...@redhat.com (Andrew Haley) wrote:
-- Subject: Re: stop using mmap for zip I/O
| On 26/02/15 22:17, Christos Zoulas wrote:
| There are numerous bug reports about the jvm crashing in libzip...
| Just google for libzip java crash. The bottom line is that using
| mmap is
On 02/27/2015 07:27 AM, Florian Weimer wrote:
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are especially interesting in
Any reason setlastModifiedTime() uses javaToDosTime()? maybe the original
pair should be private?
On 02/27/2015 08:32 AM, Claes Redestad wrote:
On 02/26/2015 10:09 PM, Peter Levart wrote:
Hi Claes,
I like the backwards-compatible extended DOS time format idea. If you keep it
as one field,
Hi,
Please find below a patch for:
8074032: Instant.ofEpochMilli(millis).toEpochMilli() can
throw arithmetic overflow in toEpochMilli()
http://cr.openjdk.java.net/~dfuchs/webrev_8074032/webrev.00/
The issue is that when converting milliseconds to seconds + nanos
Hi,
On Feb 13, 2015, at 8:26 PM, Stuart Marks stuart.ma...@oracle.com wrote:
OK, this looks great. Thanks for the updates.
There is also
in same order - in the same order
in the doc for the results() method, as Brian pointed out internally.
No need for another webrev.
Alas
On 02/26/2015 10:09 PM, Peter Levart wrote:
Hi Claes,
I like the backwards-compatible extended DOS time format idea. If you
keep it as one field, you could move the code for conversion from
millisecond Java time to/from extended DOS time format to the ZipUtils
methods entirely
Hi Daniel,
Looks ok.
Roger
On 2/27/2015 11:25 AM, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
8074032: Instant.ofEpochMilli(millis).toEpochMilli() can
throw arithmetic overflow in toEpochMilli()
http://cr.openjdk.java.net/~dfuchs/webrev_8074032/webrev.00/
The issue is
On Feb 27, 2015, at 4:47 PM, Florian Weimer fwei...@redhat.com wrote:
I really don't think this tooling support will provide sufficient
enticement to developers to maintain separate 7/8/9 source branches of
their libraries. Isn't that the main obstacle, and not the way the bits
are delivered?
Please review this change to remove deprecated methods:
java.lang.Runtime.getLocalizedInputStream(InputStream in)
java.lang.Runtime.getLocalizedOutputStream(OutputStream out)
If you are aware of any uses of these methods please comment; I could
not find any.
Webrev:
Hi Roger,
Looks fine based on the various discussions about these methods
On Feb 27, 2015, at 11:57 AM, Roger Riggs roger.ri...@oracle.com wrote:
Please review this change to remove deprecated methods:
java.lang.Runtime.getLocalizedInputStream(InputStream in)
Looks good to me.
thanks
Stephen
On 27 February 2015 at 16:25, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi,
Please find below a patch for:
8074032: Instant.ofEpochMilli(millis).toEpochMilli() can
throw arithmetic overflow in toEpochMilli()
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are especially interesting in hearing feedback from library developers,
On Feb 27, 2015, at 2:27 PM, Florian Weimer fwei...@redhat.com wrote:
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are
On 27/02/2015 11:30, Andrew Haley wrote:
On 02/27/2015 09:51 AM, Seán Coffey wrote:
So we catch the signal, right? Maybe there's something I'm missing...
We don't catch/detect such SEGV's. Would it make sense, is it possible ?
Sure. There's some fiddly low-level code involved but it's
On Feb 27, 1:49pm, a...@redhat.com (Andrew Haley) wrote:
-- Subject: Re: stop using mmap for zip I/O
| The issues I've been looking at are SEGV issues concerning multiple threads
| operating on the same zip structure. (one freeing, while another is
| attempting access)
Yes, I am not
On 27/02/15 12:23, chris...@zoulas.com wrote:
On Feb 27, 9:51am, sean.cof...@oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
wrote:
-- Subject: Re: stop using mmap for zip I/O
| The sun.zip.disableMemoryMapping=true property helps with ZipFile class
| only. There are other related issues in
On 27 February 2015 at 10:55, Daniel Fuchs daniel.fu...@oracle.com wrote:
I don't think I saw an issue raised for caching the clock in ZoneId.
That seems like a good plan to me (ZoneId instances are controlled
singletons, so there is no big memory issue there)
I'd been intending to log that.
On Feb 27, 9:51am, sean.cof...@oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
wrote:
-- Subject: Re: stop using mmap for zip I/O
| The sun.zip.disableMemoryMapping=true property helps with ZipFile class
| only. There are other related issues in the ZipInput/Output streams.
| Some code areas
Hello,
Looks good to me.
Thank you,
Elena
On 27.02.2015 5:28, joe darcy wrote:
Hello,
Please review the small changes to address
JDK-8073952: Spec of j.l.r.Method.toString/toGenericString need to
be clarified
http://cr.openjdk.java.net/~darcy/8073952.0/
Full patch below.
In
On 02/27/2015 01:47 PM, Seán Coffey wrote:
On 27/02/15 12:23, chris...@zoulas.com wrote:
On Feb 27, 9:51am, sean.cof...@oracle.com
(=?windows-1252?Q?Se=E1n_Coffey?=) wrote:
-- Subject: Re: stop using mmap for zip I/O
| The sun.zip.disableMemoryMapping=true property helps with ZipFile
On 27/02/2015 13:27, Florian Weimer wrote:
:
I'm wondering how you propose to build such JAR files. Do you think
library developers will maintain two separate branches, compile one with
JDK 8, the other one with JDK 9, and then use some (not yet existing?)
tool to merge the output into a single
On 02/27/2015 10:34 AM, Paul Sandoz wrote:
On Feb 27, 2015, at 7:18 PM, Xueming Shenxueming.s...@oracle.com wrote:
Hi Paul,
1133 * @param replacer
1134 * The function to be applied to the match result of this
matcher
1135 * that returns a replacement string.
On Feb 27, 2015, at 7:48 PM, Xueming Shen xueming.s...@oracle.com wrote:
On 02/27/2015 10:34 AM, Paul Sandoz wrote:
On Feb 27, 2015, at 7:18 PM, Xueming Shenxueming.s...@oracle.com wrote:
Hi Paul,
1133 * @param replacer
1134 * The function to be applied to the match
On Feb 27, 2015, at 7:18 PM, Xueming Shen xueming.s...@oracle.com wrote:
Hi Paul,
1133 * @param replacer
1134 * The function to be applied to the match result of this
matcher
1135 * that returns a replacement string.
1136 *
1137 *p The
Le 27/02/15 16:47, Florian Weimer a écrit :
Maybe I misunderstood the multi-version JAR files proposal, but I
thought that the assumption there is that there are actual *source*
files which use newer features of the platform.
I really don't think this tooling support will provide sufficient
On 27/02/15 02:04, Stuart Marks wrote:
On 2/19/15 9:33 AM, Chris Hegarty wrote:
It came up recently that java.util.Arrays was missing subrange
overloads for setAll and parallelSetAll. These methods can be easily
written with IntStream.range. Rather than adding eight new methods for
this, it
Hi Paul,
1133 * @param replacer
1134 * The function to be applied to the match result of this
matcher
1135 * that returns a replacement string.
1136 *
1137 *p The function should not modify this matcher's state during
1138 * replacement.
Why do you expect the new classes in the JDK not to be part of the API? Simple
example:
I have a library that's 5 years old. The API needed the equivalent of
java.util.Function (from Java 8), which obviously was not there when I wrote my
library. Let's say I had defined CustomFunction and now
Thanks, Paul!
Best regards,
Vladimir Ivanov
On 2/27/15 1:03 PM, Paul Sandoz wrote:
On Feb 26, 2015, at 7:14 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8073644/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8073644
After JDK-8069591 [1]
On 02/27/2015 03:20 PM, Alan Bateman wrote:
On 27/02/2015 13:27, Florian Weimer wrote:
:
I'm wondering how you propose to build such JAR files. Do you think
library developers will maintain two separate branches, compile one with
JDK 8, the other one with JDK 9, and then use some (not yet
On 02/27/2015 11:21 AM, Xueming Shen wrote:
On 02/27/2015 10:55 AM, Paul Sandoz wrote:
What about a light wright immutable MatchResult? is that possible?
Should be possible. I can give it try.
too repetitive?
On 02/27/2015 10:55 AM, Paul Sandoz wrote:
What about a light wright immutable MatchResult? is that possible?
Should be possible. I can give it try.
On Feb 26, 2015, at 5:02 PM, Paul Sandoz paul.san...@oracle.com wrote:
Hi,
If anyone wants to give this a test drive see stuff in here:
http://cr.openjdk.java.net/~psandoz/multiversion-jar/
produced by Steve (CC'ed) who has done all the development.
Another correction, CC'ing Steve
On Feb 26, 2015, at 11:33 PM, Alan Bateman alan.bate...@oracle.com wrote:
On 26/02/2015 22:09, Xueming Shen wrote:
thanks! webrev has been updated accordingly.
http://cr.openjdk.java.net/~sherman/8073924/webrev
We could probably improve it further but what you have is good and not worth
On Feb 26, 2015, at 12:38 PM, Chris Hegarty chris.hega...@oracle.com wrote:
On 24 Feb 2015, at 15:07, Chris Hegarty chris.hega...@oracle.com wrote:
On 24 Feb 2015, at 11:45, Peter Levart peter.lev...@gmail.com wrote:
...
That's better now. Let me just try to measure the overhead of
On 26/02/15 22:17, Christos Zoulas wrote:
There are numerous bug reports about the jvm crashing in libzip...
Just google for libzip java crash. The bottom line is that using
mmap is problematic (I can get into more per OS details if necessary)
because it will potentially signal when the file
On Feb 27, 2015, at 9:00 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Feb 26, 2015, at 5:02 PM, Paul Sandoz paul.san...@oracle.com wrote:
Hi,
If anyone wants to give this a test drive see stuff in here:
http://cr.openjdk.java.net/~psandoz/multiversion-jar/
produced by Steve
On 26 February 2015 at 23:29, Peter Levart peter.lev...@gmail.com wrote:
Here's another variant that doesn't use a back link to base TimeZone:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.03/
Yes, thats easier to follow. I think I'd be happy with that approach.
I
On 26/02/2015 22:09, Xueming Shen wrote:
thanks! webrev has been updated accordingly.
One other tests that needs to be re-examined is
test/sun/nio/cs/Test4200310.sh as it assumes rt.jar and charsets.jar
too. In this case then it might be better to just remove it.
-Alan
On Feb 23, 2015, at 5:57 PM, Roger Riggs roger.ri...@oracle.com wrote:
Hi,
I propose to remove two methods; they have been deprecated for more than a
decade,
do not seem to be in use anywhere, and have degenerate implementations.
java.lang.Runtime.getLocalizedInputStream(InputStream
On 26 feb 2015, at 22:35, Peter Levart peter.lev...@gmail.com wrote:
On 02/26/2015 10:27 PM, Peter Levart wrote:
The m.setAccessible(true) for the methods is needed to access methods of
non-public annotations, right? This call could be moved to AnnotationType
constructor as there it will
On 2015-02-26 10:25, Erik Joelsson wrote:
Hello Magnus,
Overall looks good. I would prefer if some of the longer lines in
Main.gmk were split as it's a file I often need to read. In MakeBase,
the definition of dups, I thought we (informally) agreed to start such
macro definitions with a
On 27/02/15 09:36, Stephen Colebourne wrote:
On 26 February 2015 at 23:29, Peter Levart peter.lev...@gmail.com wrote:
Here's another variant that doesn't use a back link to base TimeZone:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.03/
Yes, thats easier to follow.
On 2/27/15 12:40 PM, Xueming Shen wrote:
On 02/27/2015 11:21 AM, Xueming Shen wrote:
On 02/27/2015 10:55 AM, Paul Sandoz wrote:
What about a light wright immutable MatchResult? is that possible?
Should be possible. I can give it try.
too repetitive?
On 2015-02-27 18:00, Xueming Shen wrote:
Any reason setlastModifiedTime() uses javaToDosTime()? maybe the original
pair should be private?
Right, hiding the now internal methods and making the calls consistent is a
better practice here.
On Feb 26, 2015, at 7:14 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8073644/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8073644
After JDK-8069591 [1] which introduced LambdaForm customization, the assert
in
Hi Chris,
webrev.04 is nice an simple now. I'm ok with it.
Regards, Peter
On Feb 27, 2015 11:11 AM, Chris Hegarty chris.hega...@oracle.com wrote:
Hi Peter,
I think you are ok with this now. If so, would you mind to just taking a
quick look at the webrev, the changes are trivial, and
Hi,
On 27 feb 2015, at 01:04, Mandy Chung mandy.ch...@oracle.com wrote:
On 2/26/15 1:27 PM, Peter Levart wrote:
On 02/26/2015 05:34 PM, Mandy Chung wrote:
The problem is with the default method
AnnotatedElement::getDeclaredAnnotationsByType. If someone has an external
implementation
The sun.zip.disableMemoryMapping=true property helps with ZipFile class
only. There are other related issues in the ZipInput/Output streams.
Some code areas don't have synchronization and there are opportunities
for the underlying native zip resources to be freed which Java code then
tries to
On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote:
On 26 feb 2015, at 22:35, Peter Levart peter.lev...@gmail.com wrote:
On 02/26/2015 10:27 PM, Peter Levart wrote:
The m.setAccessible(true) for the methods is needed to access methods of
non-public annotations, right? This call could be moved
On 02/27/2015 09:51 AM, Seán Coffey wrote:
So we catch the signal, right? Maybe there's something I'm missing...
We don't catch/detect such SEGV's. Would it make sense, is it possible ?
Sure. There's some fiddly low-level code involved but it's perfectly
possible, at least on GNU/Linux.
54 matches
Mail list logo
