Re: RFR: 8284209: Replace remaining usages of 'a the' in source code

[Jonathan Gibbons]

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: 
> a/the, an?/an?, the/the…
> 
> It's the last issue in the series, and it still touches different areas of 
> the code.

javac and javadoc changes look OK

test/langtools/tools/javac/modules/T8168854/module-info.java line 4:

> 2:  * @test
> 3:  * @bug 8168854
> 4:  * @summary javac erroneously reject a service interface inner class in a 
> provides clause

FYI, this duplication was in the JBS issue summary; now fixed there.

-

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

Integrated: JDK-8286348: incorrect use of `@serial`

[Jonathan Gibbons]

On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons  wrote:

> Please review a fix to remove incorrect use of the `@serial` tag from the doc 
> comments for methods such as `readObject` and `readResolve`. The tag has no 
> effect in this position other than to trigger warnings from the standard 
> doclet when running javadoc.
> 
> There is no change to the generated documentation as a result off this 
> change. In particular, there is no change to the API docs for any of the 
> modified files, or to the overall top-level serialized-form.html file.
> 
> Although most of the affected files are in the `java.desktop` module, there 
> is one outlier, in `java.security.Provider`.

This pull request has now been integrated.

Changeset: 54e33082
Author:Jonathan Gibbons 
URL:   
https://git.openjdk.java.net/jdk/commit/54e33082105dcbcfc795839c954f6e63402edff1
Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod

8286348: incorrect use of `@serial`

Reviewed-by: iris, prr

-

PR: https://git.openjdk.java.net/jdk/pull/8586

Re: RFR: JDK-8286348: incorrect use of `@serial` [v3]

[Jonathan Gibbons]

> Please review a fix to remove incorrect use of the `@serial` tag from the doc 
> comments for methods such as `readObject` and `readResolve`. The tag has no 
> effect in this position other than to trigger warnings from the standard 
> doclet when running javadoc.
> 
> There is no change to the generated documentation as a result off this 
> change. In particular, there is no change to the API docs for any of the 
> modified files, or to the overall top-level serialized-form.html file.
> 
> Although most of the affected files are in the `java.desktop` module, there 
> is one outlier, in `java.security.Provider`.

Jonathan Gibbons has updated the pull request incrementally with one additional 
commit since the last revision:

  Fix whitespace (blank lines) after merge

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8586/files
  - new: https://git.openjdk.java.net/jdk/pull/8586/files/d1920183..8684b44b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8586=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8586=01-02

  Stats: 10 lines in 10 files changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8586.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8586/head:pull/8586

PR: https://git.openjdk.java.net/jdk/pull/8586

Re: RFR: JDK-8286348: incorrect use of `@serial` [v2]

[Jonathan Gibbons]

> Please review a fix to remove incorrect use of the `@serial` tag from the doc 
> comments for methods such as `readObject` and `readResolve`. The tag has no 
> effect in this position other than to trigger warnings from the standard 
> doclet when running javadoc.
> 
> There is no change to the generated documentation as a result off this 
> change. In particular, there is no change to the API docs for any of the 
> modified files, or to the overall top-level serialized-form.html file.
> 
> Although most of the affected files are in the `java.desktop` module, there 
> is one outlier, in `java.security.Provider`.

Jonathan Gibbons has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains two commits:

 - Merge with upstream/master
 - JDK-8286348: incorrect use of `@serial`

-

Changes: https://git.openjdk.java.net/jdk/pull/8586/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8586=01
  Stats: 11 lines in 11 files changed: 0 ins; 11 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8586.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8586/head:pull/8586

PR: https://git.openjdk.java.net/jdk/pull/8586

Re: RFR: JDK-8286348: incorrect use of `@serial`

[Jonathan Gibbons]

On Sun, 8 May 2022 02:19:09 GMT, Phil Race  wrote:

> Jon, all of the changes in java.desktop are already underway in 
> https://github.com/openjdk/jdk/pull/8432/files and
> have been approved and even have an approved CSR .. just waiting for 
> @alisenchung to type /integrate ..

Thanks for the heads up; I'll merge with Alisen's changes.

-

PR: https://git.openjdk.java.net/jdk/pull/8586

RFR: JDK-8286348: incorrect use of `@serial`

[Jonathan Gibbons]

Please review a fix to remove incorrect use of the `@serial` tag from the doc 
comments for methods such as `readObject` and `readResolve`. The tag has no 
effect in this position other than to trigger warnings from the standard doclet 
when running javadoc.

There is no change to the generated documentation as a result off this change. 
In particular, there is no change to the API docs for any of the modified 
files, or to the overall top-level serialized-form.html file.

Although most of the affected files are in the `java.desktop` module, there is 
one outlier, in `java.security.Provider`.

-

Commit messages:
 - JDK-8286348: incorrect use of `@serial`

Changes: https://git.openjdk.java.net/jdk/pull/8586/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8586=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286348
  Stats: 13 lines in 13 files changed: 0 ins; 13 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8586.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8586/head:pull/8586

PR: https://git.openjdk.java.net/jdk/pull/8586

Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces

[Jonathan Gibbons]

On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy  wrote:

> To enable more complete doclint checking (courtesy @jonathan-gibbons), please 
> review this PR to add type-level @param tags where they are missing.
> 
> To the maintainers of java.util.concurrent, those changes could be separated 
> out in another bug if that would ease maintenance of that code.
> 
> Making these library fixes is a blocker for correcting and expanding the 
> doclint checks (JDK-8285496).
> 
> I'll update copyright years before pushing.

src/java.base/share/classes/java/lang/ClassValue.java line 43:

> 41:  * it can use a {@code ClassValue} to cache information needed to
> 42:  * perform the message send quickly, for each class encountered.
> 43:  * @param  type of the derived value

stylistically, compared to other comments, you are missing an initial "the"

-

PR: https://git.openjdk.java.net/jdk/pull/8410

Re: RFR: 8257733: Move module-specific data from make to respective module [v13]

[Jonathan Gibbons]

