Re: Missing @since tags

Hi Martin, On 02/07/2013 10:29 AM, Martin Buchholz wrote: On Thu, Feb 7, 2013 at 9:49 AM, Alan Bateman wrote: On 07/02/2013 17:40, Martin Buchholz wrote: Alternatively, maybe this is a job for an annotation processor. IIRC, we considered that 6 years ago. It might be possible, but consid

Re: Early review on NIO Stream APIs

On Thu, Feb 7, 2013 at 10:45 PM, Henry Jen wrote: > BiPredicate is a intentional choice, as during the walk process, the > attribute is read and many times, filtering is based on file attributes. > > PathMatcher is basically a Predicate, developer can easily use that in > a filter with walk, whi

hg: jdk8/tl/langtools: 7195131: Update 2 compiler combo tests for repeating annotations to include package and default use cases

Changeset: 5125b9854d07 Author:darcy Date: 2013-02-07 20:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5125b9854d07 7195131: Update 2 compiler combo tests for repeating annotations to include package and default use cases Reviewed-by: darcy Contributed-by: sonali.g

Re: Early review on NIO Stream APIs

BiPredicate is a intentional choice, as during the walk process, the attribute is read and many times, filtering is based on file attributes. PathMatcher is basically a Predicate, developer can easily use that in a filter with walk, which return a Stream. Hope that helps. Cheers, Henry On Feb

Re: Early review on NIO Stream APIs

The find() method uses a BiPredicate matcher what about using the existing java.nio.file.PathMatcher interface? There are already some implementations of PathMatcher both in JDK and in the wild. PathMatcher doesn't accept the file attributes though, but that's a problem for most Path-based

Re: [JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates

I wonder if it's not better to declare enum constants of DayOfWeek (and Month) in an order that is not the usual week/month order to make clear that ordinal() doesn't work as expected. By example they can be declared in alphabetical order. cheers, Rémi On 02/07/2013 07:31 PM, Xueming Shen wro

Re: RFR JDK-8007609

On 7/02/2013 10:54 PM, Chris Hegarty wrote: On 02/07/2013 11:54 AM, David Holmes wrote: AFAICS setting len=0 means len==0 will be true and so we will free(result). And if len != 0 then we will have already freed result, so avoiding a double-free. Here's the code as it stands today. Y

Early review on NIO Stream APIs

Hi, While lambda still finalizing the final API for Stream, there are a couple of streamifaction APIs in nio area, which I would like to start circling around to get early feedbacks. Those APIs return a CloseableStream, other than that, there is not much directly connection to Stream definition.

Re: Missing @since tags

JDiff hasn't been updated since 2008. I would be surprised if you could get it to work on jdk8 vs. jdk7 without significant work. But the key thing is to use a tool, any tool, since history has shown it is very easy for engineers to forget to add the necessary @since tags. On Thu, Feb 7, 2013 at

Re: JDK7's java.util.zip breakage with very large files

Sure, I do have the "zipinfo" there:-) try java com.sun.nio.zipfs.ZipInfo FOO.jar Cool, right :-) -Sherman On 02/07/2013 12:36 PM, Kumar Srinivasan wrote: On 2/7/2013 12:23 PM, Xueming Shen wrote: There is difference between doing "jar xvf data.jar data" and "jar xvf data.jar" you can

Re: JDK7's java.util.zip breakage with very large files

On Thu, Feb 7, 2013 at 3:36 PM, Kumar Srinivasan wrote: > On 2/7/2013 12:23 PM, Xueming Shen wrote: >> >> There is difference between doing >> >> "jar xvf data.jar data" >> >> and >> >> "jar xvf data.jar" > > > you can also use zipinfo -v to check CEN entries. Wow, that works too. Hmph. I think b

Re: JDK7's java.util.zip breakage with very large files

On Thu, Feb 7, 2013 at 3:33 PM, Alexander Sack wrote: > On Thu, Feb 7, 2013 at 3:23 PM, Xueming Shen wrote: >> There is difference between doing >> >> "jar xvf data.jar data" >> >> and >> >> "jar xvf data.jar" >> >> If the previous one works, it means the zip file should have >> the healthy end t

Re: JDK7's java.util.zip breakage with very large files

