Changeset: da8b8ee281f9
Author:xuelei
Date: 2012-02-10 22:17 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da8b8ee281f9
7144781: incorrect URLs in JSSE java doc
Reviewed-by: wetmore, skannan
! src/share/classes/javax/net/ssl/ExtendedSSLSession.java
! src/share/classes/javax
Changeset: b16cbeb0d213
Author:wetmore
Date: 2012-02-10 19:07 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b16cbeb0d213
7142509: Cipher.doFinal(ByteBuffer,ByteBuffer) fails to process when
in.remaining() == 0
Reviewed-by: valeriep
! src/share/classes/javax/crypto/CipherSp
It sounds very reasonable when you put it that way ;-)
I was thinking along the lines of when flush() fails - clearly you
can't flush a stream when it is closed - then it should throw an
IOException. =
Either way - I will sleep some more on my code and work around this in JDK8.
Thank you and Ala
On 2/10/2012 12:31 AM, Masayoshi Okutsu wrote:
I tend to agree with Sherman that the real problem is the
OutputStreamWriter API which isn't good enough to handle various
encodings. My understanding is that the charset API was introduced in
1.4 to deal with the limitations of the java.io and o
Changeset: 5f3fcd591768
Author:amurillo
Date: 2012-01-20 17:07 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f3fcd591768
7131979: new hotspot build - hs23-b12
Reviewed-by: jcoomes
! make/hotspot_version
Changeset: 53a127075045
Author:kvn
Date: 2012-01-20 09:4
Changeset: 8da468cf037b
Author:katleman
Date: 2012-02-02 09:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8da468cf037b
Added tag jdk8-b24 for changeset 34029a0c69bb
! .hgtags
Changeset: ad9f1c8970da
Author:prr
Date: 2012-01-19 12:41 -0800
URL: http://hg.o
Changeset: b376d901e006
Author:katleman
Date: 2012-02-02 09:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b376d901e006
Added tag jdk8-b24 for changeset e0d90803439b
! .hgtags
Changeset: 3518639eab6c
Author:katleman
Date: 2012-02-09 12:55 -0800
URL: http
Changeset: 5350cd6e0cc0
Author:katleman
Date: 2012-02-02 09:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/5350cd6e0cc0
Added tag jdk8-b24 for changeset 1a5f1d6b98d6
! .hgtags
Changeset: 221a378e06a3
Author:lana
Date: 2012-02-07 10:36 -0800
URL: http://hg.open
Changeset: 5a784dab75f1
Author:katleman
Date: 2012-02-02 09:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5a784dab75f1
Added tag jdk8-b24 for changeset 6c9d21ca92c4
! .hgtags
Changeset: 520c30f85bb5
Author:lana
Date: 2012-02-07 10:39 -0800
URL: http
Changeset: bb694c151fc7
Author:katleman
Date: 2012-02-02 09:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bb694c151fc7
Added tag jdk8-b24 for changeset 7836655e2495
! .hgtags
Changeset: dbb7283c197b
Author:katleman
Date: 2012-02-09 12:55 -0800
URL: http:
Changeset: e45d6b406d5f
Author:katleman
Date: 2012-02-02 09:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e45d6b406d5f
Added tag jdk8-b24 for changeset b98f0e6dddf9
! .hgtags
Changeset: 79f709a099f4
Author:katleman
Date: 2012-02-09 12:55 -0800
URL: http
Hello,
Please review fix for :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131266
The gist of the problem being addressed, the specimen jar contains
two versions of class file implementations with the same package names,
this tends to confuse the pack200 mechanism causing it to fire as
On 10/02/2012 13:16, Alex Lam S.L. wrote:
To recover the previous behaviour, I think the following might just work:
try (OutputStream ostream = out) {
flush();
} catch (IOException ignored) {
}
Remember try-with-resource-catch works the inside-out from
try-catch-finally! You are discardin
It is a custom OutputStream class which is not part of the JDK.
In this case close() is being called multiple times, because there are
actions which relies it. And flush() will throw IOException if the
stream is already closed.
I guess I can work around this by introducing a boolean flag to track
On 02/10/2012 02:52 PM, Alex Lam S.L. wrote:
Hi there,
Thanks for the pointer - I wasn't able to trace back to that email for
some reasons.
The problem is that:
- flush() is reporting IOException because underlying stream is closed
- close() is then forwarding that IOException now in JavaS
On 10/02/2012 13:52, Alex Lam S.L. wrote:
Hi there,
Thanks for the pointer - I wasn't able to trace back to that email for
some reasons.
The problem is that:
- flush() is reporting IOException because underlying stream is closed
- close() is then forwarding that IOException now in JavaSE 8
Hi there,
Thanks for the pointer - I wasn't able to trace back to that email for
some reasons.
The problem is that:
- flush() is reporting IOException because underlying stream is closed
- close() is then forwarding that IOException now in JavaSE 8
I guess my question is: what is the best way
On 02/10/12 03:58 AM, Michael Barker wrote:
Hi Stuart,
Thank you for the reviewing the patches. I forgot about the
Contributed-by header, sorry about that. That's one I'll put on the
list to make sure I have sorted next time. I've split the
contributors up according to the two patches supplie
I think I have narrowed it down to this changeset:
http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/759aa847dcaf
7015589: (spec) BufferedWriter.close leaves stream open if close of
underlying Writer fails
Which no longer catches and ignores the exception thrown by flush():
try (OutputStream os
Hi there,
I have some code which calls FilterOutputStream.close(), which calls
the underlying OutputStream.flush() which throws IOException.
With previous versions of JavaSE, close() returns successfully without
any problems.
Using JDK8-b24, I get an IOException which is propagated from flush().
I agree with the fix.
In test/java/io/OutputStreamWriter/Flush.java I suggest:
a) As all values are positive, following would be better readable:
byte[] bytes = new byte[] {0x1b, 0x24, 0x42, 0x3a, 0x47, 0x1b, 0x28, 0x42};
... or remember the format rule - which I still don't like - to insert
I tend to agree with Sherman that the real problem is the
OutputStreamWriter API which isn't good enough to handle various
encodings. My understanding is that the charset API was introduced in
1.4 to deal with the limitations of the java.io and other encoding
handling issues.
I still don't th
22 matches
Mail list logo
