On 7 February 2013 07:32, Bruce Chapman brucechap...@paradise.net.nz 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.
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);
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. */
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
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
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 *
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
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
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
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
On Thu, Feb 7, 2013 at 8:49 AM, Chris Hegarty chris.hega...@oracle.comwrote:
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.
On Thu, Feb 7, 2013 at 8:15 AM, Alan Bateman alan.bate...@oracle.comwrote:
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/**
On Thu, Feb 7, 2013 at 9:49 AM, Alan Bateman alan.bate...@oracle.comwrote:
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
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
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
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
Hi,
8007572: Replace existing jdk timezone data at java.home/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 java.home/lib/zi for
j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own
time zone
On Thu, Feb 7, 2013 at 1:32 PM, Martin Buchholz marti...@google.com wrote:
It's probably a bug, but ...
- it would help to have a clear reproducible test case
dd if=your favorite hard disk node, e.g. /dev/sda1 of=data bs=1G count=12
jar cvf data.jar data
[get a cup of your favorite hot
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,
On Thu, Feb 7, 2013 at 3:11 PM, Xueming Shen xueming.s...@oracle.com 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
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 looks
On Thu, Feb 7, 2013 at 3:23 PM, Xueming Shen xueming.s...@oracle.com 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).
$
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
On Thu, Feb 7, 2013 at 3:33 PM, Alexander Sack pisym...@gmail.com wrote:
On Thu, Feb 7, 2013 at 3:23 PM, Xueming Shen xueming.s...@oracle.com 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
On Thu, Feb 7, 2013 at 3:36 PM, Kumar Srinivasan
kumar.x.sriniva...@oracle.com 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
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
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.
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.
The find() method uses a
BiPredicatePath, BasicFileAttributes 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
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 PredicatePath, developer can easily use that in a
filter with walk, which return a StreamPath.
Hope that helps.
Cheers,
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:
On Thu, Feb 7, 2013 at 10:45 PM, Henry Jen henry@oracle.com 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 PredicatePath, developer can easily use that in
a
Hi Martin,
On 02/07/2013 10:29 AM, Martin Buchholz wrote:
On Thu, Feb 7, 2013 at 9:49 AM, Alan Bateman alan.bate...@oracle.comwrote:
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
33 matches
Mail list logo
