This looks fine to me too ( removal of streams usage and JRT, for 7uXX )..
-Chris.
On 9 Jan 2015, at 11:07, Seán Coffey wrote:
> Thanks for reviewing Daniel. I'm mark you as author. If I can get a jdk7u
> Reviewer to review, I'll push this.
> Will update copyright before pushing also.
>
> reg
Thanks for reviewing Daniel. I'm mark you as author. If I can get a
jdk7u Reviewer to review, I'll push this.
Will update copyright before pushing also.
regards,
Sean.
On 08/01/15 14:55, Daniel Fuchs wrote:
Hi Seán,
Thanks for taking care of that :-)
It looks good to me. You might want to se
Hi Seán,
Thanks for taking care of that :-)
It looks good to me. You might want to set the copyright year to 2015.
Best regards,
-- daniel
On 08/01/15 15:41, Seán Coffey wrote:
I've taken suggested test code from Daniel and am looking to backport
8066612 to jdk7u-dev. The test differs slightl
I've taken suggested test code from Daniel and am looking to backport
8066612 to jdk7u-dev. The test differs slightly in that it used the
non-lambda approach (ClassNameListBuilder)
I've reduced the number of run counts also (one ovm run for secure and
one for non-secure mode) - As a result and
Hi Daniel,
Thumbs up from me!
Thanks,
David
On 16/12/2014 8:36 PM, Daniel Fuchs wrote:
On 16/12/14 11:34, Daniel Fuchs wrote:
Here is a new version where I have removed all the 'ClassLoaders' stuff.
After all
it was not instrumental to the test. Is that good to go?
Forgot the link:
http://
On 16/12/14 11:34, Daniel Fuchs wrote:
Here is a new version where I have removed all the 'ClassLoaders' stuff.
After all
it was not instrumental to the test. Is that good to go?
Forgot the link:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.03/
sorry for the noise.
-- daniel
Hi David,
On 12/16/14 6:20 AM, David Holmes wrote:
On 16/12/2014 3:48 AM, Daniel Fuchs wrote:
Hi guys,
Do I have approval to push the latest version of the test for JDK 9:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
or are there still some objections?
My objections stan
On 16/12/2014 3:48 AM, Daniel Fuchs wrote:
Hi guys,
Do I have approval to push the latest version of the test for JDK 9:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
or are there still some objections?
My objections stand - the classloader aspect of the test is overly
com
On 15/12/2014 17:48, Daniel Fuchs wrote:
Hi guys,
Do I have approval to push the latest version of the test for JDK 9:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
or are there still some objections?
I'm fine with the test Daniel (as before) - it's a long-life test that
ca
Hi guys,
Do I have approval to push the latest version of the test for JDK 9:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
or are there still some objections?
best regards,
-- daniel
On 06/12/14 11:44, Daniel Fuchs wrote:
Hi Peter,
On 12/6/14 11:16 AM, Peter Levart wro
Hi Daniel,
On 6/12/2014 6:06 AM, Daniel Fuchs wrote:
Hi David, all,
@David: You're right David.
The loader parameter is never used - I have removed it.
But you still have extraneous loader related stuff that doesn't actually
achieve anything. getClassLoaderFor(s) is not needed. Clas
Hi Peter,
On 12/6/14 11:16 AM, Peter Levart wrote:
On 12/05/2014 09:06 PM, Daniel Fuchs wrote:
Hi David, all,
@David: You're right David.
The loader parameter is never used - I have removed it.
@all: I have received a comment from Alan that it would be better to use
the new jr
On 12/05/2014 09:06 PM, Daniel Fuchs wrote:
Hi David, all,
@David: You're right David.
The loader parameter is never used - I have removed it.
@all: I have received a comment from Alan that it would be better to use
the new jrt:/ FileSystem directly, rather than using private API
Hi David, all,
@David: You're right David.
The loader parameter is never used - I have removed it.
@all: I have received a comment from Alan that it would be better to use
the new jrt:/ FileSystem directly, rather than using private APIs.
One of the consequence is that the te
Hi Daniel,
I still find your use of the classloader very confusing. You talk about
the defining loader but you never check the defining loader against
anything. In
146 static void checkFor(Class c, ClassLoader loader) {
the loader variable is never used. And if loader is simply the
On 04/12/14 14:02, Seán Coffey wrote:
Thanks for driving efforts in this area Daniel. I think it's a very
useful test and is bound to help test code coverage. If it's currently
passing on all JPRT platforms, it's a good measure.
It seems to :-)
Eventually I think we can bulk up the tests that
Thanks for driving efforts in this area Daniel. I think it's a very
useful test and is bound to help test code coverage. If it's currently
passing on all JPRT platforms, it's a good measure.
Eventually I think we can bulk up the tests that can be run on the
Iterable returned from your class se
On 04/12/14 13:06, David Holmes wrote:
Hi Daniel,
On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
Hi David,
In fact I could use 'null' on JDK 9 as well.
My first version of the JDK 9 test was parsing over all the .jimage
files under /lib/modules - which explain why I needed to
use the System class l
Hi Daniel,
On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
Hi David,
In fact I could use 'null' on JDK 9 as well.
My first version of the JDK 9 test was parsing over all the .jimage
files under /lib/modules - which explain why I needed to
use the System class loader.
Then I switched to only parsing
Hi Daniel,
On 4/12/2014 7:05 PM, Daniel Fuchs wrote:
On 12/4/14 4:37 AM, David Holmes wrote:
Once clarification please ...
On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
Hi,
This is a review for a new test which has a different
implementation for JDK 8 & JDK 9
During the review of
JDK-8065552:
Hi David,
In fact I could use 'null' on JDK 9 as well.
My first version of the JDK 9 test was parsing over all the .jimage
files under /lib/modules - which explain why I needed to
use the System class loader.
Then I switched to only parsing the bootmodules.jimage - because
I noticed that the res
Hi David,
On 12/4/14 4:37 AM, David Holmes wrote:
Hi Daniel,
Once clarification please ...
On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
Hi,
This is a review for a new test which has a different
implementation for JDK 8 & JDK 9
During the review of
JDK-8065552: setAccessible(true) on fields of
Hi Daniel,
Once clarification please ...
On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
Hi,
This is a review for a new test which has a different
implementation for JDK 8 & JDK 9
During the review of
JDK-8065552: setAccessible(true) on fields of Class may throw
a SecurityException,
i
Hi,
This is a review for a new test which has a different
implementation for JDK 8 & JDK 9
During the review of
JDK-8065552: setAccessible(true) on fields of Class may throw
a SecurityException,
it was remarked that such a test would be useful.
So here is such a test that loads all
24 matches
Mail list logo