From forax at univ-mlv.fr Tue May 2 08:41:02 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 2 May 2017 10:41:02 +0200 (CEST) Subject: exports lint is perhaps a little overzealous In-Reply-To: <1264811037.252149.1493631993349.JavaMail.zimbra@u-pem.fr> References: <356809234.3135667.1493407891018.JavaMail.zimbra@u-pem.fr> <1264811037.252149.1493631993349.JavaMail.zimbra@u-pem.fr> Message-ID: <1244770109.696787.1493714462502.JavaMail.zimbra@u-pem.fr> ping ? R?mi ----- Mail original ----- > De: "Remi Forax" > ?: "compiler-dev" > Envoy?: Lundi 1 Mai 2017 11:46:33 > Objet: Re: exports lint is perhaps a little overzealous > ping ? > > R?mi > > ----- Mail original ----- >> De: "Remi Forax" >> ?: "compiler-dev" >> Envoy?: Vendredi 28 Avril 2017 21:31:31 >> Objet: exports lint is perhaps a little overzealous > >> javac output warnings when an annotation on public methods or a public class of >> an exported package comes from a dependencies which is not declared as >> transitive. >> >> I believe that annotations are not really part of the API so should not be >> checked by exports linter. >> In my case, the annotation is the JUnit5 @Test, given how JUnit works, the >> method is always called by reflection so having a requires transitive makes >> little sense. >> >> >> target\test\merged\com.github.forax.pro.api\com\github\forax\pro\api\helper\CmdLineTests.java:9: >> warning: [exports] class Test in module junit.jupiter.api is not indirectly >> exported using requires transitive >> @Test >> ^ >> target\test\merged\com.github.forax.pro.api\com\github\forax\pro\api\helper\CmdLineTests.java:15: >> warning: [exports] class Test in module junit.jupiter.api is not indirectly >> exported using requires transitive >> @Test >> ^ >> target\test\merged\com.github.forax.pro.api\com\github\forax\pro\api\helper\CmdLineTests.java:22: >> warning: [exports] class Test in module junit.jupiter.api is not indirectly >> exported using requires transitive >> @Test >> ^ >> target\test\merged\com.github.forax.pro.helper\com\github\forax\pro\helper\FileHelperTests.java:11: >> warning: [exports] class Test in module junit.jupiter.api is not indirectly >> exported using requires transitive >> @Test >> ^ >> >> regards, > > R?mi From jonathan.gibbons at oracle.com Wed May 3 22:06:47 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 May 2017 15:06:47 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. Message-ID: <590A5477.9050602@oracle.com> This is a review request for two co-dependent fixes. JDK-8179592: Update tables in java.base to be HTML 5-friendly. JDK-8179479: Add new styles to enable HTML 5 tables In doc comments, some of the HTML 4.01 attributes for tables are no longer available in HTML 5, and CSS should be used instead. To this end, some updates have been made to the main/default stylesheet used by javadoc, to define two new CSS classes for tables. The new classes are: Just puts plain borders around each cell, with no background coloring.
Horizontal borders are not used between cells in the table body; instead, alternating backgrounds are used to help distinguish the separate rows. In addition, there is still the default
No borders. These styles are in the langtools webrev, here: http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ The changes to the doc comments in java.base are in the jdk webrev, here: http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ summary vs.
The ARIA recommendations are to use the summary attribute or tag ... but the summary attribute is no longer allowed in HTML 5. In general, the text that has been provided for a summary is not suitable for direct use as a caption. The temporary workaround is to use a caption that is not displayed. In time, the appropriate API owners should update the use of these undisplayed table captions, to modify the text of the caption and make the caption displayed (by removing style="display:none"). Doc comments were changed in files in the following packages: java.io java.lang java.lang.invoke java.lang.reflect java.math java.net java.nio.channels java.nio.charset java.nio.file java.nio.file.attribute java.nio.file.spi java.security java.security.cert java.text java.time.chrono java.time.format java.time.temporal java.util java.util.concurrent java.util.regex java.util.spi javax.net.ssl The intent is that the only changes in this webrev are to the HTML 5 markup. There should be no significant changes to the text in any doc comment. The decision to add the styles to the default stylesheet at this late stage in the release is not taken lightly, and is seen as a temporary measure. JDK-8177283 is a wishlist enhancement for updates to javadoc support of stylesheets, which includes the desire to move JDK-specific styles to a JDK-specific stylesheet. This review is primarily about continuing the ongoing effort to make our docs be HTML 5 compliant. I would prefer not to get into extended discussions about which style class to use for each table, and what the exact definition of the styleclasses should be at this time. But appropriate review feedback is obviously welcome. -- Jon From martinrb at google.com Wed May 3 23:39:37 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 May 2017 16:39:37 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A5477.9050602@oracle.com> References: <590A5477.9050602@oracle.com> Message-ID: Thanks, Jon. For the Deque/Queue tables - * + *
I expected that we would modify these to
which rendered alright and is compliant (although "border" is a weird boolean) and makes the "border intent" clear to humans and to browsers. THIS IS JAVA, so I'd prefer more verbose meaningful names for these style classes ... hmmm ... class="contrasting_rows" ? To me, "plain" is suggestive of no borders at all. Can we have some guidance comments in stylesheet.css explaining when to use the different classes? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 4 00:03:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 May 2017 17:03:13 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> Message-ID: <590A6FC1.5030803@oracle.com> On 05/03/2017 04:39 PM, Martin Buchholz wrote: > Thanks, Jon. > > For the Deque/Queue tables > - *
> + *
> I expected that we would modify these to >
> which rendered alright and is compliant (although "border" is a weird > boolean) and makes the "border intent" clear to humans and to browsers. > > THIS IS JAVA, so I'd prefer more verbose meaningful names for these > style classes ... hmmm ... class="contrasting_rows" ? To me, "plain" > is suggestive of no borders at all. > > Can we have some guidance comments in stylesheet.css explaining when > to use the different classes? > Martin, If you are specifically requesting that the tables in Deque/Queue use "
" then I will do as you request, but I note that the "plain" style does more than just `border="1"`. It adjusts the caption font and the margins above and below the table. Given that the JSR166 doc comments actually use the
tag reasonably, the presentation with the non-default font seemed "better". That being said, prior to doing this work, I did some analysis on the tables coming from doc comments. There are about 484 with 70 different variants of the opening tag. Therefore, there was a secondary goal to simplify the many different visual appearances created using inline styles. How strongly do you feel about the names? As I said at the end of the email, I would like to do a more complete cleanup of javadoc support for stylesheets in a subsequent release. This would involve separating the stylesheet for the HTML generated by the doclet from a stylesheet provided to accompany the doc comments, and would clean up the name space and write a moderately formal specification of the styles in those stylesheets. I can put some comments in the default stylesheet for the time being. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu May 4 00:46:23 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 May 2017 17:46:23 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A6FC1.5030803@oracle.com> References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> Message-ID: Jon, I am happy for you to own the html5 style for the entire javadoc; consistency wins; my comments are only suggestions and I'm no html or css expert. On Wed, May 3, 2017 at 5:03 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > > On 05/03/2017 04:39 PM, Martin Buchholz wrote: > > Thanks, Jon. > > For the Deque/Queue tables > > - *
> + *
> > I expected that we would modify these to >
> which rendered alright and is compliant (although "border" is a weird > boolean) and makes the "border intent" clear to humans and to browsers. > > THIS IS JAVA, so I'd prefer more verbose meaningful names for these style > classes ... hmmm ... class="contrasting_rows" ? To me, "plain" is > suggestive of no borders at all. > > Can we have some guidance comments in stylesheet.css explaining when to > use the different classes? > > > Martin, > > If you are specifically requesting that the tables in Deque/Queue use > "
" then I will do as you request, but I note that the > "plain" style does more than just `border="1"`. It adjusts the caption > font and the margins above and below the table. Given that the JSR166 doc > comments actually use the
tag reasonably, the presentation with > the non-default font seemed "better". > > That being said, prior to doing this work, I did some analysis on the > tables coming from doc comments. There are about 484 with 70 > different variants of the opening tag. Therefore, there was a > secondary goal to simplify the many different visual appearances created > using inline styles. > > How strongly do you feel about the names? As I said at the end of the > email, I would like to do a more complete cleanup of javadoc support for > stylesheets in a subsequent release. This would involve separating the > stylesheet for the HTML generated by the doclet from a stylesheet provided > to accompany the doc comments, and would clean up the name space and write > a moderately formal specification of the styles in those stylesheets. > > I can put some comments in the default stylesheet for the time being. > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 4 01:16:35 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 May 2017 18:16:35 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> Message-ID: <590A80F3.6050904@oracle.com> With my javadoc-tool-developer hat on, I'd like to get out of the business of jdk-style-owner, or at least identify that as a distinct hat. :-) Kumar has identified a problem with the styles as currently defined ... you cannot easily embed a table with a default style inside a table with an explicit style ... which suggests the need for a third named style for "no borders". (And yes, we have nested tables in some places.). Although we disagree with your comment "THIS IS JAVA" (no it's not, it's HTML and CSS) the point is noted. How about the following names, with appropriate comments to come in the style sheet: 1.
it does what it says, but long term, I see this being deprecated in favor of other styles ... there are places where a style with no borders is in use now, but when you add in captions, some amount of bordering would be better. 2.
simple collapsed borders around each cell 3.
previously called altrows. How about longer names, specific to tables, like "borderless-table", "plain-table", "striped-table"? That would make it easier to have named styles for other constructs, although we will need to keep a balance between a proliferation of named styles and too much inline style. All of this would be so much better with sufficient definitions for all the styles used by javadoc to allow adventurous and creative folk to use modified stylesheets for their own API. But not this week. By the way, I forgot to mention in my original email, there is a copy of the API docs showing the proposed changes, available here: http://cr.openjdk.java.net/~jjg/8179479-8179592/api/java.base-summary.html -- Jon On 05/03/2017 05:46 PM, Martin Buchholz wrote: > Jon, I am happy for you to own the html5 style for the entire javadoc; > consistency wins; my comments are only suggestions and I'm no html or > css expert. > > On Wed, May 3, 2017 at 5:03 PM, Jonathan Gibbons > > wrote: > > > > On 05/03/2017 04:39 PM, Martin Buchholz wrote: >> Thanks, Jon. >> >> For the Deque/Queue tables >> - *
>> + *
>> I expected that we would modify these to >>
>> which rendered alright and is compliant (although "border" is a >> weird boolean) and makes the "border intent" clear to humans and >> to browsers. >> >> THIS IS JAVA, so I'd prefer more verbose meaningful names for >> these style classes ... hmmm ... class="contrasting_rows" ? To >> me, "plain" is suggestive of no borders at all. >> >> Can we have some guidance comments in stylesheet.css explaining >> when to use the different classes? >> > > Martin, > > If you are specifically requesting that the tables in Deque/Queue > use "
" then I will do as you request, but I note > that the "plain" style does more than just `border="1"`. It > adjusts the caption font and the margins above and below the > table. Given that the JSR166 doc comments actually use the >
tag reasonably, the presentation with the non-default > font seemed "better". > > That being said, prior to doing this work, I did some analysis on > the tables coming from doc comments. There are about 484 > with 70 different variants of the opening tag. Therefore, > there was a secondary goal to simplify the many different visual > appearances created using inline styles. > > How strongly do you feel about the names? As I said at the end of > the email, I would like to do a more complete cleanup of javadoc > support for stylesheets in a subsequent release. This would > involve separating the stylesheet for the HTML generated by the > doclet from a stylesheet provided to accompany the doc comments, > and would clean up the name space and write a moderately formal > specification of the styles in those stylesheets. > > I can put some comments in the default stylesheet for the time being. > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu May 4 02:49:29 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 May 2017 19:49:29 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A80F3.6050904@oracle.com> References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> <590A80F3.6050904@oracle.com> Message-ID: Jonathan Gibbons for "css style czar"! --- I checked the tables at http://cr.openjdk.java.net/~jjg/8179479-8179592/api/java/util/concurrent/BlockingDeque.html They look perfectly fine, although I feel a twinge of non-collapsed-border-nostalgia. --- Yes, "striped" is a much better name than "altrows". "striped-tables" as you suggest may be better. Choose your names carefully - we can't change them in the future. --- w3.org doc seems to suggest we should only be defining table styles with borders. https://www.w3.org/TR/html5/tabular-data.html#attr-table-border """Tables should not be used as layout aids. """ """User agents, especially those that do table analysis on arbitrary content, are encouraged to find heuristics to determine which tables actually contain data and which are merely being used for layout. """ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 4 15:16:21 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 4 May 2017 08:16:21 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> <590A80F3.6050904@oracle.com> Message-ID: On 5/3/17 7:49 PM, Martin Buchholz wrote: > > w3.org doc seems to suggest we should only be defining > table styles with borders. > > https://www.w3.org/TR/html5/tabular-data.html#attr-table-border > > """Tables should not be used as layout aids. """ > > """User agents, especially those that do table analysis on arbitrary > content, are encouraged to find heuristics to determine which tables > actually contain data and which are merely being used for layout. """ Understood. The patch as provided already changes some tables with `summary="layout"` into definition lists. There are additional candidates that would be candidates for such a change at some point. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 4 15:27:23 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 4 May 2017 08:27:23 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> <590A80F3.6050904@oracle.com> Message-ID: <307d0c82-5358-5a2e-88a4-344a9f591c21@oracle.com> On 5/3/17 7:49 PM, Martin Buchholz wrote: > > --- > > Yes, "striped" is a much better name than "altrows". "striped-tables" > as you suggest may be better. Choose your names carefully - we can't > change them in the future. > > --- Well, we can, ... but ... A goal of creating specification(s) for the stylesheet(s) provided by javadoc, for the doclet-generated output, and for the doc-comment content, is that the specification(s) should be subject to specification review[1], and not just an impl detail of the javadool tool and/or build system. -- Jon [1] http://mail.openjdk.java.net/pipermail/csr-discuss/2017-April/thread.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu May 4 16:02:56 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 4 May 2017 12:02:56 -0400 Subject: RFR: 8144185: javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute Message-ID: Hello, could I get feedback on this potential fix for JDK-8144185? bug: https://bugs.openjdk.java.net/browse/JDK-8144185 webrev: http://cr.openjdk.java.net/~cushon/8144185/webrev.00/ We ran into this because the incorrect localvar_target crashes ASM. The change causes annotations on captured outer locals to not be propagated to the synthetic formal parameter, as discussed here: http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009866.html . I gave the parameters for captured enclosing instances the same treatment, although I'm not sure it's possible for type annotations to be attached to them. I also removed some calls to `setTypeAttributes` that as far as I can tell were redundant with the call to that method in `translate(Symbol, LambdaSymbolKind)`, and which were incorrect for captured outer locals. -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Fri May 5 00:18:37 2017 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Fri, 5 May 2017 05:48:37 +0530 Subject: RFR: 8144185: javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute In-Reply-To: References: Message-ID: <590BC4DD.4050400@oracle.com> Thanks Liam, I will take a look at this next week. Thanks! Srikanth On Thursday 04 May 2017 09:32 PM, Liam Miller-Cushon wrote: > Hello, could I get feedback on this potential fix for JDK-8144185? > > bug: https://bugs.openjdk.java.net/browse/JDK-8144185 > webrev: http://cr.openjdk.java.net/~cushon/8144185/webrev.00/ > > > We ran into this because the incorrect localvar_target crashes ASM. > The change causes annotations on captured outer locals to not be > propagated to the synthetic formal parameter, as discussed here: > http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009866.html. > > > I gave the parameters for captured enclosing instances the same > treatment, although I'm not sure it's possible for type annotations to > be attached to them. > > I also removed some calls to `setTypeAttributes` that as far as I can > tell were redundant with the call to that method in `translate(Symbol, > LambdaSymbolKind)`, and which were incorrect for captured outer locals. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri May 5 10:14:08 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 5 May 2017 12:14:08 +0200 Subject: exports lint is perhaps a little overzealous In-Reply-To: <1244770109.696787.1493714462502.JavaMail.zimbra@u-pem.fr> References: <356809234.3135667.1493407891018.JavaMail.zimbra@u-pem.fr> <1264811037.252149.1493631993349.JavaMail.zimbra@u-pem.fr> <1244770109.696787.1493714462502.JavaMail.zimbra@u-pem.fr> Message-ID: <590C5070.5040304@oracle.com> Hi Remi, The lint check only looks for @Documented annotations, which are part of the element's contract, I think. Jan On 2.5.2017 10:41, Remi Forax wrote: > ping ? > > R?mi > > ----- Mail original ----- >> De: "Remi Forax" >> ?: "compiler-dev" >> Envoy?: Lundi 1 Mai 2017 11:46:33 >> Objet: Re: exports lint is perhaps a little overzealous > >> ping ? >> >> R?mi >> >> ----- Mail original ----- >>> De: "Remi Forax" >>> ?: "compiler-dev" >>> Envoy?: Vendredi 28 Avril 2017 21:31:31 >>> Objet: exports lint is perhaps a little overzealous >> >>> javac output warnings when an annotation on public methods or a public class of >>> an exported package comes from a dependencies which is not declared as >>> transitive. >>> >>> I believe that annotations are not really part of the API so should not be >>> checked by exports linter. >>> In my case, the annotation is the JUnit5 @Test, given how JUnit works, the >>> method is always called by reflection so having a requires transitive makes >>> little sense. >>> >>> >>> target\test\merged\com.github.forax.pro.api\com\github\forax\pro\api\helper\CmdLineTests.java:9: >>> warning: [exports] class Test in module junit.jupiter.api is not indirectly >>> exported using requires transitive >>> @Test >>> ^ >>> target\test\merged\com.github.forax.pro.api\com\github\forax\pro\api\helper\CmdLineTests.java:15: >>> warning: [exports] class Test in module junit.jupiter.api is not indirectly >>> exported using requires transitive >>> @Test >>> ^ >>> target\test\merged\com.github.forax.pro.api\com\github\forax\pro\api\helper\CmdLineTests.java:22: >>> warning: [exports] class Test in module junit.jupiter.api is not indirectly >>> exported using requires transitive >>> @Test >>> ^ >>> target\test\merged\com.github.forax.pro.helper\com\github\forax\pro\helper\FileHelperTests.java:11: >>> warning: [exports] class Test in module junit.jupiter.api is not indirectly >>> exported using requires transitive >>> @Test >>> ^ >>> >>> regards, >>> R?mi From jonathan.gibbons at oracle.com Fri May 5 22:52:47 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 05 May 2017 15:52:47 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A5477.9050602@oracle.com> References: <590A5477.9050602@oracle.com> Message-ID: <590D023F.1010809@oracle.com> This is an updated review for the changes to improve tables in java.base. The changes incorporate earlier review feedback, and also address a problem that was discovered with nested tables. The summary of the set of changes since the previous round is: * A new style class is added for borderless tables, to be used in preference to a table tag with no class. * The style classes are now named: borderless plain striped The longer form using a suffix `-table` was considered, but generally, there should not be so many style classes that such a level of discrimination is needed. The names `borderless` and `striped` are most likely to only apply to tables anyway, and `plain` could reasonably be used for other elements without conflict. * Comments are added to the stylesheet regarding these new classes, as a placeholder until a better specification for the styles in these stylesheets is created. * Within java.base, all uses of the `altrows` class have been updated to use `striped`, and tables with no class attribute have been changed to explicitly use `borderless`. Webrevs: langtools (the stylesheet): http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ jdk (changes to java.base): http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ API showing the combined effect of these cahnges: http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html -- Jon On 05/03/2017 03:06 PM, Jonathan Gibbons wrote: > This is a review request for two co-dependent fixes. > > JDK-8179592: Update tables in java.base to be HTML 5-friendly. > JDK-8179479: Add new styles to enable HTML 5 tables > > In doc comments, some of the HTML 4.01 attributes for tables are no > longer available in HTML 5, and CSS should be used instead. > To this end, some updates have been made to the main/default > stylesheet used by javadoc, to define two new CSS classes for tables. > > The new classes are: >
> Just puts plain borders around each cell, with no background > coloring. > >
> Horizontal borders are not used between cells in the table body; > instead, alternating backgrounds are used to help distinguish the > separate rows. > > In addition, there is still the default >
> No borders. > > These styles are in the langtools webrev, here: > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ > > The changes to the doc comments in java.base are in the jdk webrev, here: > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ > > summary vs.
> > The ARIA recommendations are to use the summary attribute or > tag ... but the summary attribute is no longer allowed in > HTML 5. In general, the text that has been provided for a summary is > not suitable for direct use as a caption. The temporary workaround is > to use a caption that is not displayed. In time, the appropriate API > owners should update the use of these undisplayed table captions, to > modify the text of the caption and make the caption displayed (by > removing style="display:none"). > > Doc comments were changed in files in the following packages: > > java.io > java.lang > java.lang.invoke > java.lang.reflect > java.math > java.net > java.nio.channels > java.nio.charset > java.nio.file > java.nio.file.attribute > java.nio.file.spi > java.security > java.security.cert > java.text > java.time.chrono > java.time.format > java.time.temporal > java.util > java.util.concurrent > java.util.regex > java.util.spi > javax.net.ssl > > The intent is that the only changes in this webrev are to the HTML 5 > markup. There should be no significant changes to the text in any doc > comment. > > The decision to add the styles to the default stylesheet at this late > stage in the release is not taken lightly, and is seen as a temporary > measure. JDK-8177283 is a wishlist enhancement for updates to javadoc > support of stylesheets, which includes the desire to move JDK-specific > styles to a JDK-specific stylesheet. > > This review is primarily about continuing the ongoing effort to make > our docs be HTML 5 compliant. I would prefer not to get into extended > discussions about which style class to use for each table, and what > the exact definition of the styleclasses should be at this time. But > appropriate review feedback is obviously welcome. > > -- Jon From martinrb at google.com Mon May 8 20:26:58 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 8 May 2017 13:26:58 -0700 Subject: Compiler bug with nested lambdas and anonymous inner classes? In-Reply-To: <20170508202154.GH21050@gmail.com> References: <20170508202154.GH21050@gmail.com> Message-ID: [compiler-dev instead] On Mon, May 8, 2017 at 1:21 PM, Keith Amling wrote: > > $ cat Bug.java > > public class Bug { > > public static void foo() { > > Runnable r1 = () -> { > > new Object() { > > Runnable r2 = () -> new Object() { }; > > }; > > }; > > } > > } > > $ > > "Compiles", but bytecode is nonsense (generates aload_0 in static method > with > no args) and fails verification: > > > $ javac Bug.java > > $ javap -private -c -verbose Bug | grep 'foo()' -A 12 > > public static void foo(); > > descriptor: ()V > > flags: ACC_PUBLIC, ACC_STATIC > > Code: > > stack=1, locals=1, args_size=0 > > 0: aload_0 > > 1: invokedynamic #2, 0 // InvokeDynamic > #0:run:(LBug;)Ljava/lang/Runnable; > > 6: astore_0 > > 7: return > > LineNumberTable: > > line 3: 0 > > line 8: 7 > > > > $ java Bug > > Error: A JNI error has occurred, please check your installation and try > again > > Exception in thread "main" java.lang.VerifyError: Bad local variable type > > Exception Details: > > Location: > > Bug.foo()V @0: aload_0 > > Reason: > > Type top (current frame, locals[0]) is not assignable to reference > type > > Current Frame: > > bci: @0 > > flags: { } > > locals: { } > > stack: { } > > Bytecode: > > 0x0000000: 2aba 0002 0000 4bb1 > > > > at java.lang.Class.getDeclaredMethods0(Native Method) > > at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) > > at java.lang.Class.privateGetMethodRecursive(Class.java:3048) > > at java.lang.Class.getMethod0(Class.java:3018) > > at java.lang.Class.getMethod(Class.java:1784) > > at sun.launcher.LauncherHelper.validateMainClass( > LauncherHelper.java:544) > > at sun.launcher.LauncherHelper.checkAndLoadMain( > LauncherHelper.java:526) > > $ > > This with: > > > $ uname -a > > Linux trtoje 4.9.0-2-amd64 #1 SMP Debian 4.9.10-1 (2017-02-17) x86_64 > GNU/Linux > > $ java -version > > openjdk version "1.8.0_131" > > OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1-b11) > > OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode) > > $ > > Keith > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon May 8 20:35:56 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 8 May 2017 21:35:56 +0100 Subject: Compiler bug with nested lambdas and anonymous inner classes? In-Reply-To: References: <20170508202154.GH21050@gmail.com> Message-ID: Thanks for the report. This issue is not reproducible in JDK 9, and I believe it to be a duplicate of [1]. Cheers Maurizio [1] - https://bugs.openjdk.java.net/browse/JDK-8076538 On 08/05/17 21:26, Martin Buchholz wrote: > VerifyError: Bad local variable type From keith.amling at gmail.com Mon May 8 20:56:50 2017 From: keith.amling at gmail.com (Keith Amling) Date: Mon, 8 May 2017 13:56:50 -0700 Subject: Compiler bug with nested lambdas and anonymous inner classes? In-Reply-To: References: <20170508202154.GH21050@gmail.com> Message-ID: <20170508205650.GI21050@gmail.com> Yeah, sorry I failed to make heads or tails of the bug tracker before reporting. I assume "Fix Version: 9" means this was fixed for JDK9 (alone), although that's somewhat unhelpful for people stuck on 8. Keith Thus spake Maurizio Cimadamore, at Mon, May 08, 2017 at 09:35:56PM +0100: > Date: Mon, 8 May 2017 21:35:56 +0100 > From: Maurizio Cimadamore > To: Martin Buchholz , Keith Amling > , compiler-dev > Subject: Re: Compiler bug with nested lambdas and anonymous inner classes? > > Thanks for the report. This issue is not reproducible in JDK 9, and I > believe it to be a duplicate of [1]. > > Cheers > Maurizio > > [1] - https://bugs.openjdk.java.net/browse/JDK-8076538 > > > On 08/05/17 21:26, Martin Buchholz wrote: > >VerifyError: Bad local variable type > From kumar.x.srinivasan at oracle.com Mon May 8 22:12:11 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 08 May 2017 15:12:11 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <590D023F.1010809@oracle.com> References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> Message-ID: <5910ED3B.9090808@oracle.com> Hi Jon, I looked at the stylesheet can the descriptive comments for each of the classes be moved closer to the class itself, ie. just before the definition ? Kumar > This is an updated review for the changes to improve tables in java.base. > > The changes incorporate earlier review feedback, and also address a > problem that was discovered with nested tables. > > The summary of the set of changes since the previous round is: > > * A new style class is added for borderless tables, to be used in > preference to a table tag with no class. > > * The style classes are now named: > borderless > plain > striped > The longer form using a suffix `-table` was considered, but > generally, there should not be so many style classes that such a level > of discrimination is needed. The names `borderless` and `striped` are > most likely to only apply to tables anyway, and `plain` could > reasonably be used for other elements without conflict. > > * Comments are added to the stylesheet regarding these new classes, as > a placeholder until a better specification for the styles in these > stylesheets is created. > > * Within java.base, all uses of the `altrows` class have been updated > to use `striped`, and tables with no class attribute have been changed > to explicitly use `borderless`. > > > Webrevs: > > langtools (the stylesheet): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ > > jdk (changes to java.base): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ > > API showing the combined effect of these cahnges: > http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html > > > > -- Jon > > > > > On 05/03/2017 03:06 PM, Jonathan Gibbons wrote: >> This is a review request for two co-dependent fixes. >> >> JDK-8179592: Update tables in java.base to be HTML 5-friendly. >> JDK-8179479: Add new styles to enable HTML 5 tables >> >> In doc comments, some of the HTML 4.01 attributes for tables are no >> longer available in HTML 5, and CSS should be used instead. >> To this end, some updates have been made to the main/default >> stylesheet used by javadoc, to define two new CSS classes for tables. >> >> The new classes are: >> >> Just puts plain borders around each cell, with no background >> coloring. >> >>
>> Horizontal borders are not used between cells in the table body; >> instead, alternating backgrounds are used to help distinguish the >> separate rows. >> >> In addition, there is still the default >>
>> No borders. >> >> These styles are in the langtools webrev, here: >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ >> >> The changes to the doc comments in java.base are in the jdk webrev, >> here: >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ >> >> summary vs.
>> >> The ARIA recommendations are to use the summary attribute or >> tag ... but the summary attribute is no longer allowed in >> HTML 5. In general, the text that has been provided for a summary is >> not suitable for direct use as a caption. The temporary workaround is >> to use a caption that is not displayed. In time, the appropriate API >> owners should update the use of these undisplayed table captions, to >> modify the text of the caption and make the caption displayed (by >> removing style="display:none"). >> >> Doc comments were changed in files in the following packages: >> >> java.io >> java.lang >> java.lang.invoke >> java.lang.reflect >> java.math >> java.net >> java.nio.channels >> java.nio.charset >> java.nio.file >> java.nio.file.attribute >> java.nio.file.spi >> java.security >> java.security.cert >> java.text >> java.time.chrono >> java.time.format >> java.time.temporal >> java.util >> java.util.concurrent >> java.util.regex >> java.util.spi >> javax.net.ssl >> >> The intent is that the only changes in this webrev are to the HTML 5 >> markup. There should be no significant changes to the text in any doc >> comment. >> >> The decision to add the styles to the default stylesheet at this late >> stage in the release is not taken lightly, and is seen as a temporary >> measure. JDK-8177283 is a wishlist enhancement for updates to javadoc >> support of stylesheets, which includes the desire to move >> JDK-specific styles to a JDK-specific stylesheet. >> >> This review is primarily about continuing the ongoing effort to make >> our docs be HTML 5 compliant. I would prefer not to get into extended >> discussions about which style class to use for each table, and what >> the exact definition of the styleclasses should be at this time. But >> appropriate review feedback is obviously welcome. >> >> -- Jon > From jonathan.gibbons at oracle.com Mon May 8 22:22:39 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 08 May 2017 15:22:39 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <5910ED3B.9090808@oracle.com> References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> <5910ED3B.9090808@oracle.com> Message-ID: <5910EFAF.2080609@oracle.com> Kumar, The nature of CSS is such that there is generally no one single definition. The descriptive comments are just before the shared/common parts of the definitions. If I grouped the comment and class definition, someone else would point out that I could be sharing common properties. The better long term solution is a separate document, with examples. -- Jon On 05/08/2017 03:12 PM, Kumar Srinivasan wrote: > > Hi Jon, > > I looked at the stylesheet can the descriptive comments for each of the > classes be moved closer to the class itself, ie. just before the > definition ? > > Kumar > >> This is an updated review for the changes to improve tables in >> java.base. >> >> The changes incorporate earlier review feedback, and also address a >> problem that was discovered with nested tables. >> >> The summary of the set of changes since the previous round is: >> >> * A new style class is added for borderless tables, to be used in >> preference to a table tag with no class. >> >> * The style classes are now named: >> borderless >> plain >> striped >> The longer form using a suffix `-table` was considered, but >> generally, there should not be so many style classes that such a >> level of discrimination is needed. The names `borderless` and >> `striped` are most likely to only apply to tables anyway, and `plain` >> could reasonably be used for other elements without conflict. >> >> * Comments are added to the stylesheet regarding these new classes, >> as a placeholder until a better specification for the styles in these >> stylesheets is created. >> >> * Within java.base, all uses of the `altrows` class have been updated >> to use `striped`, and tables with no class attribute have been >> changed to explicitly use `borderless`. >> >> >> Webrevs: >> >> langtools (the stylesheet): >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ >> >> jdk (changes to java.base): >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ >> >> API showing the combined effect of these cahnges: >> http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html >> >> >> >> -- Jon >> >> >> >> >> On 05/03/2017 03:06 PM, Jonathan Gibbons wrote: >>> This is a review request for two co-dependent fixes. >>> >>> JDK-8179592: Update tables in java.base to be HTML 5-friendly. >>> JDK-8179479: Add new styles to enable HTML 5 tables >>> >>> In doc comments, some of the HTML 4.01 attributes for tables are no >>> longer available in HTML 5, and CSS should be used instead. >>> To this end, some updates have been made to the main/default >>> stylesheet used by javadoc, to define two new CSS classes for tables. >>> >>> The new classes are: >>> >>> Just puts plain borders around each cell, with no background >>> coloring. >>> >>>
>>> Horizontal borders are not used between cells in the table body; >>> instead, alternating backgrounds are used to help distinguish the >>> separate rows. >>> >>> In addition, there is still the default >>>
>>> No borders. >>> >>> These styles are in the langtools webrev, here: >>> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ >>> >>> The changes to the doc comments in java.base are in the jdk webrev, >>> here: >>> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ >>> >>> summary vs.
>>> >>> The ARIA recommendations are to use the summary attribute or >>> tag ... but the summary attribute is no longer allowed in >>> HTML 5. In general, the text that has been provided for a summary >>> is not suitable for direct use as a caption. The temporary >>> workaround is to use a caption that is not displayed. In time, the >>> appropriate API owners should update the use of these undisplayed >>> table captions, to modify the text of the caption and make the >>> caption displayed (by removing style="display:none"). >>> >>> Doc comments were changed in files in the following packages: >>> >>> java.io >>> java.lang >>> java.lang.invoke >>> java.lang.reflect >>> java.math >>> java.net >>> java.nio.channels >>> java.nio.charset >>> java.nio.file >>> java.nio.file.attribute >>> java.nio.file.spi >>> java.security >>> java.security.cert >>> java.text >>> java.time.chrono >>> java.time.format >>> java.time.temporal >>> java.util >>> java.util.concurrent >>> java.util.regex >>> java.util.spi >>> javax.net.ssl >>> >>> The intent is that the only changes in this webrev are to the HTML 5 >>> markup. There should be no significant changes to the text in any >>> doc comment. >>> >>> The decision to add the styles to the default stylesheet at this >>> late stage in the release is not taken lightly, and is seen as a >>> temporary measure. JDK-8177283 is a wishlist enhancement for updates >>> to javadoc support of stylesheets, which includes the desire to move >>> JDK-specific styles to a JDK-specific stylesheet. >>> >>> This review is primarily about continuing the ongoing effort to make >>> our docs be HTML 5 compliant. I would prefer not to get into >>> extended discussions about which style class to use for each table, >>> and what the exact definition of the styleclasses should be at this >>> time. But appropriate review feedback is obviously welcome. >>> >>> -- Jon >> > From david.holmes at oracle.com Tue May 9 01:05:16 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 May 2017 11:05:16 +1000 Subject: Compiler bug with nested lambdas and anonymous inner classes? In-Reply-To: <20170508202154.GH21050@gmail.com> References: <20170508202154.GH21050@gmail.com> Message-ID: Hi Keith, Thanks - bug reports can be made at http://bugreport.java.com/ Or you could discuss this issue with javac folk via compiler-dev at openjdk.java.net (cc'd). This issue is fixed in JDK 9 but still present in JDK 8u. Please drop the discuss list from any replies. Thanks, David On 9/05/2017 6:21 AM, Keith Amling wrote: >> $ cat Bug.java >> public class Bug { >> public static void foo() { >> Runnable r1 = () -> { >> new Object() { >> Runnable r2 = () -> new Object() { }; >> }; >> }; >> } >> } >> $ > > "Compiles", but bytecode is nonsense (generates aload_0 in static method with > no args) and fails verification: > >> $ javac Bug.java >> $ javap -private -c -verbose Bug | grep 'foo()' -A 12 >> public static void foo(); >> descriptor: ()V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=1, locals=1, args_size=0 >> 0: aload_0 >> 1: invokedynamic #2, 0 // InvokeDynamic #0:run:(LBug;)Ljava/lang/Runnable; >> 6: astore_0 >> 7: return >> LineNumberTable: >> line 3: 0 >> line 8: 7 >> >> $ java Bug >> Error: A JNI error has occurred, please check your installation and try again >> Exception in thread "main" java.lang.VerifyError: Bad local variable type >> Exception Details: >> Location: >> Bug.foo()V @0: aload_0 >> Reason: >> Type top (current frame, locals[0]) is not assignable to reference type >> Current Frame: >> bci: @0 >> flags: { } >> locals: { } >> stack: { } >> Bytecode: >> 0x0000000: 2aba 0002 0000 4bb1 >> >> at java.lang.Class.getDeclaredMethods0(Native Method) >> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) >> at java.lang.Class.privateGetMethodRecursive(Class.java:3048) >> at java.lang.Class.getMethod0(Class.java:3018) >> at java.lang.Class.getMethod(Class.java:1784) >> at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) >> at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526) >> $ > > This with: > >> $ uname -a >> Linux trtoje 4.9.0-2-amd64 #1 SMP Debian 4.9.10-1 (2017-02-17) x86_64 GNU/Linux >> $ java -version >> openjdk version "1.8.0_131" >> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1-b11) >> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode) >> $ > > Keith > From bsrbnd at gmail.com Wed May 10 20:14:36 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 10 May 2017 22:14:36 +0200 Subject: JDK 10: Refactoring of LetExpr to allow more than one statement Message-ID: Hi, I've suggested some time ago a refactoring of LetExpr to generate a more optimized code in some cases, see [1]. The key idea is to allow LetExpr to have more than one statement in addition to multiple variable declarations. This would lead to a more optimal translation of comma-expressions, see [1]. This suggestion refers to let-expressions in Lisp which allow more than one statement in addition to multiple variable declarations, see [2]. Are you interested in such a feature? Should I create a JBS issue for that to be integrated in JDK 10? Regards, Bernard [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010531.html [2) http://www.lispworks.com/documentation/HyperSpec/Body/s_let_l.htm From maurizio.cimadamore at oracle.com Wed May 10 21:00:41 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 May 2017 22:00:41 +0100 Subject: JDK 10: Refactoring of LetExpr to allow more than one statement In-Reply-To: References: Message-ID: <9419157b-1296-33db-544c-db0c7cda6598@oracle.com> Hi, I think that we're I'd like to see things moving is more in the direction of block expressions, which allow even more freedom. That is, a list of statements (maybe var decls, but maybe not), followed by an expression (which is the expression value). I think this could be a powerful tool that could come handy for some of the features discussed under the Amber umbrella. So, I agree with you that LetExpr should be improved, but I guess I'm in for a more radical overhaul ;-) Maurizio On 10/05/17 21:14, B. Blaser wrote: > Hi, > > I've suggested some time ago a refactoring of LetExpr to generate a > more optimized code in some cases, see [1]. > > The key idea is to allow LetExpr to have more than one statement in > addition to multiple variable declarations. This would lead to a more > optimal translation of comma-expressions, see [1]. > > This suggestion refers to let-expressions in Lisp which allow more > than one statement in addition to multiple variable declarations, see > [2]. > > Are you interested in such a feature? Should I create a JBS issue for > that to be integrated in JDK 10? > > Regards, > Bernard > > [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010531.html > [2) http://www.lispworks.com/documentation/HyperSpec/Body/s_let_l.htm From mandy.chung at oracle.com Wed May 10 22:50:45 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 May 2017 15:50:45 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <590D023F.1010809@oracle.com> References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> Message-ID: <63E72F41-CF80-4692-9600-3A3857A5F94E@oracle.com> > On May 5, 2017, at 3:52 PM, Jonathan Gibbons wrote: > > This is an updated review for the changes to improve tables in java.base. > : > Webrevs: > > langtools (the stylesheet): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ > > jdk (changes to java.base): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ > > API showing the combined effect of these cahnges: > http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html > The new style class names are better. I reviewed the javadoc changes in java.base. Mostly looks good. A few table without an explicit class and FileSystemProvider should use striped class table. src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java - * + *
src/java.base/share/classes/java/nio/charset/Charset.java + *
+ *
+ *
+ *
+ *
" in one but not the other? -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Thu May 11 06:46:44 2017 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Thu, 11 May 2017 12:16:44 +0530 Subject: RFR: 8144185: javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute In-Reply-To: <590BC4DD.4050400@oracle.com> References: <590BC4DD.4050400@oracle.com> Message-ID: <591408D4.2060003@oracle.com> I am looking into this one - turns out I had a patch for this that was put through internal review process and some open issues that needed addressing caused it to be deferred. Comparing the patches I see some common code: Eliminating the three calls to setTypeAttributes is the right thing to do. Differences come in the following form: (1) Your proposed patch simply switches on the kind to determine whether annotations need to be carried over. This looks incorrect/insufficient. Type annotations and declarations annotations have different rules to be carried over. >From http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009865.html: - Declaration annotations on a lambda formal should not make it to the class file at all. - Type annotations on the type of a lambda formal should be carried over to the type of the formal parameter of the synthetic method that implements the lambda[*] I don't think this is handled by your patch ??? (2) From https://bugs.openjdk.java.net/browse/JDK-8144185: Not only is the range incorrect, but also LVT index appears incorrect: I don't think this is handled by your patch ??? FWIW, JDK-8144185 carries a fix version of tbd_major and I was going to work on it for JDK10. I can rework my patch and take it to push in the coming couple of weeks. Does that sound good ? Thanks! Srikanth. On Friday 05 May 2017 05:48 AM, Srikanth wrote: > Thanks Liam, > > I will take a look at this next week. > > Thanks! > Srikanth > > On Thursday 04 May 2017 09:32 PM, Liam Miller-Cushon wrote: >> Hello, could I get feedback on this potential fix for JDK-8144185? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8144185 >> webrev: http://cr.openjdk.java.net/~cushon/8144185/webrev.00/ >> >> >> We ran into this because the incorrect localvar_target crashes ASM. >> The change causes annotations on captured outer locals to not be >> propagated to the synthetic formal parameter, as discussed here: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009866.html. >> >> >> I gave the parameters for captured enclosing instances the same >> treatment, although I'm not sure it's possible for type annotations >> to be attached to them. >> >> I also removed some calls to `setTypeAttributes` that as far as I can >> tell were redundant with the call to that method >> in `translate(Symbol, LambdaSymbolKind)`, and which were incorrect >> for captured outer locals. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu May 11 14:17:47 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 11 May 2017 10:17:47 -0400 Subject: RFR: 8144185: javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute In-Reply-To: <591408D4.2060003@oracle.com> References: <590BC4DD.4050400@oracle.com> <591408D4.2060003@oracle.com> Message-ID: Thanks for reviewing, On Thu, May 11, 2017 at 2:46 AM, Srikanth wrote: > > I am looking into this one - turns out I had a patch for this that was put > through internal review process and some open issues that needed addressing > caused it to be deferred. > If it'd be less work to continue with your patch that sounds good to me, thanks. As I said I ran into an ASM crash related to this, and thought it might be a simple fix. > (1) Your proposed patch simply switches on the kind to determine whether > annotations need to be carried over. This looks incorrect/insufficient. > Type annotations and declarations annotations have different rules to be > carried over. > > From http://mail.openjdk.java.net/pipermail/compiler-dev/2015- > December/009865.html: > > - Declaration annotations on a lambda formal should not make it to the > class file at all. > I think that is handled in ClassWriter: http://hg.openjdk.java.net/jdk9/dev/langtools/file/ee84b7d44339/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java#l1183 > - Type annotations on the type of a lambda formal should be carried > over to the type > of the formal parameter of the synthetic method that implements > the lambda[*] > > I don't think this is handled by your patch ??? > As far as I can tell this is handled correctly before and after the patch: class T { @Retention(RUNTIME) @Target(TYPE_USE) @interface A {} Function r = (@A String x) -> x; } ... RuntimeVisibleTypeAnnotations: 0: #20(): METHOD_FORMAL_PARAMETER, param_index=0 > > (2) From https://bugs.openjdk.java.net/browse/JDK-8144185: > > Not only is the range incorrect, but also LVT index appears incorrect: > > I don't think this is handled by your patch ??? > I thought it was handled by the patch and exercised by the included test case. What am I missing? The incorrect LVT index comes from associating the annotation with the capture parameter in the synthetic lambda method instead of with the original local variable. In the test, the LVT index of the variable in f() is 1, and the LVT index of the capture parameter in the synthetic lambda method is 0. Before the patch, I see: RuntimeVisibleTypeAnnotations: 0: #23(): LOCAL_VARIABLE, {start_pc=0, length=31, index=0} With the patch applied: RuntimeVisibleTypeAnnotations: 0: #23(): LOCAL_VARIABLE, {start_pc=3, length=8, index=1} -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Thu May 11 14:50:45 2017 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Thu, 11 May 2017 20:20:45 +0530 Subject: RFR: 8144185: javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute In-Reply-To: References: <590BC4DD.4050400@oracle.com> <591408D4.2060003@oracle.com> Message-ID: <59147A45.8070502@oracle.com> I made the assertions about the differences in the patches simply by looking at the patches without ascertaining the behavior on tip due to other fixes. I will look into this in detail to see what is the minimal set of changes that would suffice. Srikanth On Thursday 11 May 2017 07:47 PM, Liam Miller-Cushon wrote: > Thanks for reviewing, > > On Thu, May 11, 2017 at 2:46 AM, Srikanth > > wrote: > > > I am looking into this one - turns out I had a patch for this that > was put through internal review process and some open issues that > needed addressing caused it to be deferred. > > > If it'd be less work to continue with your patch that sounds good to > me, thanks. As I said I ran into an ASM crash related to this, and > thought it might be a simple fix. > > (1) Your proposed patch simply switches on the kind to determine > whether annotations need to be carried over. This looks > incorrect/insufficient. Type annotations and declarations > annotations have different rules to be carried over. > > From > http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009865.html > : > > - Declaration annotations on a lambda formal should not make > it to the > class file at all. > > > I think that is handled in ClassWriter: > http://hg.openjdk.java.net/jdk9/dev/langtools/file/ee84b7d44339/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java#l1183 > > > - Type annotations on the type of a lambda formal should be > carried > over to the type > of the formal parameter of the synthetic method that > implements > the lambda[*] > > I don't think this is handled by your patch ??? > > > As far as I can tell this is handled correctly before and after the patch: > > class T { > @Retention(RUNTIME) @Target(TYPE_USE) @interface A {} > Function r = (@A String x) -> x; > } > ... > RuntimeVisibleTypeAnnotations: > 0: #20(): METHOD_FORMAL_PARAMETER, param_index=0 > > (2) From https://bugs.openjdk.java.net/browse/JDK-8144185 > : > > Not only is the range incorrect, but also LVT index appears incorrect: > > I don't think this is handled by your patch ??? > > > I thought it was handled by the patch and exercised by the included > test case. What am I missing? The incorrect LVT index comes from > associating the annotation with the capture parameter in the synthetic > lambda method instead of with the original local variable. In the > test, the LVT index of the variable in f() is 1, and the LVT index of > the capture parameter in the synthetic lambda method is 0. > > Before the patch, I see: > > RuntimeVisibleTypeAnnotations: > 0: #23(): LOCAL_VARIABLE, {start_pc=0, length=31, index=0} > > With the patch applied: > > RuntimeVisibleTypeAnnotations: > 0: #23(): LOCAL_VARIABLE, {start_pc=3, length=8, index=1} -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 11 15:17:56 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 11 May 2017 08:17:56 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> Message-ID: <37cbe0ce-060c-6c4c-044b-7903b291fac2@oracle.com> Martin, I've worked with Bhavesh to sort out these issues. The inconsistency in the syntax has been fixed. The CSS could be more compact ... if we did not have to deal with nested tables. It was also a goal to simplify the use for the doc comment author, such that it was possible to put just one class definition on the
tag, and not have to make additional declarations on the tags within the table. Our experiments showed that when we did not fully specify the structure, it was possible for the details of one style to "leak" into another when a table of one style was nested in another table of a different style. At this point, the goal is to introduce the class names, and to have CSS that works well enough across the major browsers. If someone wants to suggest more concise CSS that works well in all our uses cases, that would be a fine RFE for a future release. -- Jon On 5/10/17 7:10 PM, Martin Buchholz wrote: > Looks good. > > --- > > I suspect there's some way to specify the styles more compactly, but I > don't know enough css to say. > > --- > > +table.borderless thead tr th, table.borderless tbody tr th, > table.borderless tr th, > > +table.plain > thead > tr > th, table.plain > tbody > tr > th, > table.plain > tr > th, > > I was surprised at the difference in syntax; why the ">" in one but > not the other? -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.2016.kay at gmail.com Fri May 12 09:31:46 2017 From: s.2016.kay at gmail.com (Ess Kay) Date: Fri, 12 May 2017 19:31:46 +1000 Subject: private and non-final fields in Java 9 interfaces Message-ID: The Java 9 compiler currently allows 1) private static and instance fields and 2) non-final static and instance fields. Please see the attached InterfacePrivateMemberTest0.java. Is this a bug? If not then are these changes specified anywhere? -------------- next part -------------- A non-text attachment was scrubbed... Name: InterfacePrivateMemberTest0.java Type: application/octet-stream Size: 866 bytes Desc: not available URL: From maurizio.cimadamore at oracle.com Fri May 12 11:43:14 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 12 May 2017 12:43:14 +0100 Subject: private and non-final fields in Java 9 interfaces In-Reply-To: References: Message-ID: <7817351a-27c9-9a70-a1ea-27f7faac13dd@oracle.com> Did you make a mistake - e.g. used 'class' instead of 'interface' in your code? Maurizio On 12/05/17 10:31, Ess Kay wrote: > The Java 9 compiler currently allows > 1) private static and instance fields and > 2) non-final static and instance fields. > Please see the attached InterfacePrivateMemberTest0.java. > Is this a bug? If not then are these changes specified anywhere? From anthony.vanelverdinghe at gmail.com Tue May 16 17:30:26 2017 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Tue, 16 May 2017 19:30:26 +0200 Subject: How to use an annotation processor which depends on java.xml.bind? Message-ID: Hi Given an annotation processor, JaxbProcessor, and a simple source file, Test.java, as below. First I compile JaxbProcessor.java with: javac --add-modules java.xml.bind JaxbProcessor.java or, by using the JAXB RI: javac --upgrade-module-path . JaxbProcessor.java But I can't find out how to compile Test.java with the JaxbProcessor, i.e. how to replace the dots to make this succeed: javac ... -processor JaxbProcessor Test.java No matter what I try, it gives me: java.lang.NoClassDefFoundError: javax/xml/bind/JAXB So how can I use an annotation processor which depends on one of the modules that is not resolved by default? Kind regards, Anthony == Test.java @FunctionalInterface public interface Test { void test(); } == JaxbProcessor.java import java.util.Set; import javax.annotation.processing.*; import javax.lang.model.SourceVersion; import javax.lang.model.element.TypeElement; import javax.xml.bind.JAXB; @SupportedAnnotationTypes("java.lang.FunctionalInterface") public class JaxbProcessor extends AbstractProcessor { @Override public boolean process(Set set, RoundEnvironment re) { JAXB.marshal("hello", "world"); return true; } @Override public SourceVersion getSupportedSourceVersion() { return SourceVersion.latestSupported(); } } From jonathan.gibbons at oracle.com Tue May 16 17:58:50 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 16 May 2017 10:58:50 -0700 Subject: How to use an annotation processor which depends on java.xml.bind? In-Reply-To: References: Message-ID: <3ce0f1a7-90f5-fe10-3bcc-4342b98544af@oracle.com> You need to add java.xml.bind into the runtime environment underlying javac, instead of the compilation environment containing the classes being compiled. If you are running javac from the command line, use -J-add-module to pass the option to the underlying JVM. If you are running javac via an API in an existing JVM, that JVM has to be configured to include the desired module(s). -- Jon On 5/16/17 10:30 AM, Anthony Vanelverdinghe wrote: > Hi > > Given an annotation processor, JaxbProcessor, and a simple source > file, Test.java, as below. > > First I compile JaxbProcessor.java with: > javac --add-modules java.xml.bind JaxbProcessor.java > or, by using the JAXB RI: > javac --upgrade-module-path . JaxbProcessor.java > > But I can't find out how to compile Test.java with the JaxbProcessor, > i.e. how to replace the dots to make this succeed: > javac ... -processor JaxbProcessor Test.java > > No matter what I try, it gives me: java.lang.NoClassDefFoundError: > javax/xml/bind/JAXB > > So how can I use an annotation processor which depends on one of the > modules that is not resolved by default? > > Kind regards, Anthony > > == Test.java > > @FunctionalInterface > public interface Test { void test(); } > > == JaxbProcessor.java > > import java.util.Set; > import javax.annotation.processing.*; > import javax.lang.model.SourceVersion; > import javax.lang.model.element.TypeElement; > import javax.xml.bind.JAXB; > > @SupportedAnnotationTypes("java.lang.FunctionalInterface") > public class JaxbProcessor extends AbstractProcessor { > > @Override > public boolean process(Set set, > RoundEnvironment re) { > JAXB.marshal("hello", "world"); > return true; > } > > @Override > public SourceVersion getSupportedSourceVersion() { > return SourceVersion.latestSupported(); > } > > } > From anthony.vanelverdinghe at gmail.com Fri May 19 18:12:09 2017 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Fri, 19 May 2017 20:12:09 +0200 Subject: javac options interspersed with sourcefiles: supported? Message-ID: Hi Though the documentation [1] has a synopsis of `javac [options] [sourcefiles]`, javac actually allows options and sourcefiles to be interspersed, e.g.: javac -J--add-modules=java.xml.ws.annotation Foo.java -g Bar.java --release 9 -sourcepath Baz.java --release 8 -cp '*' I find this confusing (especially with long commands like the ones Maven produces) & would expect it to be rejected, so I'm wondering: is this supported behavior? If so, I believe the documentation should be updated accordingly. If not, I believe javac should explicitly reject such commands. [1] http://docs.oracle.com/javase/9/tools/javac.htm Kind regards, Anthony From jan.lahoda at oracle.com Mon May 22 11:21:19 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 22 May 2017 13:21:19 +0200 Subject: JDK-8180745: Add --release 10 as an alias for --release 9 Message-ID: <5922C9AF.2000000@oracle.com> Hi, In the JDK 10 repositories, several tests are failing: langtools/tools/javac/options/release/ReleaseOptionUnsupported.java langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestNotFound.java langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java The proposed solution here is to reintroduce --release 10 as an alias to --release 9 until a proper fix is made (which will be JDK-8180744). Bug: https://bugs.openjdk.java.net/browse/JDK-8180745 Webrev: http://cr.openjdk.java.net/~jlahoda/8180745/webrev.00/ Feedback is welcome. Thanks, Jan From maurizio.cimadamore at oracle.com Mon May 22 12:42:30 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 22 May 2017 13:42:30 +0100 Subject: JDK-8180745: Add --release 10 as an alias for --release 9 In-Reply-To: <5922C9AF.2000000@oracle.com> References: <5922C9AF.2000000@oracle.com> Message-ID: <44350b16-910d-9f08-944a-a800d6c7f75e@oracle.com> Looks good - at least as an interim fix Maurizio On 22/05/17 12:21, Jan Lahoda wrote: > Hi, > > In the JDK 10 repositories, several tests are failing: > langtools/tools/javac/options/release/ReleaseOptionUnsupported.java > langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestNotFound.java > langtools/tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java > > The proposed solution here is to reintroduce --release 10 as an alias > to --release 9 until a proper fix is made (which will be JDK-8180744). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180745 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8180745/webrev.00/ > > Feedback is welcome. > > Thanks, > Jan From daniel.smith at oracle.com Tue May 30 18:57:53 2017 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 30 May 2017 12:57:53 -0600 Subject: General Registration -- 2017 JVM Language Summit Message-ID: GENERAL REGISTRATION -- JVM LANGUAGE SUMMIT, JULY-AUGUST 2017 General registration for the 2017 JVM Language Summit is now open. The event will be held at Oracle's Santa Clara campus on July 31-August 2, 2017. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. This event is being organized by language and JVM engineers?no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. The schedule consists of a single track of traditional presentations (about 6 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-4 each day) and, possibly, impromptu "lightning talks." Workshops will be less structured than in the past, favoring an open discussion format with only a small amount of prepared material. Thus, rather than collecting workshop abstracts from speakers, we're asking each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2017 at jvmlangsummit.com