On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie  wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. 
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by 
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by 
>> make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after 
>> all, "source code" for that module that is "compiler" into resulting 
>> deliverables, for that module. (But the "source code" language is not Java 
>> or C, but typically a highly domain specific language or data format, and 
>> the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. 
>> When such data is changed, most of the time build-dev (or the new build 
>> label) is involved, even though this has nothing to do with the build. While 
>> this is annoying, a worse problem is if the actual team that needs to review 
>> the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to 
> a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into shuffle-data
>  - Correct name for bfc files
>  - Merge tag 'jdk-19+14' into shuffle-data
>
>Added tag jdk-19+14 for changeset 08cadb47
>  - Move x11wrappergen from share/data to unix/data
>  - Fix fontconfig according to review request
>  - Fix typos
>  - Restore charsetmapping and cldr to make/data
>  - Update copyright year
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - ... and 10 more: 
> https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d

As before, the changes for `jdk.compiler` and `idk.javadoc` look OK, and if 
there is general consensus on the overall proposed move, then I think that 
overall it is a good idea.

I did not review the `jdk.compiler` in low-level detail, but scanning the 
webrev index file, the changes seemed OK, and a pure move (no lines changed.)

It might have been better to have handled this on a per-module basis, rather 
than all-at-once, but whatever ...

-

PR: https://git.openjdk.java.net/jdk/pull/1611

Re: RFR: 8279918: Fix various doc typos [v2]

[Jonathan Gibbons]

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo  wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, 
>> please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant 
>> formatting artefact and thus can be removed.
>> - `` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Additional typos

jdk.compiler and jdk.javadoc look good

-

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7063

Re: RFR: 8279918: Fix various doc typos [v2]

[Jonathan Gibbons]

On Thu, 13 Jan 2022 11:40:20 GMT, Lance Andersen  wrote:

>> OK, so lines 264,  295, 329, 364, 431 are arguably wrong as well?  
>> Separating the [] completely looks quite rare.
>> I'll leave it up to you. 8-)
>
> I think that can be a follow on clean up.

The strange formatting of `long []updateCounts` looks very unusual and well 
worth a followup cleanup.

-

PR: https://git.openjdk.java.net/jdk/pull/7063

Re: RFR: 8263105: security-libs doclint cleanup

[Jonathan Gibbons]

On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore  wrote:

> Fix various things pointed out by the most recent doclint run in the 
> security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running 
> tier1/tier2 tests.  Minor spot checks on generated files.

I've read the first 10 files. The edits are definitely in the right direction, 
and will address the "missing comments" issues.

I'll leave it up to you and the others in your team to decide what level of 
stylistic consistency you would like for the new comments, but just having a 
relevant comment at all is a great start.

src/java.base/share/classes/java/security/BasicPermission.java line 497:

> 495: /**
> 496:  * @serialData Default fields.
> 497:  */

FWIW, this doc comment will be ignored, because it will be superseded by the 
new comment on line 499.  At some point doen the road, you may get a warning 
from javac about an ignored doc comment.

src/java.base/share/classes/java/security/GuardedObject.java line 64:

> 62: 
> 63: /**
> 64:  * The guard object

add a period?

src/java.base/share/classes/java/security/PermissionCollection.java line 105:

> 103:  * Whether this permission collection is read-only.
> 104:  * 
> 105:  * If set, add() will throw an exception.

maybe use `{@code}` or `{@link}` on add?

src/java.base/share/classes/java/security/Permissions.java line 581:

> 579: /**
> 580:  * @serialData Default fields.
> 581:  */

Another ignored comment. I suggest just changing these to `/*` comments.

-

PR: https://git.openjdk.java.net/jdk/pull/2856

Integrated: JDK-8263104: fix warnings for empty paragraphs

[Jonathan Gibbons]

On Fri, 5 Mar 2021 19:36:13 GMT, Jonathan Gibbons  wrote:

> Please review some simple cleanup for empty `` tags.
> 
> Two of the tags are completely redundant, and simply deleted.
> 
> The other three, in _package.html_ files are generally undesirable. Although 
> the presumed intent of the `id` declaration is to label the `@see` info, 
> proximity in the source code does not ensure proximity in the generated code. 
> The actual result is an empty paragraph at the end of the enclosing generated 
> ``, and before the generated output for the `@since` tag.
> 
> The better solution is to move the `id` declaration into the `@see  href...` and then delete the empty ``.

This pull request has now been integrated.

Changeset: 71829850
Author:Jonathan Gibbons 
URL:   https://git.openjdk.java.net/jdk/commit/71829850
Stats: 8 lines in 5 files changed: 0 ins; 4 del; 4 mod

8263104: fix warnings for empty paragraphs

Reviewed-by: alanb, lancea

-

PR: https://git.openjdk.java.net/jdk/pull/2850

RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module

[Jonathan Gibbons]

Please review some minor doc fixes, for issues found by _doccheck_.There 
are two kinds of errors that are addressed.

1. Incorrect use of ``. In HTML, `` marks the *beginning* of a paragraph. 
It is not a terminator, to mark the end of a paragraph, or a separator to mark 
the boundary between paragraphs.  In particular, it should not be used at the 
end of a description before a javadoc block tag, such as `@param` or before 
other HTML block tags, like `` or ``.

2. References to the id `package-description`, following the recent 
standardization of all ids generated by javadoc,

-

Commit messages:
 - JDK-8262875: doccheck: empty paragraphs, etc in java.base module

Changes: https://git.openjdk.java.net/jdk/pull/2795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2795=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262875
  Stats: 9 lines in 8 files changed: 0 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2795/head:pull/2795

PR: https://git.openjdk.java.net/jdk/pull/2795

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

[Jonathan Gibbons]

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie  wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. 
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by 
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by 
>> make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after 
>> all, "source code" for that module that is "compiler" into resulting 
>> deliverables, for that module. (But the "source code" language is not Java 
>> or C, but typically a highly domain specific language or data format, and 
>> the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. 
>> When such data is changed, most of the time build-dev (or the new build 
>> label) is involved, even though this has nothing to do with the build. While 
>> this is annoying, a worse problem is if the actual team that needs to review 
>> the patch (i.e., the team owning the module) is missed in the review.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

I have reviewed all lines in the patch file with or near instances of 
`jdk.compiler`

-

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611

Integrated: JDK-8255262: Remove use of legacy custom @spec tag

[Jonathan Gibbons]

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons  wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

This pull request has now been integrated.

Changeset: 0aa3c925
Author:    Jonathan Gibbons 
URL:   https://git.openjdk.java.net/jdk/commit/0aa3c925
Stats: 209 lines in 69 files changed: 0 ins; 209 del; 0 mod

8255262: Remove use of legacy custom @spec tag

Reviewed-by: lancea, mr, iris, alanb, darcy, mchung

-

PR: https://git.openjdk.java.net/jdk/pull/814

RFR: JDK-8255262: Remove use of legacy custom @spec tag

[Jonathan Gibbons]

The change is (just) to remove legacy usages of a JDK-private custom tag.

-

Commit messages:
 - JDK-8255262: Remove use of legacy custom @spec tag

Changes: https://git.openjdk.java.net/jdk/pull/814/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=814=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255262
  Stats: 209 lines in 69 files changed: 0 ins; 209 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/814.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/814/head:pull/814

PR: https://git.openjdk.java.net/jdk/pull/814

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

[Jonathan Gibbons]

On Thu, 10 Sep 2020 12:04:48 GMT, Dmitriy Dumanskiy 
 wrote:

> I have in mind dozens of improvements all over the code like this one.

That sounds scary. Broad updates like these cause unnecessary churn in the 
codebase, and can make merging and back
porting harder.  Changes should be discussed ahead of time with the appropriate 
teams.

-

PR: https://git.openjdk.java.net/jdk/pull/29

Re: Fix for Javadoc errors in java.base

[Jonathan Gibbons]

On 8/13/20 10:13 AM, Sean Mullan wrote:

On 8/13/20 11:05 AM, Julia Boes wrote:

Hi Vipin,

Thanks for providing this fix, I'm happy to sponsor your change. To 
complete the review, we still need someone to green light the 
remaining changes below. I'm looping in net-dev and security-dev to 
have a look.


Bug: https://bugs.openjdk.java.net/browse/JDK-8251542

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/

Once the review is completed, please provide me with a patch that 
includes a changeset comment as described here: 
https://openjdk.java.net/guide/producingChangeset.html


If you have any questions, let me know.

Cheers,

Julia

--- 
old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java

2020-07-25 23:46:21.233726447 +0530
+++ 
new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java

2020-07-25 23:46:20.721720857 +0530
@@ -96,8 +96,6 @@
   * @param p the prime modulus
   * @param g the base generator
   * @param l the private-value length
- *
- * @exception InvalidKeyException if the key cannot be encoded


This should actually remain, but it should be ProviderException which 
is a RuntimeException. See the other DHPrivateKey ctor as that 
specifies it correctly.


--Sean



I note the use of `@exception`, as compared to `@throws`, which is more 
common.


Stats:
`@exception` 7322 occurrences
`@throws` 21173 occurrences

That's probably too many `@exception` to clean up. :-(

-- Jon

FYI: new javadoc tag to document system properties

[Jonathan Gibbons]

This is an FYI to announce some initial, long-overdue support in javadoc 
for documenting system properties (JDK-5076751).


Currently, system properties are just documented using ad-hoc narrative 
text, which is fine if you know where to look for any given property.


JDK 12 introduces a new inline javadoc tag, {@systemProperty 
/property-name/} which can be used to "declare" the name of a system 
property. You can use this tag as a drop-in replacement for the 
plain-text property name; it will have no overt effect on the narrative 
text, but it will cause the property name to be put into the search 
index and the A-Z index. Thus, property names will become searchable, to 
allow users to easily find the definition of any such system property.


Adding support into javadoc is only part of the story. Now that the 
support is in javadoc, we want to update the API documentation, so that 
the documentation is updated for all Java SE and JDK system properties.


Where should the tag be used?  The tag should be used in the text of the 
defining instance of the property.  This is where the characteristics of 
the system property are described, which may include information like: 
"what is the property for", "how and when is it set", "can it be 
modified", and so on. For example, it could be used in the docs for 
System.getProperties [1] or Networking Properties [2] In general, it 
should -not- be used in situations that merely refer to the system 
property by name.  For example, the docs for Path.toAbsolutePath [3] 
make a reference to the system property user.dir, but that is not a 
definition of the property.


Going forward, in future releases, we expect to explore some 
enhancements to this feature. Here are some of the ideas that have been 
suggested:


 * Create a "summary page" that lists all the system properties. This
   would be somewhat similar to the current top-level "Constant Values"
   page.
 * Add information regarding the "scope" of the definition: is it
   defined by the Java SE specification, or JDK, or JavaFX, etc. This
   information could be used to organize the content on the summary page.
 * Update @see and {@link} to be able to refer to system properties.
 * Allow a short description to be included in the {@systemProperty}
   tag. This text could be included in the search index, the A-Z index,
   and the summary page.

-- Jon


[1]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties()
[2]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html
[3]: 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath()

Re: RFR [12]: 8211878: Bad/broken links in docs/api/java.xml.crypto/javax/xml/crypto/dsig/Reference.html

[Jonathan Gibbons]

Looks good to me.

-- Jon


On 10/10/18 9:33 AM, Sean Mullan wrote:

Please review this trivial fix to correct a couple of broken hyperlinks:

diff --git 
a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java 
b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java
--- 
a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java
+++ 
b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -144,7 +144,7 @@

 /**
  * Returns the dereferenced data, if
- * reference 
caching
+ * reference 
caching

  * is enabled. This is the result of dereferencing the URI of this
  * reference during a validation or generation operation.
  *
@@ -156,7 +156,7 @@

 /**
  * Returns the pre-digested input stream, if
- * reference 
caching
+ * reference 
caching

  * is enabled. This is the input to the digest operation during a
  * validation or signing operation.
  *

Thanks,
Sean

Re: RFR: JDK-8210274: Source Launcher should work with a security manager

[Jonathan Gibbons]

On 09/11/2018 12:53 PM, Sean Mullan wrote:
I have looked over the changes and they look reasonable, though I am 
not very familiar with this code.


I was wondering, when running with the PermissiveTestSecurityManager 
did you also have to enable security debugging (ex: 
java.security.debug=access) so that you log the permissions that were 
required? If so, it might be helpful to add that to the comments in 
the test. If not, how did you figure that out? - it's not immediately 
apparent when looking at the code.


--Sean 


Sean,

Thanks for looking at this.

I did not need to enable any security debugging when using the 
PermissiveTestSecurityManager. For the most part, the basic security 
infrastructure was good enough by itself, since it reported enough 
information in the SecurityExceptions to be able to easily determine the 
missing but  required permissions. It helped to have a sense of what 
permissions might be required, such file access, system properties, and 
permissions for class loaders and reflections in some limited parts of 
javac, and the corresponding tests in the test suite. The most "tedious" 
part was just running the tests until all the issues had been found and 
fixed, but that being said, the overall process converged pretty quickly.


I will note that PermissiveTestSecurityManager arrived late in the game 
for this work. For the most part, I was using the plain standard 
security manager, and was adding permissions for tests as needed in a 
custom policy file that I also specified on the jtreg command line. That 
work could never have been checked in, since it involved lots of 
host-specific paths in the additional policy file. It was only later on 
that I came up with the idea of using first a custom security manager, 
and from there, the idea of using a custom policy in the custom security 
manager.  The use of PermissiveTestSecurityManager made it much faster 
to find and fix all remaining issues and enabled me to achieve the goal 
of getting all javac tests to work, instead of settling for most tests. 
(I had previously been prepared to set aside and ignore the main block 
of annotation processing tests.)


-- Jon

Re: RFR: JDK-8210274: Source Launcher should work with a security manager

[Jonathan Gibbons]

Alan,

Thanks for all the feedback.  I'll add the extra test case you suggest.

-- Jon



On 09/11/2018 12:34 PM, Alan Bateman wrote:

On 11/09/2018 19:42, Jonathan Gibbons wrote:

:

As regards the interaction between Source Launcher and the use of a 
security manager, I see 3 possibilities:


1. Specifically support it, as provided in this webrev
2. No code change, but update JEP 330 to specify the behavior
3. Explicitly reject the combination of Source Launcher and the 
security manager.
Since you've started into this then it's probably best to just 
continue with #1 and get it done. My main point here was the test in 
the webrev sets the security manager on the command line and I think 
you also need another test that sets in the test main method.





Is there any way (spi.ToolProvider or some means) for untrusted code 
to indirectly run the source launcher? This question is important 
because the updated source launcher could be abused to probe 
anywhere on the file system.
Untrusted code can only run the source launcher by breaking 
encapsulation on the command line.  The source launcher is a 
combination of native code in the launcher itself and a class in an 
unexported package of jdk.compiler.  Even if you could access the 
source launcher, the compilation command line (i.e. the args for the 
internal call to javac) is highly constrained, and so it is difficult 
to see how the source launcher could be abused.
Thanks, the question had to be asked because the privileged block in 
the source launcher main means it can access any file.




What are the implications for uses of javax.tools and 
com.sun.tools.javac.Main in code running with a security manager? 
Maybe that is a separate project but I would have expected to see 
privileged blocks in places that need permissions.
The intent was to stay clear (in this changeset) of all other ways of 
invoking javac, meaning javax.tools, com.sun.tools.javac.Main and 
spi.ToolProvider. While there are relatively few ways to invoke 
javac, these ways all permit the use of annotation processors and 
other callbacks, and so we would need privileged blocks in all places 
where callbacks could re-enter javac.
That is what I was wondering about it. I don't see a queue at the door 
of developers looking to run javac with a security manager but at the 
same time it is possible to configure many app servers with JSP 
support to run with a security manager. I assume they must have 
historically granted at least some permissions to "tools.jar" for this 
to work.




If we were to drop the support for a security manager from the source 
launcher, would you still consider it worthwhile to update the policy 
file to enumerate the privileges required to run javac? Setting aside 
the updates for the Source Launcher tests, I think the work to 
improve all the other tests to function better when a security 
manager is involved is also worth while.
It took a lot of work in JDK 9 to identify the minimum permissions 
needed by several modules. The java.xml.bind and java.xml.ws modules 
took a lot of effort because of the callbacks and missing privileged 
blocks. It does take a lot of effort and testing to be confident. So 
my personal view (and not my call) is that it's probably not high 
priority to do the same for jdk.compiler at this time.


-Alan

Re: RFR: JDK-8210274: Source Launcher should work with a security manager

[Jonathan Gibbons]

On 9/11/18 12:58 AM, Alan Bateman wrote:

On 10/09/2018 21:37, Jonathan Gibbons wrote:
Please review a patch to have the Source Launcher be able to work 
when a security manager is enabled.
It's not clear to me that this is an interesting use-case but in any 
case I think you've got two scenarios to test. One is setting 
java.security.manager on the command line, the other is the launched 
code's main method calling System.setSecurityManager which amounts to 
setting a security manager in a running VM. You might want to add a 
test case for the latter.


I agree that this may not be a very interesting use case, and I have no 
strong feelings about whether or not to support it, except to say that I 
think we should specify the interaction between Source Launcher and the 
use of a security manager.  I note that this piece of work was triggered 
by the recent change to support the getResource* family of methods in 
the classloader used to run the user classes. At that time, it was noted 
that creating the URL involved directly calling a method that needed a 
privilege to be available (NetPermission specifyStreamHandler) (as 
compared to all the permissions indirectly required when invoking the 
compiler.)


As regards the interaction between Source Launcher and the use of a 
security manager, I see 3 possibilities:


1. Specifically support it, as provided in this webrev
2. No code change, but update JEP 330 to specify the behavior
3. Explicitly reject the combination of Source Launcher and the security 
manager.




Is there any way (spi.ToolProvider or some means) for untrusted code 
to indirectly run the source launcher? This question is important 
because the updated source launcher could be abused to probe anywhere 
on the file system.
Untrusted code can only run the source launcher by breaking 
encapsulation on the command line.  The source launcher is a combination 
of native code in the launcher itself and a class in an unexported 
package of jdk.compiler.  Even if you could access the source launcher, 
the compilation command line (i.e. the args for the internal call to 
javac) is highly constrained, and so it is difficult to see how the 
source launcher could be abused.


What are the implications for uses of javax.tools and 
com.sun.tools.javac.Main in code running with a security manager? 
Maybe that is a separate project but I would have expected to see 
privileged blocks in places that need permissions.
The intent was to stay clear (in this changeset) of all other ways of 
invoking javac, meaning javax.tools, com.sun.tools.javac.Main and 
spi.ToolProvider. While there are relatively few ways to invoke javac, 
these ways all permit the use of annotation processors and other 
callbacks, and so we would need privileged blocks in all places where 
callbacks could re-enter javac.


-Alan


If we were to drop the support for a security manager from the source 
launcher, would you still consider it worthwhile to update the policy 
file to enumerate the privileges required to run javac? Setting aside 
the updates for the Source Launcher tests, I think the work to improve 
all the other tests to function better when a security manager is 
involved is also worth while.


-- Jon

RFR: JDK-8210274: Source Launcher should work with a security manager

[Jonathan Gibbons]

Please review a patch to have the Source Launcher be able to work when a 
security manager is enabled.


There are 4 parts to the work: an update to the default policy file, an 
update to the source launcher itself, updates to tests, and a custom 
security manager to help with testing.


1. src/java.base/share/lib/security/default.policy

Add reasonably fine-grain permissions to give javac the permissions it 
needs to run when a security manager is enabled. These permissions were 
determined by running all javac tests under with a special security 
manager installed: more on that later. There is one anomalous property 
which was detected, which is a property to control some internal javac 
behavior. Arguably, it should eventually be renamed with at least a 
"javac.*" prefix.


2. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java

Update the source launcher to use doPrivileged in a couple of places: 
most notably around the main invocation of javac. Generally, it 
continues to be the policy that command-line tools like javac, javadoc 
do not use fine-grained doPrivileged blocks throughout the tool, and 
this update does not change that.  It is worth noting that when javac is 
invoked from the Source Launcher, it does not support callbacks like 
annotation processors, task listeners, and other plugin code, so that 
eliminates any issues relating to using callbacks from code in a 
doPrivileged block.


3. test/langtools/tools/lib/security/PermissiveTestSecurityManager.java

This is a custom new security manager for manual testing purposes in 
conjunction with jtreg, so that we can run a large subset of tests under 
the influence of a security manager. . It is a design characteristic of 
jtreg that almost all tests have their own distinct codebase, and so it 
is impractical to use a modified policy file to grant all necessary 
permissions to all necessary tests, so this security manager installs a 
custom Policy object that grants permissions to test code while 
deferring to the system policy for everything else (and for javac in 
particular.)   Using this security manager, it is possible to run all 
the javac tests to detect with high probability all the permissions that 
it requires. Using a custom security manager to install a custom Policy 
object allows the feature to be easily enabled on the jtreg command line.


There is one workaround in this security manager: a bug was uncovered 
such that the jdk.zipfs module needs permission to access the user.dir 
system property.  ( https://bugs.openjdk.java.net/browse/JDK-8210469 )  
A temporary workaround is used to get a clean test run.


Note: this code is not directly used in any normal/automated test runs 
for javac; nevertheless, it is deemed worthwhile to save the code for 
use in similar situations in the future.


4. Minor updates to tests.

Some new test cases are added to Source Launcher tests.

Although most tests are not directly affected by the use of a security 
manager, there are some exceptions. Some tests manipulate the security 
manager and/or expect the security manager to be unset.  These tests are 
modified to "pass by default" if the runtime conditions are not suitable 
(i.e. a security manager has been installed.)


Although it is not a requirement to be able to run annotation processing 
tests when a security manager is enabled (because that condition cannot 
arise with the Source Launcher), most annotation processing tests do run 
successfully. There were 3 exceptions, where the test required more 
permissions than granted to javac in code being called from javac. These 
permissions were to access test.* system properties and the setIO 
runtime permission. Rather than grant unnecessary properties to javac, 
it was enough to use doPrivileged in a couple of places in the javac 
"toolbox" test library, and to refactor those tests to better use toolbox.


In conjunction with these changes,ignoring any tests on the ProblemList, 
all javac tests pass, with and without a security manager being present.



JBS: https://bugs.openjdk.java.net/browse/JDK-8210274
Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.00/


-- Jon

Re: RFR: JDK-8186160 Fix a11y issues in java.security package

[Jonathan Gibbons]

Brad,

Thanks. I should have noted that the issues were detected by checking tools,
and that after the edits, no such issues were reported in this package.

FWIW, there is one remaining issue to be addressed: it is a broken link 
in Provider.html.

It comes from Provider.replace(Object, Object, Object) which overrides
Properties.replace(Object, Object, Object), but for some reason, that 
method is

marked @hidden in Properties, causing a broken link in Provider. That needs
to be investigated, but I don't want to block these accessibility fixes.

-- Jon


On 08/11/2017 05:14 PM, Bradford Wetmore wrote:
Changes look good to me, although I'm not an HTML expert nor an expert 
in our current documentation style.  I did compare the output, and can 
see the effects.  (Striped, scope (row vs col), style)


Brad



On 8/11/2017 5:01 PM, Jonathan Gibbons wrote:
Please review the following small fix for some accessibility issues 
in the java.security package.


3 tables are converted to the de-facto JDK standard for row-oriented 
tables, and updated
with appropriate scope=row|col attributes to identify the header cell 
in each row or column.

You can see the appearance of the updated tables in the API link below.

This is part of the ongoing effort to clean up all such issues in the 
JDK documentation.


JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
API: http://cr.openjdk.java.net/~jjg/8186160/api.00

-- Jon

RFR: JDK-8186160 Fix a11y issues in java.security package

[Jonathan Gibbons]

Please review the following small fix for some accessibility issues in 
the java.security package.


3 tables are converted to the de-facto JDK standard for row-oriented 
tables, and updated
with appropriate scope=row|col attributes to identify the header cell in 
each row or column.

You can see the appearance of the updated tables in the API link below.

This is part of the ongoing effort to clean up all such issues in the 
JDK documentation.


JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
API: http://cr.openjdk.java.net/~jjg/8186160/api.00

-- Jon

Re: RFR: 8184208: update class="striped" tables for accessibility

[Jonathan Gibbons]

On 07/11/2017 04:02 PM, Brian Burkhalter wrote:
On Jul 11, 2017, at 2:39 PM, Jonathan Gibbons 
<jonathan.gibb...@oracle.com <mailto:jonathan.gibb...@oracle.com>> wrote:


Please review this auto-generated update to improve the accessibility 
of many of the tables

in the API docs for the java.base module.


Looks all right to me.

All the modifiied tables have been visually checked with an 
accessibility checker.


There does not however appear to be a visual difference between the 
JDK 9 javadoc and the javadoc generated in a JDK 10 clone with this 
patch applied.


Brian


Brian,

Yes, the differences will show up when using a screen reader or some 
form of accessibility checker. There should not be any noticeable 
difference  for most users.


-- Jon

RFR: 8184208: update class="striped" tables for accessibility

[Jonathan Gibbons]

Please review this auto-generated update to improve the accessibility of 
many of the tables

in the API docs for the java.base module.

The changes are just to the HTML markup for selected tables;
there is no change to the wording of any documentation.

This update was generated by a utility program that looks for tables 
using the

CSS style class "striped", and updates those tables as follows:

* header cells () in the  now declare scope="col"
* the first data cell () in each row in the  are changed to 
and declare scope="row".
Although these cells are changed from  to , the CSS still 
uses font-weight-normal for

these cells.

The changes are in line with HTML 5 and WCAG 2.0.

This update does not include the following tables, which will be done 
separately (manually)


* tables with CSS class "borderless" (18), "plain" (37), or no class (6)
* tables in java.time.chrono (5): although these table use "striped",
the first column does not contain unique values, and is therefore 
unsuited for the

automated update

All the modifiied tables have been visually checked with an 
accessibility checker.


JBS: https://bugs.openjdk.java.net/browse/JDK-8184208
Webrev: http://cr.openjdk.java.net/~jjg/8184208/webrev.00/
API: http://cr.openjdk.java.net/~jjg/8184208/api.00/

-- Jon

Re: RFR: [Updated] Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

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?

Re: RFR: [Updated] Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

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

RFR: [Updated] Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

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

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

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

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

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

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

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 
<jonathan.gibb...@oracle.com <mailto:jonathan.gibb...@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

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

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

RFR: Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

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

Re: RFR: 8179370: Replace use of , and tags in java.base

[Jonathan Gibbons]

Updated webrev to address Joe's suggestion to try harder to use {@code} 
as a substitute for .


http://cr.openjdk.java.net/~jjg/8179370/webrev.01

The modified sed script has a new first line:

s|\([^&<>]*\)|{@code \1}|g
s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(<td[^>]*\)>\([^<]*\)|\1 style="text-align:center">\2|
s|
s|||
s|||

Also note that there is a small visible bug in webrev. If you look at 
ServiceLoader.java:133,
the second instance of  is not converted to {@code} because the 
embedded '\' is actually
an entity in the source file ... and so it is inappropriate to use 
{@code} for that instance.


-- Jon



On 04/26/2017 06:09 PM, Jonathan Gibbons wrote:

Joe,

Yes, there are occurrences here that require  instead of 
{@code}, because of the presence of HTML entities. It's about 50/50.


I'd prefer to stay with mechanical updates as much as possible for 
these bulk updates, as compared to manual updates, but I may be able 
to improve the sed script for this case.


-- Jon

On 04/26/2017 05:55 PM, Joseph D. Darcy wrote:

Hi Jon,

I'd prefer if the "foo" were replaced with "{@code tt}" 
rather than "foo"- none of the tricky cases which 
preclude use of {@code } use seem to be present here - but will 
approve the changeset in its current form too.


Cheers,

-Joe

On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
Please review these mostly simple changes to replace HTML tags which 
are not valid in HTML 5 in public doc comments in java.base.


As with the previous changes, the changes were done mechanically, 
using the following sed script:


s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(<td[^>]*\)>\([^<]*\)|\1 
style="text-align:center">\2|
s|style="margin:0 auto" |

s|||
s|||

The unusual form of the 3rd line was to cover the occurrence in a 
makefile.


The 4th line is specific for DataInput.java, and replaces  
within a  with a style on the  element itself.


The 5th and 6th lines are specific to URLConnection. The use of the 
table itself and the ASCII art that follows it are questionable, but 
the intent here is just to update the HTML and not to rework the 
visual appearance of the generated documentation.


The changes cover files in the following packages:

java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl


JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/

-- Jon

Re: RFR: 8179370: Replace use of , and tags in java.base

[Jonathan Gibbons]

Joe,

Yes, there are occurrences here that require  instead of {@code}, 
because of the presence of HTML entities. It's about 50/50.


I'd prefer to stay with mechanical updates as much as possible for these 
bulk updates, as compared to manual updates, but I may be able to 
improve the sed script for this case.


-- Jon

On 04/26/2017 05:55 PM, Joseph D. Darcy wrote:

Hi Jon,

I'd prefer if the "foo" were replaced with "{@code tt}" 
rather than "foo"- none of the tricky cases which 
preclude use of {@code } use seem to be present here - but will 
approve the changeset in its current form too.


Cheers,

-Joe

On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
Please review these mostly simple changes to replace HTML tags which 
are not valid in HTML 5 in public doc comments in java.base.


As with the previous changes, the changes were done mechanically, 
using the following sed script:


s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(<td[^>]*\)>\([^<]*\)|\1 
style="text-align:center">\2|
s|style="margin:0 auto" |

s|||
s|||

The unusual form of the 3rd line was to cover the occurrence in a 
makefile.


The 4th line is specific for DataInput.java, and replaces  
within a  with a style on the  element itself.


The 5th and 6th lines are specific to URLConnection. The use of the 
table itself and the ASCII art that follows it are questionable, but 
the intent here is just to update the HTML and not to rework the 
visual appearance of the generated documentation.


The changes cover files in the following packages:

java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl


JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/

-- Jon

RFR: 8179370: Replace use of , and tags in java.base

[Jonathan Gibbons]

Please review these mostly simple changes to replace HTML tags which are 
not valid in HTML 5 in public doc comments in java.base.


As with the previous changes, the changes were done mechanically, using 
the following sed script:


s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(]*\)>\([^<]*\)|\1 style="text-align:center">\2|
s|
s|||
s|||

The unusual form of the 3rd line was to cover the occurrence in a makefile.

The 4th line is specific for DataInput.java, and replaces  
within a  with a style on the  element itself.


The 5th and 6th lines are specific to URLConnection. The use of the 
table itself and the ASCII art that follows it are questionable, but the 
intent here is just to update the HTML and not to rework the visual 
appearance of the generated documentation.


The changes cover files in the following packages:

java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl


JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/

-- Jon

Re: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

[Jonathan Gibbons]

The test can also report which providers it is testing and/or skipping, 
so that anyone checking the .jtr file can verify the behavior.


Maybe it fails if expected modules or providers are not found.

-- Jon


On 06/29/2016 10:50 AM, Mandy Chung wrote:

Valerie’s suggestion is a good one.  The test will require a minimum image with 
cross-platform security providers to run the test while it can still verify 
other platform-specific providers.

Mandy


On Jun 29, 2016, at 10:41 AM, Valerie Peng  wrote:


It's not like the test silently passes as the test still covers the 
cross-platform modules.
The way I view this is that the platform=specific modules are "optional" and we 
update the expected result by detecting their presence (or the not). It's not a hack or 
workaround, but rather an enhancement for the test to handle different images.

Just my .02,
Valerie

On 6/29/2016 10:22 AM, Alexandre (Shura) Iline wrote:

On Jun 28, 2016, at 5:22 PM, Valerie Peng  wrote:


One of the purpose of this test is to test the ordering (see the initial bug 
which this test is for: JDK-6997010).

The original test already detects the OS and will skip certain providers 
accordingly.
Instead of splitting the test into multiple platform-specific tests, maybe we 
can keep the original test but add module-presence checking? Is there API 
available to query if certain module are present?

ModuleFinder.ofSystem().find(String).

We can have only the cross-platform modules listed in @modules and make the 
test to pass silently if the required platform-specific modules are not present.

So, for example, on windows, if the test would be executed against an image 
which have no jdk.crypto.mscapi, the test will not run any checks and report 
pass.

This would help to avoid the additional test creation, but it will add another 
silently passing test, which is less clean.

Mandy?

Shura


If yes, then we can leave out the platform-specific providers from the @modules 
line and skip the providers if either the OS does not match or the module is 
not present.

If we can't query what modules are available, then we may have to think of 
something else.
Valerie

On 6/27/2016 12:27 PM, Mandy Chung wrote:

I’m including security-dev which would be a better list to review this test fix.

Valerie,
Does this test have to be order-sensitive?  I think this test would be 
cleaner to make it order-insensitive and simply test the security provider 
initialization.

See my comments below.


On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline 
 wrote:

Hi.

Please take a look on a suggested for for the 
java/lang/SecurityManager/CheckSecurityProvider.java test.

The test in question depend on a list of modules, some of them are 
platform-specific. Listing all the dependencies in one test is causing the test 
to be skipped on every platform. In an offline conversation it was decided that 
it is better to split this tests into a few tests to declare the per-platform 
module dependencies.

The bug: https://bugs.openjdk.java.net/browse/JDK-8158670
The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/

The copyright header start year of the new tests should be 2016.

I would suggest to make CheckSecurityProvide a platform-neutral test, i.e.,
- drop @requires
- make line 94-97 to ignore the platform-dependent provider if it’s present in 
the white list

If we could make this test order-insensitive, it’d be cleaner to maintain a 
platform-neutral list of security providers and one list for the 
platform-dependent security providers for each platform.  Just an idea.

Mandy

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

[Jonathan Gibbons]

On 03/11/2016 07:28 PM, joe darcy wrote:

Hello,

As Jon Gibbons has noted off-list, the problem list entries can 
directly include the bug number associated with the test in question, 
enabling better reporting. This format should be used rather than the 
current convention of putting the bug number in a comment.


Please review the webrev to adopt the revised format for the problem 
list:


http://cr.openjdk.java.net/~darcy/8151763.0/

I've verified jtreg produces the same test list with the old and new 
versions of the problem list.


Thanks,

-Joe



Joe,

You can use a comma-separated list when multiple bugs are involved.   
The only restriction is,  no embedded whitespace within the list


 342 # Also 8080165
 343 java/util/Arrays/ParallelPrefix.java   8085982 generic-all

can be

 343 java/util/Arrays/ParallelPrefix.java   8085982,8080165 generic-all


-- Jon

hg: jdk8/tl/langtools: 8028318: [doclint] doclint will reject existing user-written doc comments using custom tags that follow the recommended rules

[jonathan . gibbons]

Changeset: a78f51d6bd5e
Author:jjg
Date:  2013-11-25 17:42 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a78f51d6bd5e

8028318: [doclint] doclint will reject existing user-written doc comments using 
custom tags that follow the recommended rules
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! test/tools/doclint/CustomTagTest.java
! test/tools/doclint/CustomTagTest.out
! test/tools/doclint/CustomTagTestWithOption.out

hg: jdk8/tl/langtools: 2 new changesets

[jonathan . gibbons]

Changeset: 351d6808c1a5
Author:jjg
Date:  2013-10-22 17:42 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/351d6808c1a5

8027119: Cleanup javadoc comments for taglet API
Reviewed-by: mduigou

! src/share/classes/com/sun/javadoc/Tag.java

Changeset: 41d3ffca22ff
Author:jjg
Date:  2013-10-22 17:44 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/41d3ffca22ff

Merge

hg: jdk8/tl/langtools: 8025109: Better encapsulation for AnnotatedType

[jonathan . gibbons]

Changeset: e5d3cd43c85e
Author:jjg
Date:  2013-10-20 12:01 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e5d3cd43c85e

8025109: Better encapsulation for AnnotatedType
Reviewed-by: jjg
Contributed-by: wdi...@gmail.com

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java

hg: jdk8/tl/langtools: 8026791: wrong type_path encoded for method_return on an inner class constructor

[jonathan . gibbons]

Changeset: ae4f5cb78ebd
Author:jjg
Date:  2013-10-20 12:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ae4f5cb78ebd

8026791: wrong type_path encoded for method_return on an inner class constructor
Reviewed-by: jjg
Contributed-by: wdi...@gmail.com

! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java

hg: jdk8/tl/langtools: 8026749: Missing LV table in lambda bodies

[jonathan . gibbons]

Changeset: 7de97abc4a5c
Author:jjg
Date:  2013-10-18 15:03 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7de97abc4a5c

8026749: Missing LV table in lambda bodies
Reviewed-by: vromero, jlahoda

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/lambda/LocalVariableTable.java

hg: jdk8/tl/langtools: 8026704: Build failure with --enable-debug

[jonathan . gibbons]

Changeset: d7e155f874a7
Author:jjg
Date:  2013-10-16 10:47 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d7e155f874a7

8026704: Build failure with --enable-debug
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
- test/tools/javac/lambda/LocalVariableTable.java

hg: jdk8/tl/langtools: 8025998: Missing LV table in lambda bodies

[jonathan . gibbons]

Changeset: 09a414673570
Author:jjg
Date:  2013-10-14 23:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09a414673570

8025998: Missing LV table in lambda bodies
Reviewed-by: vromero

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/lambda/LocalVariableTable.java

hg: jdk8/tl/langtools: 8026564: import changes from type-annotations forest

[jonathan . gibbons]

Changeset: b0c086cd4520
Author:jjg
Date:  2013-10-15 15:57 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0c086cd4520

8026564: import changes from type-annotations forest
Reviewed-by: jjg
Contributed-by: wdi...@gmail.com, steve.si...@oracle.com

! make/build.properties
! make/build.xml
! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/javax/lang/model/AnnotatedConstruct.java
! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java
! test/tools/javac/T7042623.java
! 
test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java
+ test/tools/javac/annotations/typeAnnotations/classfile/Scopes.java
! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java
! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.java
! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out
! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.java
! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.java
! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.out
! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion7.out
! test/tools/javac/annotations/typeAnnotations/failures/BadCast.java
! test/tools/javac/annotations/typeAnnotations/failures/BadCast.out
+ 
test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java
+ test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out
+ test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java
+ test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out
! 
test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java
- 
test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out
+ 
test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out
+ 
test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.out
! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.java
! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.out
- test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.java
- test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.out
! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.java
! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.out
! test/tools/javac/annotations/typeAnnotations/failures/LintCast.out
! test/tools/javac/annotations/typeAnnotations/failures/OldArray.java
+ test/tools/javac/annotations/typeAnnotations/failures/OldArray.out
! test/tools/javac/annotations/typeAnnotations/failures/Scopes.java
! test/tools/javac/annotations/typeAnnotations/failures/Scopes.out
! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.java
! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.out
- test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java
- test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out
! 
test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.out
- test/tools/javac/diags/examples/CantAnnotateNestedType.java
+ test/tools/javac/diags/examples/CantAnnotateScoping.java
+ test/tools/javac/diags/examples/CantAnnotateScoping1.java
- test/tools/javac/diags/examples/CantAnnotateStaticClass.java
! test/tools/javac/lib/DPrinter.java
! test/tools/javac/processing/model/type/BasicAnnoTests.java

hg: jdk8/tl/langtools: 8026368: doclint does not report empty tags when tag closed implicitly

[jonathan . gibbons]

Changeset: b024fe427d24
Author:jjg
Date:  2013-10-14 12:38 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b024fe427d24

8026368: doclint does not report empty tags when tag closed implicitly
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
! test/tools/doclint/HtmlAttrsTest.java
! test/tools/doclint/HtmlAttrsTest.out
! test/tools/doclint/tidy/BadEnd.out
! test/tools/doclint/tidy/TrimmingEmptyTag.java
! test/tools/doclint/tidy/TrimmingEmptyTag.out

hg: jdk8/tl/langtools: 8026371: tidy issues in langtools/src/**/*.html files

[jonathan . gibbons]

Changeset: b9e3b55a908c
Author:jjg
Date:  2013-10-14 16:28 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b9e3b55a908c

8026371: tidy issues in langtools/src/**/*.html files
Reviewed-by: darcy

+ src/share/classes/com/sun/javadoc/package-info.java
- src/share/classes/com/sun/javadoc/package.html
+ src/share/classes/com/sun/tools/classfile/package-info.java
- src/share/classes/com/sun/tools/classfile/package.html
+ src/share/classes/com/sun/tools/doclets/formats/html/markup/package-info.java
- src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html
+ src/share/classes/com/sun/tools/doclets/formats/html/package-info.java
- src/share/classes/com/sun/tools/doclets/formats/html/package.html
+ 
src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package-info.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/package-info.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html
+ 
src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package-info.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html
+ 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package-info.java
- 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html
+ 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package-info.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html
+ src/share/classes/com/sun/tools/doclets/package-info.java
- src/share/classes/com/sun/tools/doclets/package.html
+ src/share/classes/com/sun/tools/javap/package-info.java
- src/share/classes/com/sun/tools/javap/package.html
! src/share/classes/javax/lang/model/overview.html
! src/share/classes/javax/tools/overview.html

hg: jdk8/tl/langtools: 8025693: recent javadoc changes cause com/sun/javadoc/testLinkOption/TestLinkOption.java to fail

[jonathan . gibbons]

Changeset: 7d266a2b31b2
Author:jjg
Date:  2013-10-14 22:34 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d266a2b31b2

8025693: recent javadoc changes cause 
com/sun/javadoc/testLinkOption/TestLinkOption.java to fail
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
+ test/tools/javadoc/8025693/Test.java

hg: jdk8/tl/langtools: 8026294: 8025633 breaks langtools/test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java

[jonathan . gibbons]

Changeset: f068d235c4f7
Author:jjg
Date:  2013-10-10 17:13 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f068d235c4f7

8026294: 8025633 breaks 
langtools/test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java
Reviewed-by: darcy

! test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java

hg: jdk8/tl/langtools: 8022163: javac exits with 0 status and no messages on error to construct an ann-procesor

[jonathan . gibbons]

Changeset: 2fa6ced325cc
Author:jjg
Date:  2013-10-04 13:59 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2fa6ced325cc

8022163: javac exits with 0 status and no messages on error to construct an 
ann-procesor
Reviewed-by: darcy

! 
src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/tools/javac/processing/errors/TestBadProcessor.java

hg: jdk8/tl/langtools: 6525408: DiagnosticListener should receive MANDATORY_WARNING in standard compiler mode

[jonathan . gibbons]

Changeset: 515d54c1b063
Author:jjg
Date:  2013-10-04 14:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/515d54c1b063

6525408: DiagnosticListener should receive MANDATORY_WARNING in standard 
compiler mode
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/javax/tools/Diagnostic.java

hg: jdk8/tl/langtools: 8025970: Spurious characters in JavaCompiler

[jonathan . gibbons]

Changeset: 3e3c321710be
Author:jjg
Date:  2013-10-04 15:24 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3e3c321710be

8025970: Spurious characters in JavaCompiler
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java

hg: jdk8/tl/langtools: 8025407: TypeAnnotations does not use Context

[jonathan . gibbons]

Changeset: 5043e7056be8
Author:jjg
Date:  2013-09-25 11:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5043e7056be8

8025407: TypeAnnotations does not use Context
Reviewed-by: jfranck

! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java

hg: jdk8/tl/langtools: 8025412: Add legal header and comments to test/tools/doclint/tidy/util/Main.java

[jonathan . gibbons]

Changeset: 3d61984b077c
Author:jjg
Date:  2013-09-25 14:04 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d61984b077c

8025412: Add legal header and comments to test/tools/doclint/tidy/util/Main.java
Reviewed-by: bpatel

! test/tools/doclint/tidy/util/Main.java
! test/tools/doclint/tidy/util/tidy.sh

hg: jdk8/tl/langtools: 8025050: Doclint doesn't recognize dfn tag

[jonathan . gibbons]

Changeset: 96dcb66e6b0a
Author:jjg
Date:  2013-09-24 10:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/96dcb66e6b0a

8025050: Doclint doesn't recognize dfn tag
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclint/HtmlTag.java
! test/tools/doclint/html/InlineTagsTest.java

hg: jdk8/tl/langtools: 8025246: [doclint] doclint is showing error on anchor already defined when it's not

[jonathan . gibbons]

Changeset: 503338f16d2b
Author:jjg
Date:  2013-09-24 10:51 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/503338f16d2b

8025246: [doclint] doclint is showing error on anchor already defined when it's 
not
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/anchorTests/p/Test.java
+ test/tools/doclint/anchorTests/p/Test.javac.out
+ test/tools/doclint/anchorTests/p/Test.out
+ test/tools/doclint/anchorTests/p/package-info.java
+ test/tools/doclint/anchorTests/p/package-info.javac.out
+ test/tools/doclint/anchorTests/p/package-info.out

hg: jdk8/tl/langtools: 8025272: doclint needs to check for valid usage of @value tag

[jonathan . gibbons]

Changeset: 6a05a713450d
Author:jjg
Date:  2013-09-24 11:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6a05a713450d

8025272: doclint needs to check for valid usage of @value tag
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
+ test/tools/doclint/ValueTest.java
+ test/tools/doclint/ValueTest.out

hg: jdk8/tl/langtools: 8002154: [doclint] doclint should check for issues which are errors in javadoc

[jonathan . gibbons]

Changeset: 3ae62331a56f
Author:jjg
Date:  2013-09-24 13:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ae62331a56f

8002154: [doclint] doclint should check for issues which are errors in javadoc
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
! test/tools/doclint/ReferenceTest.java
! test/tools/doclint/ReferenceTest.out

hg: jdk8/tl/langtools: 8024609: sjavac assertion fails during call to BuildState.collectArtifacts

[jonathan . gibbons]

Changeset: 0cfd5baa7154
Author:ohrstrom
Date:  2013-09-19 08:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0cfd5baa7154

8024609: sjavac assertion fails during call to BuildState.collectArtifacts
Reviewed-by: jjg

! src/share/classes/com/sun/tools/sjavac/BuildState.java
! src/share/classes/com/sun/tools/sjavac/Main.java
! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java

hg: jdk8/tl/langtools: 8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL

[jonathan . gibbons]

Changeset: fdfbc5f0c4ed
Author:jjg
Date:  2013-09-17 14:17 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fdfbc5f0c4ed

8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
+ test/tools/javac/doclint/implicitSource/ImplicitSourceTest.java
+ test/tools/javac/doclint/implicitSource/Other.java

hg: jdk8/tl/langtools: 8019521: Enhanced rethrow disabled in lambdas

[jonathan . gibbons]

Changeset: 77d395862700
Author:jlahoda
Date:  2013-09-09 23:13 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/77d395862700

8019521: Enhanced rethrow disabled in lambdas
Summary: Fixing effectively final detection inside lambdas, small cleanup 
related to thrown types detection in lambdas
Reviewed-by: mcimadamore, jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/lambda/EffectivelyFinalThrows.java

hg: jdk8/tl/langtools: 8006972: jtreg test fails: test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java

[jonathan . gibbons]

Changeset: 7439356a7dc5
Author:jjg
Date:  2013-09-09 17:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7439356a7dc5

8006972: jtreg test fails: 
test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
Reviewed-by: darcy

! 
test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
! 
test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref

hg: jdk8/tl/langtools: 8024434: problem running javadoc tests in samevm mode on Windows

[jonathan . gibbons]

Changeset: 64328fe5e4a6
Author:jjg
Date:  2013-09-06 15:31 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64328fe5e4a6

8024434: problem running javadoc tests in samevm mode on Windows
Reviewed-by: darcy

! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java
! test/tools/javadoc/api/basic/APITest.java
! test/tools/javadoc/api/basic/GetTask_FileManagerTest.java

hg: jdk8/tl/langtools: 8001669: javadoc internal DocletAbortException should set cause when appropriate

[jonathan . gibbons]

Changeset: 0e6577980181
Author:jjg
Date:  2013-08-29 11:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0e6577980181

8001669: javadoc internal DocletAbortException should set cause when appropriate
Reviewed-by: darcy

! 
src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! 
src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! 
src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! 
src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
! 
src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
! 
src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java

hg: jdk8/tl/langtools: 8023833: Replace direct use of AnnotatedType in javadoc code

[jonathan . gibbons]

Changeset: 23f0f3c9c44a
Author:jjg
Date:  2013-08-29 19:19 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/23f0f3c9c44a

8023833: Replace direct use of AnnotatedType in javadoc code
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java

hg: jdk8/tl/langtools: 8010310: [javadoc] Error processing sources with -private

[jonathan . gibbons]

Changeset: 189942cdf585
Author:jjg
Date:  2013-08-28 15:40 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/189942cdf585

8010310: [javadoc] Error processing sources with -private
Reviewed-by: vromero, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
+ test/tools/javadoc/nonConstExprs/Test.java

hg: jdk8/tl/langtools: 8023701: Fix badly named test

[jonathan . gibbons]

Changeset: 60f156c653d3
Author:jjg
Date:  2013-08-26 11:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/60f156c653d3

8023701: Fix badly named test
Reviewed-by: bpatel

- test/com/sun/javadoc/testNavagation/TestNavagation.java
- test/com/sun/javadoc/testNavagation/pkg/A.java
- test/com/sun/javadoc/testNavagation/pkg/C.java
- test/com/sun/javadoc/testNavagation/pkg/E.java
- test/com/sun/javadoc/testNavagation/pkg/I.java
+ test/com/sun/javadoc/testNavigation/TestNavigation.java
+ test/com/sun/javadoc/testNavigation/pkg/A.java
+ test/com/sun/javadoc/testNavigation/pkg/C.java
+ test/com/sun/javadoc/testNavigation/pkg/E.java
+ test/com/sun/javadoc/testNavigation/pkg/I.java

hg: jdk8/tl/langtools: 8023768: Use the unannotatedType in cyclicity checks.

[jonathan . gibbons]

Changeset: 7bf6313e1ced
Author:jjg
Date:  2013-08-26 15:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7bf6313e1ced

8023768: Use the unannotatedType in cyclicity checks.
Reviewed-by: jjg
Contributed-by: wdi...@gmail.com

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java

hg: jdk8/tl/langtools: 8022173: Relax some warnings in doclint

[jonathan . gibbons]

Changeset: b77381d99056
Author:jjg
Date:  2013-08-22 12:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b77381d99056

8022173: Relax some warnings in doclint
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/HtmlTag.java
! test/tools/doclint/html/ListTagsTest.java
! test/tools/doclint/html/OtherTagsTest.java
! test/tools/doclint/html/OtherTagsTest.out
! test/tools/doclint/html/TableTagsTest.java

hg: jdk8/tl/langtools: 8023515: import type-annotations updates

[jonathan . gibbons]

Changeset: 7de231613e4a
Author:jjg
Date:  2013-08-21 16:13 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7de231613e4a

8023515: import type-annotations updates
Reviewed-by: jjg
Contributed-by: wdi...@gmail.com

! src/share/classes/com/sun/source/tree/MethodTree.java
! src/share/classes/com/sun/source/tree/TypeParameterTree.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! 
src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! 
test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java
+ test/tools/javac/annotations/typeAnnotations/failures/DummyProcessor.java
+ test/tools/javac/annotations/typeAnnotations/failures/T8020715.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java
+ test/tools/javac/tree/TypeAnnotationsPretty.java

hg: jdk8/tl/langtools: 8022287: javac.sym.Profiles uses a static Map when it should not

[jonathan . gibbons]

Changeset: 57e1266527dd
Author:jjg
Date:  2013-08-21 17:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/57e1266527dd

8022287: javac.sym.Profiles uses a static Map when it should not
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javac/sym/Profiles.java
+ test/tools/javac/profiles/ProfileTest.java

hg: jdk8/tl/langtools: 8020663: Restructure some properties to facilitate better translation

[jonathan . gibbons]

Changeset: a76dc1b4c299
Author:jjg
Date:  2013-08-20 14:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a76dc1b4c299

8020663: Restructure some properties to facilitate better translation
Reviewed-by: darcy

! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java

hg: jdk8/tl/langtools: 8022080: javadoc generates invalid HTML in Turkish locale

[jonathan . gibbons]

Changeset: 79e341614c50
Author:jjg
Date:  2013-08-20 14:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79e341614c50

8022080: javadoc generates invalid HTML in Turkish locale
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java
! src/share/classes/com/sun/tools/doclint/HtmlTag.java

hg: jdk8/tl/langtools: 8013887: In class use, some tables are randomly unsorted

[jonathan . gibbons]

Changeset: 720992953d43
Author:jjg
Date:  2013-08-20 15:12 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/720992953d43

8013887: In class use, some tables are randomly unsorted
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java

hg: jdk8/tl/langtools: 8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages

[jonathan . gibbons]

Changeset: 14faef2b51eb
Author:jjg
Date:  2013-08-14 16:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/14faef2b51eb

8017191: Javadoc is confused by @link to imported classes outside of the set of 
generated packages
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
+ test/com/sun/javadoc/testSeeTag/TestSeeTag.java
+ test/com/sun/javadoc/testSeeTag/pkg/Test.java

hg: jdk8/tl/langtools: 8020556: doclint does not check type variables for @throws

[jonathan . gibbons]

Changeset: 2fbe77c38802
Author:jjg
Date:  2013-07-24 17:35 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2fbe77c38802

8020556: doclint does not check type variables for @throws
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/DocTrees.java
! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/comp/Env.java
! test/tools/doclint/ReferenceTest.java

hg: jdk8/tl/langtools: 8021215: javac gives incorrect doclint warnings on normal package statements

[jonathan . gibbons]

Changeset: 129751018061
Author:jjg
Date:  2013-07-23 16:06 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/129751018061

8021215: javac gives incorrect doclint warnings on normal package statements
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/DocLint.java
! test/tools/doclint/packageTests/bad/Test.java
+ test/tools/doclint/packageTests/bad/Test.javac.out
! test/tools/doclint/packageTests/bad/Test.out
! test/tools/doclint/packageTests/bad/package-info.java
+ test/tools/doclint/packageTests/bad/package-info.javac.out
! test/tools/doclint/packageTests/bad/package-info.out
! test/tools/doclint/packageTests/good/Test.java
! test/tools/doclint/packageTests/good/package-info.java

hg: jdk8/tl/langtools: 8020664: doclint gives incorrect warnings on normal package statements

[jonathan . gibbons]

Changeset: 1476d54fdc61
Author:jjg
Date:  2013-07-17 19:16 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1476d54fdc61

8020664: doclint gives incorrect warnings on normal package statements
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
! test/tools/doclint/BadPackageCommentTest.out
! test/tools/doclint/DocLintTester.java
+ test/tools/doclint/packageTests/bad/Test.java
+ test/tools/doclint/packageTests/bad/Test.out
+ test/tools/doclint/packageTests/bad/package-info.java
+ test/tools/doclint/packageTests/bad/package-info.out
+ test/tools/doclint/packageTests/good/Test.java
+ test/tools/doclint/packageTests/good/package-info.java

hg: jdk8/tl/langtools: 8020313: doclint doesn't reset HTML anchors correctly

[jonathan . gibbons]

Changeset: 1e533c1bfb01
Author:jjg
Date:  2013-07-17 19:12 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1e533c1bfb01

8020313: doclint doesn't reset HTML anchors correctly
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/AnchorTest2.java
+ test/tools/doclint/AnchorTest2.out
+ test/tools/doclint/AnchorTest2a.java

hg: jdk8/tl/langtools: 8020278: NPE in javadoc

[jonathan . gibbons]

Changeset: 37031963493e
Author:jjg
Date:  2013-07-12 13:11 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37031963493e

8020278: NPE in javadoc
Reviewed-by: mcimadamore, vromero

! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/Env.java
+ test/tools/doclint/BadPackageCommentTest.java
+ test/tools/doclint/BadPackageCommentTest.out

hg: jdk8/tl/langtools: 8015720: since tag isn't copied while generating JavaFX documentation

[jonathan . gibbons]

Changeset: 26437287529d
Author:janvalenta
Date:  2013-06-27 17:47 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/26437287529d

8015720: since tag isn't copied while generating JavaFX documentation
Reviewed-by: jjg

! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! 
src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! test/com/sun/javadoc/testJavaFX/C.java
! test/com/sun/javadoc/testJavaFX/TestJavaFX.java

hg: jdk8/tl/langtools: 8014137: Update test/tools/javac/literals/UnderscoreLiterals to add testcases with min/max values

[jonathan . gibbons]

Changeset: 3b2e10524627
Author:jjg
Date:  2013-06-26 18:03 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3b2e10524627

8014137: Update test/tools/javac/literals/UnderscoreLiterals to add testcases 
with min/max values
Reviewed-by: jjg, darcy
Contributed-by: matherey.nu...@oracle.com

! test/tools/javac/literals/UnderscoreLiterals.java

hg: jdk8/tl/langtools: 8016193: Fix OAC issue in langtools docs

[jonathan . gibbons]

Changeset: fd31bf97340f
Author:jjg
Date:  2013-06-07 15:35 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fd31bf97340f

8016193: Fix OAC issue in langtools docs
Reviewed-by: darcy

! src/share/classes/com/sun/javadoc/Tag.java

hg: jdk8/tl/langtools: 8004643: Reduce javac space overhead introduced with compiler support for repeating annotations

[jonathan . gibbons]

Changeset: 8fb68f73d4b1
Author:jjg
Date:  2013-06-04 14:17 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8fb68f73d4b1

8004643: Reduce javac space overhead introduced with compiler support for 
repeating annotations
Reviewed-by: mcimadamore, jfranck

! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java
! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! test/tools/javac/lib/DPrinter.java

hg: jdk8/tl/langtools: 8006615: [doclint] move remaining messages into resource bundle

[jonathan . gibbons]

Changeset: 242bcad5be74
Author:jjg
Date:  2013-06-03 17:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/242bcad5be74

8006615: [doclint] move remaining messages into resource bundle
Reviewed-by: mcimadamore, vromero

! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/resources/doclint.properties
+ test/tools/doclint/ResourceTest.java
! test/tools/doclint/tool/RunTest.java

hg: jdk8/tl/langtools: 8007687: javadoc -X does not include -Xdoclint

[jonathan . gibbons]

Changeset: 019063968164
Author:jjg
Date:  2013-06-03 17:24 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/019063968164

8007687: javadoc -X does not include -Xdoclint
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! 
src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
! src/share/classes/com/sun/tools/javac/resources/javac.properties
! src/share/classes/com/sun/tools/javadoc/Start.java
! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties
! test/com/sun/javadoc/testHelpOption/TestHelpOption.java
+ test/com/sun/javadoc/testXOption/TestXOption.java

hg: jdk8/tl/langtools: 8006879: Detection of windows in sjavac fails.

[jonathan . gibbons]

Changeset: 445b8b5ae9f4
Author:jjg
Date:  2013-05-15 10:39 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/445b8b5ae9f4

8006879: Detection of windows in sjavac fails.
Reviewed-by: jjg
Contributed-by: erik.joels...@oracle.com

! src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java

hg: jdk8/tl/langtools: 8014461: genstubs creates default native methods

[jonathan . gibbons]

Changeset: 46b9c25f7024
Author:jjg
Date:  2013-05-14 12:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/46b9c25f7024

8014461: genstubs creates default native methods
Reviewed-by: alanb

! make/tools/genstubs/GenStubs.java

hg: jdk8/tl/langtools: 8014557: Mutable static field in HtmlDocletWriter

[jonathan . gibbons]

Changeset: 0384683c64be
Author:jjg
Date:  2013-05-14 13:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0384683c64be

8014557: Mutable static field in HtmlDocletWriter
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java

hg: jdk8/tl/langtools: 8013852: update reference impl for type-annotations

[jonathan . gibbons]

Changeset: ddb4a2bfcd82
Author:jjg
Date:  2013-05-14 15:04 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ddb4a2bfcd82

8013852: update reference impl for type-annotations
Reviewed-by: jjg
Contributed-by: wdi...@gmail.com, steve.si...@oracle.com, 
joel.fra...@oracle.com, alex.buck...@oracle.com

! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/classfile/TypeAnnotation.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/javac/code/Annotations.java
! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java
! src/share/classes/com/sun/tools/javadoc/Messager.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java
! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java
! test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java
! test/tools/javac/annotations/typeAnnotations/attribution/Scopes.java
! 
test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java
! 
test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java
! 
test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java
+ 
test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest3.java
! test/tools/javac/annotations/typeAnnotations/classfile/DeadCode.java
! test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java
+ test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java
+ test/tools/javac/annotations/typeAnnotations/classfile/T8008769.java
+ test/tools/javac/annotations/typeAnnotations/classfile/T8010015.java
+ test/tools/javac/annotations/typeAnnotations/classfile/TestNewCastArray.java
! test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java
! test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java
! test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.java
+ test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.out
! test/tools/javac/annotations/typeAnnotations/failures/LintCast.out
! test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java
! test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out
+ test/tools/javac/annotations/typeAnnotations/failures/T8008751.java
+ test/tools/javac/annotations/typeAnnotations/failures/T8009360.java
+ test/tools/javac/annotations/typeAnnotations/failures/T8011722.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out
+ 
test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DeclarationAnnotation.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DeclarationAnnotation.out
! 
test/tools/javac/annotations/typeAnnotations/failures/common/receiver/Nesting.java
! 

hg: jdk8/tl/langtools: 8013163: Convert 4 tools multicatch tests to jtreg format

[jonathan . gibbons]

Changeset: 53b389eb39c1
Author:sogoel
Date:  2013-05-14 18:02 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/53b389eb39c1

8013163: Convert 4 tools multicatch tests to jtreg format
Reviewed-by: jjg

+ test/tools/javac/multicatch/Pos11.java
+ test/tools/javac/multicatch/Pos12.java

hg: jdk8/tl/langtools: 8014323: Add VariableTree.getNameExpression

[jonathan . gibbons]

Changeset: 529fb3ed5d2a
Author:jjg
Date:  2013-05-14 21:08 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/529fb3ed5d2a

8014323: Add VariableTree.getNameExpression
Reviewed-by: darcy

! src/share/classes/com/sun/source/tree/VariableTree.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! test/tools/javac/tree/SourceTreeScannerTest.java

hg: jdk8/tl/langtools: 8012929: Trees.getElement should work not only for declaration trees, but also for use-trees

[jonathan . gibbons]

Changeset: 8dd528992c15
Author:jlahoda
Date:  2013-05-10 15:15 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8dd528992c15

8012929: Trees.getElement should work not only for declaration trees, but also 
for use-trees
Reviewed-by: jjg
Contributed-by: Dusan Balek dba...@netbeans.org, Jan Lahoda 
jlah...@netbeans.org

! src/share/classes/com/sun/tools/doclint/Env.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/api/TestGetElementReference.java
+ test/tools/javac/api/TestGetElementReferenceData.java

hg: jdk8/tl/langtools: 8014363: javac test class ToolTester handles classpath incorrectly

[jonathan . gibbons]

Changeset: e39669aea0bd
Author:jjg
Date:  2013-05-12 18:18 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e39669aea0bd

8014363: javac test class ToolTester handles classpath incorrectly
Reviewed-by: ksrini

! test/tools/javac/api/6406133/T6406133.java
! test/tools/javac/api/6410643/T6410643.java
! test/tools/javac/api/6411310/T6411310.java
! test/tools/javac/api/6411333/T6411333.java
! test/tools/javac/api/6412656/T6412656.java
! test/tools/javac/api/6415780/T6415780.java
! test/tools/javac/api/6418694/T6418694.java
! test/tools/javac/api/642/T642.java
! test/tools/javac/api/6421756/T6421756.java
! test/tools/javac/api/6422215/T6422215.java
! test/tools/javac/api/6422327/T6422327.java
! test/tools/javac/api/6423003/T6423003.java
! test/tools/javac/api/6431257/T6431257.java
! test/tools/javac/api/6437349/T6437349.java
! test/tools/javac/api/6437999/T6437999.java
! test/tools/javac/api/6440333/T6440333.java
! test/tools/javac/api/6440528/T6440528.java
! test/tools/javac/api/6468404/T6468404.java
! test/tools/javac/api/6731573/T6731573.java
! test/tools/javac/api/6733837/T6733837.java
! test/tools/javac/api/TestJavacTaskScanner.java
! test/tools/javac/api/guide/Test.java
! test/tools/javac/api/lib/ToolTester.java

hg: jdk8/tl/langtools: 8004082: test/tools/javac/plugin/showtype/Test.java fails on windows: jtreg can't delete plugin.jar

[jonathan . gibbons]

Changeset: 43c2f7cb9c76
Author:jjg
Date:  2013-05-07 14:27 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/43c2f7cb9c76

8004082: test/tools/javac/plugin/showtype/Test.java fails on windows: jtreg 
can't delete plugin.jar
Reviewed-by: vromero, mcimadamore

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! 
src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ src/share/classes/com/sun/tools/javac/util/ServiceLoader.java
! test/tools/javac/plugin/showtype/Test.java

hg: jdk8/tl/langtools: 8009724: Enhance the DocTree API with DocTreePath

[jonathan . gibbons]

Changeset: a7ff36d06fa2
Author:jlahoda
Date:  2013-05-06 16:22 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a7ff36d06fa2

8009724: Enhance the DocTree API with DocTreePath
Summary: Adding DocTreePath and DocTreePathScanner similar to TreePath and 
TreePathScanner, respectively
Reviewed-by: jjg
Contributed-by: Ralph Benjamin Ruijs ralphbenja...@netbeans.org, Jan Lahoda 
jlah...@netbeans.org

+ src/share/classes/com/sun/source/util/DocTreePath.java
+ src/share/classes/com/sun/source/util/DocTreePathScanner.java
! src/share/classes/com/sun/source/util/DocTrees.java
! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
+ test/tools/javac/doctree/DocTreePathScannerTest.java
! test/tools/javac/doctree/ReferenceTest.java