Thanks for the feedback Brian and Rémi.
I'm assuming this would go into JDK 8 at the earliest, so there seems
to be some time to build out the test cases and other related missing
methods. Are JUnit tests acceptable (I see only a couple in
jdk/test/java/dyn/) or would you prefer the standalone tes
于 2011-1-26 0:19, Alan Bateman 写道:
Jing LV wrote:
Hello,
I find a problem in java.io.BufferedWriter. It is stated in the java
spec of its close() method:
"... Once the stream has been closed, further write() or flush()
invocations will cause an IOException to be thrown."
However if a BufferedWr
Rémi Forax said the following on 01/27/11 18:43:
On 01/27/2011 09:38 AM, Stephen Colebourne wrote:
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
I think we can't.
This method is already used at many place in the JDK.
I think we can. Those usages w
Hi David,
On 01/27/2011 06:27 PM, Brian Goetz wrote:
Overall these look like good additions. I haven't reviewed the code
in detail but a quick sanity check suggests that this is a good
direction. There's definitely some more work needed on the testing
(for example, testing that the contents
Overall these look like good additions. I haven't reviewed the code in
detail but a quick sanity check suggests that this is a good direction.
There's definitely some more work needed on the testing (for example,
testing that the contents of x and unmodifiable(x) are identical,
testing that t
> > About the name, I propose:
> > iUsedToUseGetClassHereButNodobyWasAbleToUnderstand()
>
> But there are two methods we want to rename this to, and we can't use
> this name twice. I propose we generate random method names instead.
You don't want to violate trademarks either.
How about 'vetoN
About the name, I propose:
iUsedToUseGetClassHereButNodobyWasAbleToUnderstand()
But there are two methods we want to rename this to, and we can't use
this name twice. I propose we generate random method names instead.
On 26 January 2011 01:57, Joshua Bloch wrote:
> I have serious reservations about this. It would be the first time (to my
> knowledge) that we deliberately swept a concurrent modification under the
> rug. If we go to the effort of detecting it (which you're doing), the least
> we should do is to
On 01/27/2011 09:38 AM, Stephen Colebourne wrote:
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
I think we can't.
This method is already used at many place in the JDK.
About the name, I propose:
iUsedToUseGetClassHereButNodobyWasAbleToUnderstand()
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
On 27 January 2011 05:05, wrote:
> Executive summary: requireNonNull is the preferred name.
>
>> Date: Tue, 25 Jan 2011 18:33:47 -0500
>> From: brian.go...@oracle.com
>
>> mark.reinh...@oracle.com wrote:
10 matches
Mail list logo
