Hi Alan,
Where would you suggest to put such methods though? Should we aim for a
„IOUitls" class holding such methods in the first place and eventually place
some simple convenience methods on Input-/OutputStream and Reader/Writer?
I personally would do both, because I think it would make the u
Hi Joel, Joe, Paul,
I'd like you to do a code review.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-volatile/
https://bugs.openjdk.java.net/browse/JDK-8064846
Looks like the only comment we have is to change 2013 year to 2014 in
the Copyright header in new files (and keep creation year from old file
as Joe suggested).
I can do that trivial change and push these changes into aarch64 staging
repo.
webrev: http://cr.openjdk.java.net/~aph/aarch64-JDK-
On 13/11/2014 19:31, Patrick Reinhart wrote:
Hi there,
In the followup of a BOF with Stephen Colebourne with his ideas of small
library changes that may could get in JDK9. As of the fact that in the codebase
of my company there are several locations where we copy from/to IO stream over
and ov
On Nov 13, 2014, at 11:31 AM, Patrick Reinhart wrote:
> Hi there,
>
> In the followup of a BOF with Stephen Colebourne with his ideas of small
> library changes that may could get in JDK9. As of the fact that in the
> codebase of my company there are several locations where we copy from/to IO
Hi there,
In the followup of a BOF with Stephen Colebourne with his ideas of small
library changes that may could get in JDK9. As of the fact that in the codebase
of my company there are several locations where we copy from/to IO stream over
and over again using either external libraries or do
Looks good!
On Thu, Nov 13, 2014 at 8:47 AM, Martin Buchholz wrote:
> You should delete your import
>
> 36 import java.lang.IllegalStateException;
>
> ---
>
> I would bump up the time you're willing to wait here, by at least 10x.
>
> 2277 if ((end - start) > 2L * (AIX.is() ?
Hi,
Thank you for you patience.
On 11/13/2014 11:47 AM, Martin Buchholz wrote:
You should delete your import
36 import java.lang.IllegalStateException;
---
I would bump up the time you're willing to wait here, by at least 10x.
2277 if ((end - start) > 2L * (AIX.is() ?
You should delete your import
36 import java.lang.IllegalStateException;
---
I would bump up the time you're willing to wait here, by at least 10x.
2277 if ((end - start) > 2L * (AIX.is() ? 2 : 1))
2278 fail("Test failed: waitFor took too long (" +
(end - s
Please re-review,
Corrected the webrev, and a few changes to consistently use the same
units, thanks for the review:
The timeout time is extended to wait up to 7 seconds
and the initial waitFor should last at least 1 second.
http://cr.openjdk.java.net/~rriggs/webrev-basic-debug-8043477/
Roger
Hi Peter,
Yes, please file a separate issue and a RFR.
cheers
/Joel
On 10 nov 2014, at 17:13, Peter Levart wrote:
> On 11/07/2014 11:48 PM, Martin Buchholz wrote:
>> Hi Joel,
>>
>> Thanks for volunteering. I foisted all I have in
>>
>> https://bugs.openjdk.java.net/browse/JDK-8064391
>>
>>
Hi Martin,
Since you have already provided us with the patch here:
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/Class-thread-safety/
Lets do it the other way around. I think this is a very good fix for 8u,
reviewed.
I'll start the backporting approval with you as the provider of the fix
a
Kindly reminder.
On 10.11.2014 17:45, Konstantin Shefov wrote:
Vladimir, thanks for reviewing
I have updated the webrev:
http://cr.openjdk.java.net/~kshefov/8059070/webrev.02
I have added DEFAULT_TEST_TIMEOUT constant to Utils class.
-Konstantin
On 10.11.2014 14:33, Vladimir Ivanov wrote:
Hi Joe and All
I revised the code based on latest comments and put the webrev on
http://cr.openjdk.java.net/~joehw/jdk9/test/Frank/8043090/webrev/
Best Regards
Frank
-Original Message-
From: Frank Yuan [mailto:frank.y...@oracle.com]
Sent: Wednesday, November 05, 2014 5:12 PM
To: 'huizhe
Hi Peter,
As always, thanks for taking a look at this,
This is quite big so in order to make this more approachable perhaps you can
split the patch up into a series? If you start with creating the MethodTable
interface, adding tests for how the interface should behave and refactored the
curren
On 11/12/2014 07:27 PM, David Chase wrote:
Hello Peter,
Sadly, this seems not to be the case for MemberNames or for “Types”.
That statement is inoperative. Mistakes were made.
It’s compareTo that they lack.
Yes, I say your quite tricky implementation of MemberName.compareTo,
based on hash
16 matches
Mail list logo
