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 p
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 repetitive?
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 err
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.
http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev
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?
http://cr.openjdk.java.net/~sherman/reg
Hi,
It seems in my eagerness to expedite this, I neglected to follow the
established
protocol for removing methods.
The decision and announcement to remove methods will be made as part of
the JDK 9
updates but the actual removal will be in a later release (JDK 10).
My apologies for the conf
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?
http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/ja
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 27, 2015, at 7:48 PM, Xueming Shen wrote:
> On 02/27/2015 10:34 AM, Paul Sandoz wrote:
>> On Feb 27, 2015, at 7:18 PM, Xueming Shen wrote:
>>
>>> Hi Paul,
>>>
>>> 1133 * @param replacer
>>> 1134 * The function to be applied to the match result of this
>>> matcher
>>
On 02/27/2015 10:34 AM, Paul Sandoz wrote:
On Feb 27, 2015, at 7:18 PM, Xueming Shen 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 *
On Feb 27, 2015, at 7:18 PM, Xueming Shen 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 * The function should not modi
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 sufficie
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 I
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 * The function should not modify this matcher's state during
1138 * replacement. Th
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
>> th
On Feb 27, 2015, at 4:47 PM, Florian Weimer 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?
>
What if al
Hi Roger,
Looks fine based on the various discussions about these methods
On Feb 27, 2015, at 11:57 AM, Roger Riggs wrote:
> Please review this change to remove deprecated methods:
> java.lang.Runtime.getLocalizedInputStream(InputStream in)
> java.lang.Runtime.getLocalizedOutputStream(Output
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, yo
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:
http://cr.openjdk.java.
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 t
Looks good to me.
thanks
Stephen
On 27 February 2015 at 16:25, 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/web
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 (javaToXdosTim
Hi,
On Feb 13, 2015, at 8:26 PM, Stuart Marks 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 there is :-)
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
Instant.ofEpochMilli()
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 (no
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
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
On Feb 27, 2015, at 2:27 PM, 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 especi
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 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 perfec
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 refer
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 hearing
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
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 the
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,
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 essen
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 don
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 i
On 27 February 2015 at 10:55, Daniel Fuchs 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. Thanks for remin
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. Ma
On 27/02/15 09:36, Stephen Colebourne wrote:
On 26 February 2015 at 23:29, Peter Levart 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 w
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" 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 replying to the list.
>
>
On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote:
On 26 feb 2015, at 22:35, Peter Levart 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
con
On Feb 26, 2015, at 7:14 PM, Vladimir Ivanov
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 LambdaFormEditor.bindArgumentType became too str
Hi,
> On 27 feb 2015, at 01:04, Mandy Chung 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 of An
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 r
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 newli
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 f
> On 26 feb 2015, at 22:35, Peter Levart 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 be performed onl
On Feb 26, 2015, at 12:38 PM, Chris Hegarty wrote:
> On 24 Feb 2015, at 15:07, Chris Hegarty wrote:
>
>> On 24 Feb 2015, at 11:45, Peter Levart wrote:
>> ...
>>> That's better now. Let me just try to measure the overhead of tracking on
>>> simple objects to see if it actually pays off or is
On Feb 23, 2015, at 5:57 PM, Roger Riggs 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 in)
> java.lang.R
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 26, 2015, at 11:33 PM, Alan Bateman 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
> spending mo
On 26 February 2015 at 23:29, Peter Levart 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 don't think I saw an is
On Feb 27, 2015, at 9:00 AM, Paul Sandoz wrote:
>
> On Feb 26, 2015, at 5:02 PM, Paul Sandoz 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 dev
On Feb 26, 2015, at 5:02 PM, Paul Sandoz 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 this time...
55 matches
Mail list logo