On 2/7/2013 12:23 PM, Xueming Shen wrote: There is difference between doing "jar xvf data.jar data" and "jar xvf data.jar" you can also use zipinfo -v to check CEN entries. Kumar If the previous one works, it means the zip file should have the healthy end table there (it goes down to end

Re: JDK7's java.util.zip breakage with very large files

On Thu, Feb 7, 2013 at 3:23 PM, Xueming Shen wrote: > There is difference between doing > > "jar xvf data.jar data" > > and > > "jar xvf data.jar" > > If the previous one works, it means the zip file should have > the healthy end table there (it goes down to end->cen-> > loc->data file). $ jar xv

Re: JDK7's java.util.zip breakage with very large files

There is difference between doing "jar xvf data.jar data" and "jar xvf data.jar" If the previous one works, it means the zip file should have the healthy end table there (it goes down to end->cen-> loc->data file). The later goes from the sequential looking up from the beginning, so it only lo

Re: JDK7's java.util.zip breakage with very large files

On Thu, Feb 7, 2013 at 3:11 PM, Xueming Shen wrote: > Alexander, > > Can you do "jar xvf data.jar data" to extract the file? > > As per original email, yes I can. Also md5sum checks out. But large files result in a malformed zip file. -aps

Re: JDK7's java.util.zip breakage with very large files

Alexander, Can you do "jar xvf data.jar data" to extract the file? -Sherman On 02/07/2013 08:54 AM, Alexander Sack wrote: Folks: What I am trying to do is generate Zip64 extensions within a JAR file and then dissect the zip contents (end of directory records, file headers, etc.). However, w

Re: Missing @since tags

http://javadiff.sourceforge.net/ Which is implemented as a doclet does provide missing @since detection functionality. Mike On Feb 7 2013, at 10:29 , Martin Buchholz wrote: > On Thu, Feb 7, 2013 at 9:49 AM, Alan Bateman wrote: > >> On 07/02/2013 17:40, Martin Buchholz wrote: >> >>> Alternati

Re: JDK7's java.util.zip breakage with very large files

On Thu, Feb 7, 2013 at 1:32 PM, Martin Buchholz wrote: > It's probably a bug, but ... > - it would help to have a clear reproducible test case dd if= of=data bs=1G count=12 jar cvf data.jar data [get a cup of your favorite hot beverage] bvi data #504B0506 or "$", "#504B' etc. No EoD at the end a

[JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb.

Hi, 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. Webrev: http://cr.openjdk.java.net/~sherman/8007572/ Note: JDK/JRE has been using the time zone data at /lib/zi for j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own time zone data file/format lib/t

[JSR310 M7 Review request] 8007520: Update date/time classes in j.util and j.sql packages to interoperate with JSR310 classes

8007520: Update date/time classes in j.util and j.sql packages Webrev: http://cr.openjdk.java.net/~sherman/8007520/ Note: As part of the JSR310 Date/Time API project, methods are proposed to be added into existing jdk date/time classes in java.util and java.sql packages to inter-operate with th

[JSR310 M7 Review request] 8007392: JSR310 DateTime API Updates

8007392: JSR 310: DateTime API Updates Webrev: http://cr.openjdk.java.net/~sherman/8007392/ http://cr.openjdk.java.net/~sherman/8007392/javadoc Note: The Threeten API has been updated based on reviews and continued development. The main changes included here are - Consolidating Chronology cla

Re: JDK7's java.util.zip breakage with very large files

It's probably a bug, but ... - it would help to have a clear reproducible test case - take a look at my vaguely related webrev from yesterday to this mailing list - I don't call zos.finish; I call zos.close which Works For Me. Martin On Thu, Feb 7, 2013 at 8:54 AM, Alexander Sack wrote: > Folks

Re: Missing @since tags

On Thu, Feb 7, 2013 at 9:49 AM, Alan Bateman wrote: > On 07/02/2013 17:40, Martin Buchholz wrote: > >> Alternatively, maybe this is a job for an annotation processor. > > IIRC, we considered that 6 years ago. It might be possible, but consider that you need to diff multiple jdk implementations, a

Re: zip64 compatibility problems

On Thu, Feb 7, 2013 at 8:15 AM, Alan Bateman wrote: > On 07/02/2013 01:55, Martin Buchholz wrote: > >> Following up, please review the backward compatiblitiy support in: >> >> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/** >> useZip64For64kEntries/

Re: Missing @since tags

On 07/02/2013 17:40, Martin Buchholz wrote: On Thu, Feb 7, 2013 at 8:49 AM, Chris Hegartywrote: Martin, I have finally located the script, findMissingSince ;-) I will run it once I have a clean, up to date, jdk8 build. I think it may be a candidate to propose to add to the common scripts in th

Re: Missing @since tags

On Thu, Feb 7, 2013 at 8:49 AM, Chris Hegarty wrote: > Martin, > > I have finally located the script, findMissingSince ;-) I will run it once > I have a clean, up to date, jdk8 build. I think it may be a candidate to > propose to add to the common scripts in the top-level repo. Because the scrip

JDK7's java.util.zip breakage with very large files

Folks: What I am trying to do is generate Zip64 extensions within a JAR file and then dissect the zip contents (end of directory records, file headers, etc.). However, when I use jar or a small program that I wrote which uses java.util.zip to zip up a very large file >12G, I do not get the expect

Re: Missing @since tags

Martin, I have finally located the script, findMissingSince ;-) I will run it once I have a clean, up to date, jdk8 build. I think it may be a candidate to propose to add to the common scripts in the top-level repo. -Chris. On 02/06/2013 10:13 PM, Martin Buchholz wrote: Please find and resu

Re: Review request for JDK-8007405: Update parameter reflection API in accordance with spec changes

There is an extensive test suite being developed by Peter Jensen, which will go in after I push the compiler side. On 02/07/13 00:09, Joe Darcy wrote: > Hi Eric, > > The code changes look okay, but some tests for isImplicit should be > written as soon as there is compiler support for the feature.

Re: zip64 compatibility problems

On 07/02/2013 01:55, Martin Buchholz wrote: Following up, please review the backward compatiblitiy support in: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/useZip64For64kEntries/ (ideally users would have even more control via the API, but I ain't gonna try to touch that) No objection to

RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals

I am chiming in to agree with Stephen. About a year ago, I encountered the same issue and was extremely dissatisfied with the behavior. I was forced to create a utility method to check for "0" before passing it onto stripTrailingZeros(). The current behavior is useless; the spec is clear stripping

Re: RFR JDK-8007609

On 02/07/2013 11:54 AM, David Holmes wrote: AFAICS setting len=0 means len==0 will be true and so we will free(result). And if len != 0 then we will have already freed result, so avoiding a double-free. Here's the code as it stands today. 113 result = (WCHAR*)malloc(MAX_PATH * si

hg: jdk8/tl/jdk: 8007142: Add utility classes for writing better multiprocess tests in jtreg

Changeset: 2de8c6c2d652 Author:ykantser Date: 2013-02-07 11:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2de8c6c2d652 8007142: Add utility classes for writing better multiprocess tests in jtreg Reviewed-by: alanb, rbackman + test/lib/testlibrary/OutputAnalyzerTest.java

Re: RFR JDK-8007609

On 7/02/2013 9:49 PM, David Holmes wrote: On 7/02/2013 8:44 PM, Chris Hegarty wrote: On 02/06/2013 03:02 PM, Alan Bateman wrote: On 06/02/2013 14:57, John Zavgren wrote: Alan: I like your change, but I think the free(result) statement would need to be eliminated, otherwise the block a few line

Re: RFR JDK-8007609

On 7/02/2013 8:44 PM, Chris Hegarty wrote: On 02/06/2013 03:02 PM, Alan Bateman wrote: On 06/02/2013 14:57, John Zavgren wrote: Alan: I like your change, but I think the free(result) statement would need to be eliminated, otherwise the block a few lines later: /* Unable to get final path. */ if

Re: RFR JDK-8007609

On 02/06/2013 03:02 PM, Alan Bateman wrote: On 06/02/2013 14:57, John Zavgren wrote: Alan: I like your change, but I think the free(result) statement would need to be eliminated, otherwise the block a few lines later: /* Unable to get final path. */ if(len == 0 && result != NULL) { free(result);

Re: RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals

On 7 February 2013 07:32, Bruce Chapman wrote: > Stephen, In your case(s) would the workaround fail to work if the bug was > fixed? No. The workaround would handle the fixed implementation just fine. And all workarounds would ultimately be similar to mine. https://github.com/OpenGamma/OG-Platform