> On May 10, 2017, at 11:35 AM, Kumar Srinivasan
> wrote:
>
> Hi All,
>
> Please review fixes to make the API doc comments HTML5 clean,
> there are no changes to the verbiage, and mostly fixes for the table
> styles defined here:
> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ee84b7d4433
Thanks
-- Jon
On 05/11/2017 05:37 PM, Lance Andersen wrote:
Looks fine Jon
Best
Lance
On May 11, 2017, at 7:38 PM, Jonathan Gibbons
mailto:jonathan.gibb...@oracle.com>> wrote:
More HTML 5 fixes to review in a few files in the java.sql and
java.sql.rowset modules:
JBS: https://bugs.openjd
Looks fine Jon
Best
Lance
> On May 11, 2017, at 7:38 PM, Jonathan Gibbons
> wrote:
>
> More HTML 5 fixes to review in a few files in the java.sql and
> java.sql.rowset modules:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180256
> Webrev: http://cr.openjdk.java.net/~jjg/8180256/webrev.0
Hello,
Ping!. Lets wrap this up soon, as we have to move to
the next steps in the docs related work.
Thanks
Kumar
Hi All,
Please review fixes to make the API doc comments HTML5 clean,
there are no changes to the verbiage, and mostly fixes for the table
styles defined here:
http://hg.openjdk
http://cr.openjdk.java.net/~iignatyev//8180195/webrev.00/index.html
> 3049 lines changed: 114 ins; 2927 del; 8 mod;
Hi all,
could you please review this small patch which removes a fork of testlibrary
from jaxp repo? there were a few differences b/w the testlibraries: top level
testlibrary did
More HTML 5 fixes to review in a few files in the java.sql and
java.sql.rowset modules:
JBS: https://bugs.openjdk.java.net/browse/JDK-8180256
Webrev: http://cr.openjdk.java.net/~jjg/8180256/webrev.00/
API: http://cr.openjdk.java.net/~jjg/8180256/api.00/overview-summary.html
-- Jon
Hi Daniel,
As Jon surmised, this is an ARIA/accessibility requirement, in that one
can't
have holes in the usage of h* tags, as javadoc tool itself uses h1 and h2,
the API docs have to start with h3.
With respect to your comment, the h2->h3 is erroneous and have reverted
them back, so the on
On 12/05/2017 7:55 AM, Mandy Chung wrote:
+1 (dropping the null check as Claes suggests).
Ok - dropping null check. :)
Thanks,
David
Mandy
On May 11, 2017, at 2:01 PM, Claes Redestad wrote:
The null check is redundant, so the code could be simplified a bit.
Reviewed regardless!
/Claes
Hi,
I have one more update, with a couple of suggested changes to simplify
the execute() calls:
* execute() takes a vararg, so explicit String[] creation can be omitted
(mostly).
* args common to every execute() call are consolidated into a List.
(The resulting arg reordering should not af
+1 (dropping the null check as Claes suggests).
Mandy
> On May 11, 2017, at 2:01 PM, Claes Redestad wrote:
>
> The null check is redundant, so the code could be simplified a bit.
>
> Reviewed regardless!
>
> /Claes
>
> On 2017-05-11 22:46, David Holmes wrote:
>> Bug: https://bugs.openjdk.jav
Thanks Paul!
David
On 12/05/2017 7:14 AM, Paul Sandoz wrote:
+1
Paul.
On 11 May 2017, at 13:46, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
This is a fix contributed by Doug Lea, from a suggestion ma
Alan, could you please commit this patch for me? We've tested it locally
and all of the jdk_other tests pass with this change on jdk9.
93d92
< * Once installed, the builder cannot be replaced.
101d99
< * @exception IllegalStateException If a factory has already been
installed.
109,111d1
+1
Paul.
> On 11 May 2017, at 13:46, David Holmes wrote:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
>
> This is a fix contributed by Doug Lea, from a suggestion made by Alan
> Bateman. While I'm handling the fix proc
On 12/05/2017 7:01 AM, Claes Redestad wrote:
The null check is redundant, so the code could be simplified a bit.
Reviewed regardless!
Thanks Claes!
David
/Claes
On 2017-05-11 22:46, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
webrev: http://cr.openjdk.java.ne
The null check is redundant, so the code could be simplified a bit.
Reviewed regardless!
/Claes
On 2017-05-11 22:46, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
This is a fix contributed by Doug Lea, fro
Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
This is a fix contributed by Doug Lea, from a suggestion made by Alan
Bateman. While I'm handling the fix process for Doug, it isn't my fix so
I am also a Reviewer of this fix. I ex
Daniel,
As a general comment, it is an accessibility error to have "gaps" in the
header numbering, such as an following an without an
intervening .
If you can point to specific files where you think the numbering has
been semantically changed, that would be good to know.
-- Jon
On 05/1
Hi,
Thanks for the review and suggestions.
{@link ...} will work those links; some hrefs will remain in cases
where the link is to an "id" of some
element that is not a method or field name.
Webrev updated in place:
http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/
Thanks,
Hi Kumar,
Looks mostly good.
I'm not too sure about the changes from to and to
though.
Now some of the package.html files in java.naming retain their
Package Specification section, and others have it
changed to Package Specification.
best regards,
-- daniel
On 10/05/2017 19:57, Kumar Srin
Hm,
Such advise might not be fruitful for average user. Why?
1. ClassValue instances are typically assigned to static final fields of
application classes. Which means that they will be strongly reachable as
long as the ClassLoader of such static field's declaring class is
strongly reachable.
>
>
>>
> Unfortunately, they are not safely mutable in multi-threaded programs on
> many operating system/libc combinations.
>
> But the problem is less about mutating, that it is about reading: the VM
returns wrong values at some point, because it _assumes_ that the
environment variables are not m
2017-05-11 12:50 GMT+02:00 David Holmes :
> Hi Cedric,
>
> On 11/05/2017 5:02 PM, Cédric Champeau wrote:
>
>> Thanks for the answers, folks, but I think they are kind of missing the
>> point. The fact is that environment variables *are* mutable. Java
>>
>
> Yes they are, provided you do it careful
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 jus
On 11.05.2017 09:02, Cédric Champeau wrote:
Thanks for the answers, folks, but I think they are kind of missing the
point. The fact is that environment variables *are* mutable.
Unfortunately, they are not safely mutable in multi-threaded programs on
many operating system/libc combinations.
Hi,
Please find below a patch for:
8180176: Broken javadoc links in java.logging and java.naming
https://bugs.openjdk.java.net/browse/JDK-8180176
The fix is to use {@docRoot} as has been done elsewhere...
http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html
best regards,
--
Hi Cedric,
On 11/05/2017 5:02 PM, Cédric Champeau wrote:
Thanks for the answers, folks, but I think they are kind of missing the
point. The fact is that environment variables *are* mutable. Java
Yes they are, provided you do it carefully and don't have to deal with
the fact that its basically
On 11/05/2017 08:02, Cédric Champeau wrote:
Thanks for the answers, folks, but I think they are kind of missing the
point. The fact is that environment variables *are* mutable. Java happens
to return an immutable view of the environment variables when the VM was
started, which is not the reality
Hi Roger,
I'm surprised to see we have style links in .java
files to link to package summary and java APIs for classes and
methods, when {@link } should work...
For instance in this file:
http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/src/jdk.management/share/classes/com/sun/man
On May 10, 2017, at 11:22 AM, Roger Riggs wrote:
> Please review corrections to broken javadoc links:
> - links to the serialization spec now in ./specs/serialization
> - links in java.lang to java/util/Spliterator
> - link in ModuleLayer to Classloader
> - Links using ../../../.. do not work we
Thanks for the answers, folks, but I think they are kind of missing the
point. The fact is that environment variables *are* mutable. Java happens
to return an immutable view of the environment variables when the VM was
started, which is not the reality. We cannot trust what `System.geteenv`
returns
30 matches
Mail list logo
