Joe, here's a fix for the stray double quote.
I've used {...@code with \u005C with the hope of making Ulf happy.
As usual, we'll need bug filed, etc...
diff --git a/src/share/classes/java/lang/Character.java
b/src/share/classes/java/lang/Character.java
--- a/src/share/classes/java/lang/Character
On Thu, Sep 3, 2009 at 18:37, Ulf Zibis wrote:
> Am 04.09.2009 00:15, Martin Buchholz schrieb:
> In Character class you have inserted a typo: '\u007f'" at method
> valueOf(char) (the additional " )
When you say "you", I assume you are using the "royal you".
That change was actually made by Joe Dar
Am 04.09.2009 00:15, Martin Buchholz schrieb:
On Thu, Sep 3, 2009 at 12:51, Ulf Zibis wrote:
Am 03.09.2009 20:10, Martin Buchholz schrieb:
I like to finish the Character class and file the changes via patch on
https://bugs.openjdk.java.net. So I would be happy If you could answer m
Martin Buchholz wrote:
The obvious alternative to built-in zlib
in the jdk is jzlib
http://www.jcraft.com/jzlib/
a pure-java implementation of zlib
under an apparently GPL-compatible license
that does support flush modes.
Some people are using it for that reason.
Non-scientific benchmarks at G
On 09/03/09 Martin Buchholz uttered the following other thing:
>
> ---
> 178 public int available() throws IOException {
> 179 ensureOpen();
> 180 if (reachEOF) {
> 181 return 0;
> 182 } else {
> 183 if (inf.needsInput())
> 184
The obvious alternative to built-in zlib
in the jdk is jzlib
http://www.jcraft.com/jzlib/
a pure-java implementation of zlib
under an apparently GPL-compatible license
that does support flush modes.
Some people are using it for that reason.
Non-scientific benchmarks at Google suggest
it is twice
On Thu, Sep 3, 2009 at 16:31, Xueming Shen wrote:
> Thanks for the comment. webrev has been updated accordingly. Flush class is
> a quick hack to verify the
> change, it needs to be auto run one if putback.
Perhaps you would like to take Brandon's test InflateIn_DeflateOut.java?
> We might want t
Thanks for the comment. webrev has been updated accordingly. Flush class
is a quick hack to verify the
change, it needs to be auto run one if putback.
We might want to separate the proposed "incompatible" change of
DOS.flush() into a separate rfe/bug,
if we can not have a consensus if we should
A related mini-rfe would be to provide access to zlib's deflateBounds
so that a caller can produce an appropriately sized buffer
for deflation.
Here are review comments on your webrev
http://cr.openjdk.java.net/~sherman/zipflush/webrev
---
308 * Returns actual number of bytes of compressed data.
=>
308 * Returns actual number of bytes of compressed data written
to the output buffer.
---
{...@linke needsInput() needsInput}
=
On 09/03/09 Xueming Shen uttered the following other thing:
>
> Same as the proposed spec/impl change to
> InflaterInputStream.isAvailable(), it is also a risky/incompatible
> change to override DeflaterOutputStream.flush() method to flush the
> underlying deflater. Existing apps
> that are usi
On 09/03/09 Martin Buchholz uttered the following other thing:
> The zlib and Deflater API is hard to understand.
> It seems to me that the proper place to specify the flushing behavior is
> when calling setInput, not when calling one of the deflate methods.
>
> I'm imagining something like
> setI
On Thu, Sep 3, 2009 at 12:51, Ulf Zibis wrote:
> Am 03.09.2009 20:10, Martin Buchholz schrieb:
> I like to finish the Character class and file the changes via patch on
> https://bugs.openjdk.java.net. So I would be happy If you could answer my
> question, if replacing all occurrences of ... by {..
Same as the proposed spec/impl change to
InflaterInputStream.isAvailable(), it is also a risky/incompatible
change to override DeflaterOutputStream.flush() method to flush the
underlying deflater. Existing apps
that are using DOS.flush() (directly or in-directly) will not be happy
to see the o
Am 03.09.2009 20:10, Martin Buchholz schrieb:
I agree that the spec can be clarified.
Another case is the similar
http://java.sun.com/javase/6/docs/api/java/lang/String.html#replace(char, char)
which states "Returns a new string", but then goes on to contradict itself,
although the meaning is c
Taking this discussion public.
It has happened that concurrently there are two fixes in progress
for long suffering RFE
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4206909
Given the number of votes and support in third party java zip
packages, jdk should certainly support it.
Sherman has
David Holmes - Sun Microsystems wrote:
Hi Mandy,
Mandy Chung said the following on 09/03/09 05:25:
This is related to 6857194: Add hotspot new perf counters to aid
class loading performance measurement.
It's useful to add performance counters in the library code so that
perf data from the JD
I agree that the spec can be clarified.
Another case is the similar
http://java.sun.com/javase/6/docs/api/java/lang/String.html#replace(char, char)
which states "Returns a new string", but then goes on to contradict itself,
although the meaning is clear.
Webrev please.
Martin
On Thu, Sep 3, 20
Alan Bateman wrote:
Mandy Chung wrote:
This is related to 6857194: Add hotspot new perf counters to aid
class loading performance measurement.
It's useful to add performance counters in the library code so that
perf data from the JDK and VM can be collected and output in a
unified way (writt
Hi
Guess you might be interested to help review the change for this RFE,
here is the webrev.
http://cr.openjdk.java.net/~sherman/6878475/webrev
Since this is an API update, the change will need to go through a review
process before it can
be integrated into the workspace, so it might take a
2009/9/3 Mandy Chung :
> Alan Bateman wrote:
>>
>> Andrew John Hughes wrote:
>>>
>>> :
>>> The use of synchronized at present seems flawed as only the set
>>> methods are protected and not the get. So lb.get could be called
>>> while in an lb.put call. I don't see the reason for using a
>>> LongB
Alan Bateman wrote:
Andrew John Hughes wrote:
:
The use of synchronized at present seems flawed as only the set
methods are protected and not the get. So lb.get could be called
while in an lb.put call. I don't see the reason for using a
LongBuffer either, as only index 0 is ever used. Why not
Andrew John Hughes wrote:
:
The use of synchronized at present seems flawed as only the set
methods are protected and not the get. So lb.get could be called
while in an lb.put call. I don't see the reason for using a
LongBuffer either, as only index 0 is ever used. Why not use an
AtomicLong?
2009/9/3 Rémi Forax :
> Le 03/09/2009 10:54, Alan Bateman a écrit :
>>
>> Mandy Chung wrote:
>>>
>>> This is related to 6857194: Add hotspot new perf counters to aid class
>>> loading performance measurement.
>>>
>>> It's useful to add performance counters in the library code so that perf
>>> data
Am 02.09.2009 22:29, Martin Buchholz schrieb:
On Wed, Sep 2, 2009 at 12:46, Ulf Zibis wrote:
Am 02.09.2009 19:11, David M. Lloyd schrieb:
On 09/02/2009 12:03 PM, Martin Buchholz wrote:
On Wed, Sep 2, 2009 at 09:40, David M. Lloyd mailto:[email protected]>> wrote:
Why n
Le 03/09/2009 11:56, Alan Bateman a écrit :
Rémi Forax wrote:
:
Hi Alan,
Classloading is now done in parallele, zip and jar can be loaded by
different threads.
"for the synchronization there are places where both a counter and an
elapsed time are updated"
=> the problem is that these synchro
Rémi Forax wrote:
:
Hi Alan,
Classloading is now done in parallele, zip and jar can be loaded by
different threads.
"for the synchronization there are places where both a counter and an
elapsed time are updated"
=> the problem is that these synchronisations are done on two
different monitors
Le 03/09/2009 10:54, Alan Bateman a écrit :
Mandy Chung wrote:
This is related to 6857194: Add hotspot new perf counters to aid
class loading performance measurement.
It's useful to add performance counters in the library code so that
perf data from the JDK and VM can be collected and output
Mandy Chung wrote:
This is related to 6857194: Add hotspot new perf counters to aid class
loading performance measurement.
It's useful to add performance counters in the library code so that
perf data from the JDK and VM can be collected and output in a unified
way (written in the jvmstat sha
29 matches
Mail list logo
