Hi Alan,
On 12/03/2013 8:05 PM, Alan Bateman wrote:
On 12/03/2013 07:10, David Holmes wrote:
:
For the intro comment in profile-rtjar-includes.txt then it might be
useful to beef up the comment to explain what happens when an API
package does not match one of the rules, ie: does it go into co
The langtools changes look OK to me.
-- Jon
On 03/10/2013 06:24 PM, David Holmes wrote:
I had overlooked the need to update the ct.sym creation tool to
recognize the new syntax in the profile spec file. That process also
uncovered a few bugs in the listing that needed correcting.
The javadoc
On 12/03/2013 07:10, David Holmes wrote:
:
For the intro comment in profile-rtjar-includes.txt then it might be
useful to beef up the comment to explain what happens when an API
package does not match one of the rules, ie: does it go into compact1,
only the full JRE, or none. Also make it expli
Hi Alan,
On 11/03/2013 6:54 PM, Alan Bateman wrote:
On 11/03/2013 01:24, David Holmes wrote:
I had overlooked the need to update the ct.sym creation tool to
recognize the new syntax in the profile spec file. That process also
uncovered a few bugs in the listing that needed correcting.
The java
On 11/03/2013 01:24, David Holmes wrote:
I had overlooked the need to update the ct.sym creation tool to
recognize the new syntax in the profile spec file. That process also
uncovered a few bugs in the listing that needed correcting.
The javadoc generation of compact profile information is not
I had overlooked the need to update the ct.sym creation tool to
recognize the new syntax in the profile spec file. That process also
uncovered a few bugs in the listing that needed correcting.
The javadoc generation of compact profile information is not quite
right, but that will be handled in
On 08/03/2013 11:28, David Holmes wrote:
Now I'm a little concerned. I had not considered whether javac/javadoc
considered these to be complete lists. They have to know how to
combine the includes at a low-level with the excludes of a
higher-level - and potentially vice-versa.
I think javac s
Thanks Erik!
David
On 8/03/2013 9:25 PM, Erik Joelsson wrote:
On 2013-03-08 10:19, Alan Bateman wrote:
On 08/03/2013 01:48, David Holmes wrote:
Not sure which is best list for this given Alan will likely be the
only reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/800
On 8/03/2013 7:19 PM, Alan Bateman wrote:
On 08/03/2013 01:48, David Holmes wrote:
Not sure which is best list for this given Alan will likely be the
only reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/8009428_8009429/
As further background to others, the reverting of t
On 2013-03-08 10:19, Alan Bateman wrote:
On 08/03/2013 01:48, David Holmes wrote:
Not sure which is best list for this given Alan will likely be the
only reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/8009428_8009429/
As further background to others, the reverting of
On 8 March 2013 09:19, Alan Bateman wrote:
> One probable side effect of removing the redundant sub-packages will be the
> javadoc. The one case to date where we didn't list sub-packages is java.time
> (because there are still changes going on there) and that the result is that
> the sub-packages
On 08/03/2013 01:48, David Holmes wrote:
Not sure which is best list for this given Alan will likely be the
only reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/8009428_8009429/
As further background to others, the reverting of the $ substitution
became possible when Nas
Not sure which is best list for this given Alan will likely be the only
reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/8009428_8009429/
Two related sets of fixes here:
JDK-8009428: Revert changes to $ substitution performed as part of
nashorn integration
This removes
13 matches
Mail list logo
