On 21 Jan 2015, at 22:37, Nathan Clement nathan.a.clem...@hotmail.com wrote:
Hi Chris,
Thanks for your help on this one! Will this be backported to JDK 8, or is
that not allowed because of the spec change?
It is possible that the implementation only, not the spec changes, could be
Hi Chris,
We have worked around the problem by using a small jar in our bootstrap
classpath (now containing your updated code). From our perspective there's
probably no pressing need to have the fix backported.
Thanks,
Nathan
Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may
Hi Chris,
Thanks for your help on this one! Will this be backported to JDK 8, or is that
not allowed because of the spec change?
Thanks,
Nathan
Date: Mon, 22 Dec 2014 14:13:18 +
From: chris.hega...@oracle.com
To: core-libs-dev@openjdk.java.net; nathan.a.clem...@hotmail.com
Subject:
To close the loop; find below the complete reviewed changes.
http://cr.openjdk.java.net/~chegar/8054565/webrev.00/webrev/
Since there is a minor spec change, I will submit a CCC to cover it.
Unless any unforeseen issues arise from the CCC, you can assume that
this is final.
-Chris.
On 15/12/14 05:21, Nathan Clement wrote:
Hi,
What's the process for finalizing a decision and getting this bug fixed?
Apologies if I'm violating a social norm by asking this - I'm new to
this process and I'm not sure exactly how decisions are made.
You are not violating anything, and it is
Hi,
What's the process for finalizing a decision and getting this bug fixed?
Apologies if I'm violating a social norm by asking this - I'm new to this
process and I'm not sure exactly how decisions are made.
Thanks,
Nathan
From: nathan.a.clem...@hotmail.com
To: chris.hega...@oracle.com;
Hi,
I'd be happy with any of the solutions discussed here. In our case, we're only
calling close() multiple times as a result of the way that try-with-resources
works with wrapped streams.
Thanks,
Nathan
Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may throw
IOException if
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug should only try to address the change in behavior that
was inadvertently introduced by 7015589[1][2].
I don't see any reason to make 'closed' protected ( part of the public
Java SE API ), something like:
On 12/05/2014 03:04 PM, Chris Hegarty wrote:
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug should only try to address the change in behavior that
was inadvertently introduced by 7015589[1][2].
What about the following:
private boolean closed;
public
On 05/12/14 14:40, Peter Levart wrote:
On 12/05/2014 03:04 PM, Chris Hegarty wrote:
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug should only try to address the change in behavior that
was inadvertently introduced by 7015589[1][2].
What about the
Or, maybe a 3rd, more refined variant:
private boolean closed;
public void close() throws IOException {
Exception exc = null;
try {
flush();
} catch (IOException | RuntimeException e) {
if (!closed) exc = e;
}
try {
On 05/12/2014 14:04, Chris Hegarty wrote:
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug should only try to address the change in behavior that
was inadvertently introduced by 7015589[1][2].
I don't see any reason to make 'closed' protected ( part of the
On 05/12/14 15:33, Alan Bateman wrote:
On 05/12/2014 14:04, Chris Hegarty wrote:
...
Right, no need for it to be protected. I think what you have seems right
but we probably need a small spec clarification so that it reads When
not already closed, the close method of FilterOutputStream
On 5 Dec 2014, at 17:44, Peter Levart peter.lev...@gmail.com wrote:
On 12/05/2014 04:09 PM, Chris Hegarty wrote:
On 05/12/14 14:40, Peter Levart wrote:
On 12/05/2014 03:04 PM, Chris Hegarty wrote:
On 05/12/14 11:38, Pavel Rappo wrote:
+1, I couldn’t say better
Right. This bug
Hi Nathan,
This list removes attachments.
Can the diff's be inlined in the email?
Thanks, Roger
On 12/4/2014 1:18 AM, Nathan Clement wrote:
Hi,
Here is my suggested fix for the FilterOuputStream issue in JDK-8054565. I
have been running this fix in my applications for several weeks (by
Hi,
My apologies - the page http://openjdk.java.net/contribute/ gave me the
impression that I could send the diff as an attachment. I've included it
inline below.
Regards,
Nathan
diff --git a/src/share/classes/java/io/FilterOutputStream.java
Hello,
also using a stream in a multi threaded way is quite unusual most of
the implementations I have seen use a atomic solution. This makes
sense considering the fact that especially the close() might be called
by a timeout/cleanup/finalizer/timer/shutdown thread. Using a
AtomicUpdater would
Hello,
also using a stream in a multi threaded way is quite unusual most of
the implementations I have seen use a atomic solution.
Bernd, as far as I understand we are not talking about concurrent-proof solution
for the j.i.FilterOutputStream as this class is sure not even thread-safe. Most
Hi,
My problem is definitely not related to multi-threaded use. The test shows
basically the same code that we have in production that experienced the
problem. The stream is used from a single thread in a try-with-resources block.
I don't see that this change is any more risky than the
Am Thu, 4 Dec 2014 23:54:10 +
schrieb Pavel Rappo pavel.ra...@oracle.com:
Bernd, as far as I understand we are not talking about
concurrent-proof solution for the j.i.FilterOutputStream as this
class is sure not even thread-safe.
It is used very much, also in concurrent context. As I
Am Fri, 5 Dec 2014 11:49:26 +1100
schrieb Nathan Clement nathan.a.clem...@hotmail.com:
Hi,
My problem is definitely not related to multi-threaded use. The test
shows basically the same code that we have in production that
experienced the problem.
Of course it can be triggered single
But where does it say that this class can be used in a concurrent context?
This class is documented as serving a base class role, yes, but it has
state. It's the user/subclass responsibility to provide threadsafety, as
far as I see. Attempting to make close() atomic just makes the next reader
Hi Bernd,
My problem is definitely not related to multi-threaded use. The test
shows basically the same code that we have in production that
experienced the problem.
Of course it can be triggered single threaded. But this does not mean
you should not fix it for concurrent use as well
23 matches
Mail list logo
