I received test from the NetBeans team. The NetBeans did reference the
internal JAXPSAXParser directly. This is not a usage supported by the
spec. I would suggest them remove it and use the default parser instead.
I'm asking the NetBeans team what are the features they rely on that the
default
Hello,
Please review this change below to fix another small batch of doclint
problem in java.util.jar.
Thanks,
-Joe
diff -r fd1b5adcfdf0 src/share/classes/java/util/jar/Attributes.java
--- a/src/share/classes/java/util/jar/Attributes.javaWed Jul 24
22:52:01 2013 +0100
+++
Hello,
Please review this minor doclint fix in java.util.stream.
Thanks,
-Joe
--- a/src/share/classes/java/util/stream/StreamSupport.javaWed Jul
24 22:52:01 2013 +0100
+++ b/src/share/classes/java/util/stream/StreamSupport.javaWed Jul
24 23:57:19 2013 -0700
@@ -1,5 +1,5 @@
/*
- *
On 07/25/2013 12:09 AM, David Holmes wrote:
On 25/07/2013 4:47 PM, Joe Darcy wrote:
Hello,
Please review this change below to fix another small batch of doclint
problem in java.util.jar.
Thanks,
-Joe
diff -r fd1b5adcfdf0 src/share/classes/java/util/jar/Attributes.java
---
Hello,
Please review the fix below to add @throws tags to constructors in
java.io.Object{Input, Output}Stream.
Thanks,
-Joe
diff -r fd1b5adcfdf0 src/share/classes/java/io/ObjectInputStream.java
--- a/src/share/classes/java/io/ObjectInputStream.javaWed Jul 24
22:52:01 2013 +0100
+++
Thanks - looks good to me (if you can trust that I was actually able to
read it ;-) )
David
On 25/07/2013 5:11 PM, Joe Darcy wrote:
On 07/25/2013 12:09 AM, David Holmes wrote:
On 25/07/2013 4:47 PM, Joe Darcy wrote:
Hello,
Please review this change below to fix another small batch of
Looks good. :)
David
On 25/07/2013 4:58 PM, Joe Darcy wrote:
Hello,
Please review this minor doclint fix in java.util.stream.
Thanks,
-Joe
--- a/src/share/classes/java/util/stream/StreamSupport.javaWed Jul
24 22:52:01 2013 +0100
+++
minor one, the year in header needs also update ;-)
On 25.07.13 09:11, Joe Darcy wrote:
On 07/25/2013 12:09 AM, David Holmes wrote:
On 25/07/2013 4:47 PM, Joe Darcy wrote:
Hello,
Please review this change below to fix another small batch of doclint
problem in java.util.jar.
Thanks,
-Joe
Looks good.
David
On 25/07/2013 5:13 PM, Joe Darcy wrote:
Hello,
Please review the fix below to add @throws tags to constructors in
java.io.Object{Input, Output}Stream.
Thanks,
-Joe
diff -r fd1b5adcfdf0 src/share/classes/java/io/ObjectInputStream.java
---
Hi Joe,
Looks good.
Small nit: you could keep fSecurityPropertyManager final by using:
if (spm != null) {
fSecurityPropertyManager = spm;
} else {
fSecurityPropertyManager = new ...
...
}
Don't feel obliged to do it though - your fix is good as it is.
best regards,
-- daniel
On
Thanks for the quick review and the tip. I've started a build and am
still trying to fix some test issues on the other patch. So for now I'll
keep it that way.
-Joe
On 7/25/2013 12:39 AM, Daniel Fuchs wrote:
Hi Joe,
Looks good.
Small nit: you could keep fSecurityPropertyManager final by
Hi Joe,
Looks good.
Paul.
On Jul 25, 2013, at 7:58 AM, Joe Darcy joe.da...@oracle.com wrote:
Hello,
Please review this minor doclint fix in java.util.stream.
Thanks,
-Joe
--- a/src/share/classes/java/util/stream/StreamSupport.javaWed Jul 24
22:52:01 2013 +0100
+++
On 07/25/2013 08:39 AM, Daniel Fuchs wrote:
Hi Joe,
Looks good.
+1
Small nit: you could keep fSecurityPropertyManager final by using:
if (spm != null) {
fSecurityPropertyManager = spm;
} else {
fSecurityPropertyManager = new ...
...
}
Don't feel obliged to do it though -
Looks good to me Joe,
-Chris.
On 07/25/2013 07:47 AM, Joe Darcy wrote:
Hello,
Please review this change below to fix another small batch of doclint
problem in java.util.jar.
Thanks,
-Joe
diff -r fd1b5adcfdf0 src/share/classes/java/util/jar/Attributes.java
---
Looks fine Joe.
-Chris.
On 07/25/2013 07:58 AM, Joe Darcy wrote:
Hello,
Please review this minor doclint fix in java.util.stream.
Thanks,
-Joe
--- a/src/share/classes/java/util/stream/StreamSupport.javaWed Jul
24 22:52:01 2013 +0100
+++
Looks good.
-Chris.
On 07/25/2013 08:13 AM, Joe Darcy wrote:
Hello,
Please review the fix below to add @throws tags to constructors in
java.io.Object{Input, Output}Stream.
Thanks,
-Joe
diff -r fd1b5adcfdf0 src/share/classes/java/io/ObjectInputStream.java
---
These changes are already committed in the jsr166 CVS, this is a request
to pull them into jdk8.
diff -r fd1b5adcfdf0
src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
---
a/src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
Wed Jul
These changes are already committed in the jsr166 CVS, this is a request
to pull them into jdk8.
With these changes all but CompletableFuture are doclint warning free.
There is a separate effort to overhaul CF, which will address the warnings.
diff -r fd1b5adcfdf0
Changeset: a218f7befd55
Author:jfranck
Date: 2013-07-25 11:02 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a218f7befd55
8007961: javax.lang.model tests for repeating annotations fail in
getAnnotationsByType
Reviewed-by: jjg
!
Hi,
Please review the following patch that fixes two issues with TreeMap
spliterators:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8020156-8020009-TreeMap/webrev/
It's unfortunate and damn ugly that i resorted to using raw types and a cast
for the EntrySet Spliterator.getComparator method:
Looks fine
Best
Lance
--
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPhone
On Jul 25, 2013, at 4:41 AM, Chris Hegarty chris.hega...@oracle.com wrote:
These changes
Hi,
For the record I have updated the webrev with Mandy's suggestion:
http://cr.openjdk.java.net/~dfuchs/webrev_8019948/webrev.01/
-- daniel
On 7/23/13 6:07 PM, Mandy Chung wrote:
On 7/23/2013 9:08 PM, Daniel Fuchs wrote:
Hi,
Please find below a changeset for fixing
8019948:
This is a request for review for some doclint warnings in the java.net
package. Trivially, the list type should be left to the CSS.
Note: with these changes there are still warnings for two DatagramPacket
constructors that are missing @throws for SocketException. I do not see
any reason that
Good to go
On Jul 25, 2013, at 6:00 AM, Chris Hegarty wrote:
This is a request for review for some doclint warnings in the java.net
package. Trivially, the list type should be left to the CSS.
Note: with these changes there are still warnings for two DatagramPacket
constructors that are
looks fine Joe
On Jul 25, 2013, at 2:30 AM, huizhe wang wrote:
I received test from the NetBeans team. The NetBeans did reference the
internal JAXPSAXParser directly. This is not a usage supported by the spec. I
would suggest them remove it and use the default parser instead. I'm asking
Hi Omair and Alan,
I get this error:
In file included from
/home/hf/adopt_openjdk/openjdk8/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.c:11:0:
/home/hf/adopt_openjdk/openjdk8/jdk/src/solaris/native/sun/awt/awt_p.h:44:27:
fatal error: X11/Intrinsic.h: No such file or
Hi
sudo yum install libXt-devel solve the dependency problem.
but i get other...
cc1: all warnings being treated as errors
gmake[2]: ***
[/home/hf/adopt_openjdk/openjdk8/build/linux-x86-normal-server-release/jdk/objs/libsctp/SctpChannelImpl.o]
Error 1
gmake[2]: *** Waiting for unfinished
Hi Ivan,
Thank you for your diligence.
1) Should the test use an alternate mechanism to read the file
(FileInputStream)
and confirm the length of the array?
2) There is an edge case where the file size is between MAX_ARRAY_SIZE
and Integer.MAX_VALUE that should be avoided. The lines at L3022
Changeset: 3155e77d2676
Author:mcimadamore
Date: 2013-07-25 14:47 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3155e77d2676
8020804: javac crashes when speculative attribution infers intersection type
with array component
Summary: Assertion is causing javac to crash
On 07/24/13 19:30, Martin Buchholz wrote:
PriorityQueue is unusual in that Doug maintains a copy in jsr166 CVS even though
it is a non-thread-safe collection. I think it makes sense,
because PriorityQueue and PriorityBlockingQueue have parallel APIs and parallel
implementations. Many changes
Hi Dan,
Thanks for looking at this,
On Jul 23, 2013, at 11:12 PM, Dan Smith daniel.sm...@oracle.com wrote:
Hi.
Per a request from Joel, I've taken a look at DefaultStaticTestData. I don't
really have the full context here, but I'm assuming that the annotations get
translated into tests
Hi Amy,
On Jul 24, 2013, at 3:30 AM, Amy Lu amy...@oracle.com wrote:
Thank you Dan !
Please see my comments inline...
On 7/24/13 5:12 AM, Dan Smith wrote:
Hi.
Per a request from Joel, I've taken a look at DefaultStaticTestData. I
don't really have the full context here, but I'm
On 7/25/2013 1:06 AM, Chris Hegarty wrote:
On 07/25/2013 08:39 AM, Daniel Fuchs wrote:
Hi Joe,
Looks good.
+1
Small nit: you could keep fSecurityPropertyManager final by using:
if (spm != null) {
fSecurityPropertyManager = spm;
} else {
fSecurityPropertyManager = new ...
Thanks!
Joe
On 7/25/2013 3:25 AM, Lance Andersen - Oracle wrote:
looks fine Joe
On Jul 25, 2013, at 2:30 AM, huizhe wang wrote:
I received test from the NetBeans team. The NetBeans did reference
the internal JAXPSAXParser directly. This is not a usage supported by
the spec. I would suggest
Thanks a lot Erik,
I've added the dependency to the makefile here:
http://cr.openjdk.java.net/~robm/5049299/webrev.05/
http://cr.openjdk.java.net/%7Erobm/5049299/webrev.05/
Is it ok between the ifeq block?
Alan,
I've altered the launchMechanism code to use valueOf (and lower case
names) -
FWIW, I've filed a bug against doclint to allow ordered lists of the
form ol = a
JDK-8021324 [doclint] Doclint need not warn over use of ordered
lists with styles
In any case, the changes below look fine to go back; if you want to
leave the ol = a in java.net, that would be fine by me
Changeset: 5c035c4ccc61
Author:sundar
Date: 2013-07-25 14:05 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5c035c4ccc61
8021252: invokeMethod throws NoSuchMethodException when script object is from
different script context
Reviewed-by: lagergren, hannesw
!
Changeset: 21120e3682ef
Author:darcy
Date: 2013-07-25 09:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21120e3682ef
8021408: Fix misc doclint issues in java.util and java.io
Reviewed-by: dholmes, chegar, psandoz
! src/share/classes/java/io/ObjectInputStream.java
!
Changeset: a834ab2c1354
Author:mullan
Date: 2013-07-25 10:58 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a834ab2c1354
8010748: Add PKIXRevocationChecker NO_FALLBACK option and improve SOFT_FAIL
option
Reviewed-by: vinnie
!
My apologies if this is not the right place to address this. If so, please
forgive and direct me to the correct list.
There are a lot of people/projects complaining about Java 8's new self-closing
element not allowed error when compiling JavaDoc that has legal br / tags in
it (just google
On 07/25/2013 12:27 PM, Nick Williams wrote:
My apologies if this is not the right place to address this. If so, please
forgive and direct me to the correct list.
There are a lot of people/projects complaining about Java 8's new self-closing element not allowed
error when compiling JavaDoc
Its complicated, see for example:
http://stackoverflow.com/questions/3558119/are-self-closing-tags-valid-in-html5
The key point here is not whether its in the standard or not, but what
people actually *do*.
There is no doubt in my mind that br / br space slash is very common
indeed. Its
It all hinges on whether the tool is generating HTML 4 or HTML 5. If 4,
then the output should be HTML 4 strict and this kind of input should
either be translated or forced to be valid.
If the output is going to be HTML 5 - which I suspect is going to be
considered premature given the usual
Changeset: 690dcbaa69b7
Author:chegar
Date: 2013-07-25 19:37 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/690dcbaa69b7
8021417: Fix doclint issues in java.util.concurrent
Reviewed-by: chegar, lancea
Contributed-by: Doug Lea d...@cs.oswego.edu
!
Changeset: 9cd5159fa870
Author:chegar
Date: 2013-07-25 19:45 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9cd5159fa870
8021421: More doclint fixes in java.net
Reviewed-by: lancea, darcy
! src/share/classes/java/net/URI.java
Hi, the documents are HTML 4. I checked a sample with w3c validator and
there i get only a warning (not an error).
Warning Line 180, Column 4: NET-enabling start-tag requires SHORTTAG YES
br/
✉
The sequence FOO / can be interpreted in at least two different ways,
depending on the DOCTYPE
JDK 8 Reviewers:
This patch is still pending approval by:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018922.html
Thanks,
Brian
The message about self-closing element not allowed is because
self-closing elements are not allowed in HTML 4. The message is
generated by the new doclint feature available in javac and javadoc,
which is specifically intended to detect issues in javadoc comments. If
you do not wish to use the
The changes look OK to me. I do prefer the later form but will accept either.
Mike
On Jul 25 2013, at 02:31 , Paul Sandoz wrote:
Hi,
Please review the following patch that fixes two issues with TreeMap
spliterators:
Changeset: 251ca1e2ccd3
Author:joehw
Date: 2013-07-25 13:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/251ca1e2ccd3
8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)
Reviewed-by: chegar, lancea, dfuchs
!
Correction: I see now that we're using Frameset doctype for the parent page and
Transitional for the pages within frames. I misunderstood that. My bad.
On Jul 25, 2013, at 3:19 PM, Nick Williams wrote:
Point of interest: JavaDoc uses the HTML 4 Loose specification, not the
HTML 4 Strict
Point of interest: JavaDoc uses the HTML 4 Loose specification, not the HTML
4 Strict specification. By using frames, JavaDoc is in violation of the HTML
4.01 Loose specification (see below).
There are void elements and there are empty elements.
Void elements are elements that ARE NOT ALLOWED
Changeset: 662ec7782102
Author:joehw
Date: 2013-07-25 13:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/662ec7782102
8021148: Regression in SAXParserImpl in 7u40 b34 (NPE)
Reviewed-by: chegar, lancea, dfuchs
+ test/javax/xml/jaxp/parsers/8021148/JAXPSAXParserTest.java
+
Jonathan, I don't see the confirmation that this is not legal HTML that you
reference. I see a warning that some browsers may not interpret it correctly.
But IE 5+ and all Firefox, Chrome, Netscape, Opera, etc. versions interpret it
correctly.
I understand your point about the spec not
Hello,
Please review these changes to remove the javac lint warnings from the
java.lang.ref package:
8021429 Fix lint warnings in java.lang.ref
http://cr.openjdk.java.net/~darcy/8021429.0/
Care was taken to not change any signatures of public API elements.
After doing a clean build,
First, as was pointed out earlier[1] in the original thread, the HTML 4 spec
does not mention the existence of self-closing elements, and in that
message,
David makes a good point that br is defined to not have an end tag,
making the br/ syntax doubly questionable.
So what does doclint stand
Looks fine joe
On Jul 25, 2013, at 4:33 PM, Joe Darcy wrote:
Hello,
Please review these changes to remove the javac lint warnings from the
java.lang.ref package:
8021429 Fix lint warnings in java.lang.ref
http://cr.openjdk.java.net/~darcy/8021429.0/
Care was taken to not change
On 25/07/2013 13:33, Joe Darcy wrote:
Hello,
Please review these changes to remove the javac lint warnings from the
java.lang.ref package:
8021429 Fix lint warnings in java.lang.ref
http://cr.openjdk.java.net/~darcy/8021429.0/
Care was taken to not change any signatures of public
Okay. To address some of your points (not in order):
- I do not interpret no end tags as a strict prohibition on self-closing
elements. I think many people agree with me. I think the fact that browsers
barf at br/br but not br / reinforces this interpretation.
- HTML5 does allow self-closing
On 07/25/2013 01:58 PM, Alan Bateman wrote:
On 25/07/2013 13:33, Joe Darcy wrote:
Hello,
Please review these changes to remove the javac lint warnings from
the java.lang.ref package:
8021429 Fix lint warnings in java.lang.ref
http://cr.openjdk.java.net/~darcy/8021429.0/
Care was
Hi Joe,
On Jul 24, 2013, at 9:01 PM, Joe Darcy wrote:
I took a look through the code and I don't see how sdiff == Integer.MIN_VALUE
is handled.
This case, if compareMagnitude() does not return at lines 2668 or 2670,
intentionally falls through to line 2690. Otherwise, if hypothetically
Hi Roger!
On 25.07.2013 17:42, roger riggs wrote:
Hi Ivan,
Thank you for your diligence.
Thank you for your patience :)
1) Should the test use an alternate mechanism to read the file
(FileInputStream)
and confirm the length of the array?
This file can change from read to read. But it
On 07/25/2013 02:01 PM, Nick Williams wrote:
Okay. To address some of your points (not in order):
- I do not interpret no end tags as a strict prohibition on self-closing elements. I think many
people agree with me. I think the fact that browsers barf at br/br but not br /
reinforces this
On Jul 25, 2013, at 7:16 PM, Jonathan Gibbons wrote:
On 07/25/2013 02:01 PM, Nick Williams wrote:
Okay. To address some of your points (not in order):
- I do not interpret no end tags as a strict prohibition on self-closing
elements. I think many people agree with me. I think the fact
Changeset: 1744a32d3db3
Author:mullan
Date: 2013-07-25 20:12 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1744a32d3db3
8012288: XML DSig API allows wrong tag names and extra elements in SignedInfo
Reviewed-by: xuelei
!
On 07/25/2013 05:21 PM, Nick Williams wrote:
So why is self-closing element not allowed considered an error when it's only
a warning when validated with a W3 validator? Seems to me like a reasonable compromise to
make this a warning instead of an error. Thoughts?
Right now, the guideline is
Changeset: 86a827321c39
Author:darcy
Date: 2013-07-25 20:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86a827321c39
8021429: Fix lint warnings in java.lang.ref
Reviewed-by: lancea, mduigou, alanb
! src/share/classes/java/lang/ref/FinalReference.java
!
An update, I played around with the declarations a bit more, but wasn't
about to find something workable so I pushed the already-reviewed version.
If someone else wants to take a crack at improving the generics, I think
that would be a fine refactoring.
Thanks,
-Joe
On 7/25/2013 2:16 PM,
On 25/07/2013 16:56, Ivan Gerasimov wrote:
Would you please help review an updated webrev?
http://cr.openjdk.java.net/~igerasim/8020669/4/webrev/
Sorry for the late response to your mails on this, I was on vacation.
As you have found, in the original implementation we allowed for
resizing
69 matches
Mail list logo
