Alan,
I checked the httpsever and sctp changes. All look good to me.
-Chris.
On 10/06/2013 09:03 PM, Alan Bateman wrote:
As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported,
I'd like to have another attempt at adding the annotation to a number of
JDK specific APIs that are l
The JAAS and JGSS changes look fine too.
On 7 Oct 2013, at 09:23, Chris Hegarty wrote:
> Alan,
>
> I checked the httpsever and sctp changes. All look good to me.
>
> -Chris.
>
> On 10/06/2013 09:03 PM, Alan Bateman wrote:
>>
>> As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exp
Hi Alan,
The com.sun.management changes look good.
-- daniel
On 10/6/13 10:03 PM, Alan Bateman wrote:
As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported,
I'd like to have another attempt at adding the annotation to a number of
JDK specific APIs that are long standing export
On 10/6/2013 1:03 PM, Alan Bateman wrote:
The webrev with the proposed update is here:
http://cr.openjdk.java.net/~alanb/8008662/webrev.02/
I went through the entire webrev and the change looks good.
For the review then the intention is that @jdk.Exported be added to
the package-info a
Changeset: 0ac9dc315071
Author:alanb
Date: 2013-10-07 11:48 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ac9dc315071
8025983: Typo in Javadoc of Files.isRegularFile()
Reviewed-by: mchung, chegar
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/fil
On 07/10/2013 11:31, Mandy Chung wrote:
:
For the review then the intention is that @jdk.Exported be added to
the package-info and all public/protected types in these APIs. The
only exceptions are two cases where I've added @jdk.Exported(false),
specifically:
- com.sun.management.OSMBeanF
7 classes in com.sun.security.auth have been deprecated for several
major releases now. Should they still have this annotation?
--Sean
On 10/06/2013 04:03 PM, Alan Bateman wrote:
As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported,
I'd like to have another attempt at adding
On 07/10/2013 13:26, Sean Mullan wrote:
7 classes in com.sun.security.auth have been deprecated for several
major releases now. Should they still have this annotation?
--Sean
I know but aren't they still exported and supported?
DialogCallbackHandler is the only one with its name on a bullet.
On 10/07/2013 08:28 AM, Alan Bateman wrote:
On 07/10/2013 13:26, Sean Mullan wrote:
7 classes in com.sun.security.auth have been deprecated for several
major releases now. Should they still have this annotation?
--Sean
I know but aren't they still exported and supported?
They have all had AP
On 07/10/2013 13:36, Sean Mullan wrote:
We have only started removing some deprecated things in JDK, so it
just was never thought about until now. Marking these as supported
going forward strikes me as a bit strange, since we don't really want
anyone using these anymore.
As a guide, I think w
On 10/07/2013 08:58 AM, Alan Bateman wrote:
On 07/10/2013 13:36, Sean Mullan wrote:
We have only started removing some deprecated things in JDK, so it
just was never thought about until now. Marking these as supported
going forward strikes me as a bit strange, since we don't really want
anyone
The test captures the number of loaded classes right at the start and
then checks the diffs when it's finished. However, it seems that there
might by some async class loading still going on, initiated by JFR.
The patch simply adds a loop to wait for the number of loaded classes to
settle befor
On 19.9.2013 16:33, Jaroslav Bachorik wrote:
The updated webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03
I've moved some of the functionality to the testlibrary.
-JB -
On 12.9.2013 17:31, Jaroslav Bachorik wrote:
On 09/12/2013 05:13 PM, Dmitry Samersoff wrote:
Jaroslav,
Cust
Hi Jaroslav,
I am not an expert in classloading but I don't see any obvious
issue with what you propose.
I wonder whether making the test always run in /othervm mode
might make it more stable.
best regards,
-- daniel
On 10/7/13 3:59 PM, Jaroslav Bachorik wrote:
The test captures the number o
Jarsolav,
Looks good for me, comments below is just a nits - so fill free to
ignore it.
1.
As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for
findLibjvm parameter, It's better to create an overload function
findLibjvm().
2.
it's better to check for File.isFile() - readable (e.g
On 7.10.2013 16:22, Daniel Fuchs wrote:
Hi Jaroslav,
I am not an expert in classloading but I don't see any obvious
issue with what you propose.
I hope there is none :) If the number of loaded classes is not changing
the test should continue immediately. The only problem could be loading
the
This will make it less likely for the test to fail, but does not guarantee it
since there is nothing that says classloading will be done in 300 ms. Any
failures will unfortunately be harder to reproduce. (And the test is now 300 ms
slower to run.)
A different solution is to only allow the numbe
I don't think the test should run with JFR enabled. I would ask SQE not
to run unit tests with JFR and only add /othervm.
Erik
Jaroslav Bachorik skrev 10/7/13 3:59 PM:
The test captures the number of loaded classes right at the start and
then checks the diffs when it's finished. However, it se
On 7.10.2013 16:31, Dmitry Samersoff wrote:
Jarsolav,
Looks good for me, comments below is just a nits - so fill free to
ignore it.
1.
As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for
findLibjvm parameter, It's better to create an overload function
findLibjvm().
Ok. It wil
Jaroslav,
> Can you elaborate why checking for the current user being able to read
> the actual library file might be wrong?
It's not applicable to this particular testcase (so I'd marked it as a
nit) but a generic security rule is to always check that we deal with a
regular file.
Try to link an
On 7.10.2013 18:47, Dmitry Samersoff wrote:
Jaroslav,
Can you elaborate why checking for the current user being able to read
the actual library file might be wrong?
It's not applicable to this particular testcase (so I'd marked it as a
nit) but a generic security rule is to always check that
I agree with Erik.
It is better to just exclude this test from run with JFR enabled.
Adding /othervm should probably solve the problem.
Thanks,
Serguei
On 10/7/13 9:01 AM, Erik Gahlin wrote:
I don't think the test should run with JFR enabled. I would ask SQE
not to run unit tests with JFR and
On 7.10.2013 16:31, Dmitry Samersoff wrote:
Jarsolav,
Looks good for me, comments below is just a nits - so fill free to
ignore it.
1.
As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for
findLibjvm parameter, It's better to create an overload function
findLibjvm().
2.
it's bet
Jaroslav,
Thumbs up!
Thank you for addressing my comments.
-Dmitry
On 2013-10-07 21:10, Jaroslav Bachorik wrote:
> On 7.10.2013 16:31, Dmitry Samersoff wrote:
>> Jarsolav,
>>
>> Looks good for me, comments below is just a nits - so fill free to
>> ignore it.
>>
>> 1.
>> As FS.getPath(TEST_JDK,
Changeset: f0ad3e2918b4
Author:henryjen
Date: 2013-10-07 11:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ad3e2918b4
8025968: Integrate test improvements made in lambda repo
Reviewed-by: psandoz
! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
!
test/j
Changeset: ac9cb1d5a202
Author:acorn
Date: 2013-10-07 12:20 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ac9cb1d5a202
8009130: Lambda: Fix access controls, loader constraints.
Summary: New default methods list with inherited superinterface methods
Reviewed-by: mi
Hello,
I skimmed the patch and it looked fine.
More generally, we want every package and top-level class in the
com.sun.* namespace to be either explicitly exported or not.
Cheers,
-Joe
On 10/6/2013 1:03 PM, Alan Bateman wrote:
As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.
Changeset: 0cffe1dab0bf
Author:henryjen
Date: 2013-10-07 15:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cffe1dab0bf
8026009: Changes for 8025968 break all stream tests
Reviewed-by: mduigou
! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
Changeset: 4dd7ffbf01fb
Author:darcy
Date: 2013-10-07 16:51 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4dd7ffbf01fb
8026017: Make history of AnnotatedConstruct methods in jx.l.m.e.Element clearer
Reviewed-by: jjg
! src/share/classes/javax/lang/model/element/Element
Changeset: 0d5f4f1782e8
Author:xuelei
Date: 2013-10-07 18:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d5f4f1782e8
6956398: make ephemeral DH key match the length of the certificate key
Reviewed-by: weijun
! src/share/classes/sun/security/ssl/ServerHandshaker.java
+
t
Jaroslav,
Can you summarise the changes please? With the conversion to Java and
the infrastructure additions I can't tell what is actually fixing the
original timeout issue :)
Thanks,
David
On 8/10/2013 12:14 AM, Jaroslav Bachorik wrote:
On 19.9.2013 16:33, Jaroslav Bachorik wrote:
The upd
As I wrote in the bug report I have reservations about this as these are
launcher options not VM options. Plus with the dropping of 32-bit
Solaris the -d32/-d64 part will be moot. That leaves the VM "mode" -
client, server, minimal or whatever might happened to be defined via
jvm.cfg (-server m
32 matches
Mail list logo
