Hi,
This is the 2nd of the three [findbug] issues. The field fVersion is
simply made final.
webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8003261/webrev/
Test:
No new test needed.
Thanks,
Joe
Joe,
On 18/12/2012 6:47 PM, Joe Wang wrote:
Hi,
This is the 2nd of the three [findbug] issues. The field fVersion is
simply made final.
webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8003261/webrev/
Obviously it was known that this was a potential problem as we have
fImmutableVersion. So
On Dec 17, 2012, at 4:39 PM, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi,
As pointed out by Paul Alan, there's no reason to force
Class.forName to initialize the class when attempting to
load it in FactoryFinder.
FactoryFinder should behave like ServiceLoader in this respect.
So
On Dec 18, 2012, at 7:02 AM, Mandy Chung mandy.ch...@oracle.com wrote:
Hi Daniel,
There are currently several different FactoryFinder class in the JAXP
implementation and there might be slight difference in each of them. Do you
know if it has been looked into whether it's feasible to
On 12/17/2012 11:39 PM, Remi Forax wrote:
On 12/17/2012 11:14 PM, Peter Levart wrote:
On 12/17/2012 10:26 PM, Mandy Chung wrote:
On 12/17/12 7:36 AM, Peter Levart wrote:
Hi David and others,
Here's a patch that eliminates one of two fields in
java.lang.Class, related to caching enum
On 12/18/2012 01:50 AM, David Holmes wrote:
Hi Peter,
BTW JEP-149 not 146!
Sorry, my bad ;-(
Sorry I didn't get a chance to respond last night before you continued
on this path. I have to say no to this too. First I am just running
out of time to get this finalized by M6 - particularly
Changeset: 92fcf299cd09
Author:ohrstrom
Date: 2012-12-18 10:23 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/92fcf299cd09
8004657: Add hooks to javac to enable reporting dependency information.
Reviewed-by: jjg, mcimadamore
!
On 18/12/2012 7:24 PM, Peter Levart wrote:
On 12/18/2012 01:50 AM, David Holmes wrote:
Hi Peter,
BTW JEP-149 not 146!
Sorry, my bad ;-(
Sorry I didn't get a chance to respond last night before you continued
on this path. I have to say no to this too. First I am just running
out of time to
On 12/18/2012 02:58 AM, David Holmes wrote:
On 18/12/2012 3:06 AM, Joel Borggrén-Franck wrote:
On Dec 17, 2012, at 5:00 PM, Peter Levartpeter.lev...@gmail.com wrote:
Hi Joel,
82 // This is set by the vm at Method creation
83 private byte[] type_annotations;
On 18/12/2012 11:45, Joel Borggrén-Franck wrote:
New webrev after renaming the fields:
cr.openjdk.java.net/~jfranck/8004699/webrev.01/
I'll post matching HotSpot changes to hs-dev later today.
Thanks for the rename, looks fine to me.
-Alan
+1
--
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 Dec 18, 2012, at 3:47 AM, Joe Wang huizhe.w...@oracle.com wrote:
Hi,
This is the 2nd of the three
I've refreshed the webrev here to take in another change from Joe to the
root element handling in PropertiesDefaultHandler.
http://cr.openjdk.java.net/~alanb/8004371/webrev.03/
I'd like to get this into jdk8/tl in the next few days if possible.
On tests on then I've expanded LoadAndStoreXML
Hi,
Thanks for the review.
I updated the webrev to keep track of your suggested change.
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.01/
-- daniel
On 12/18/12 4:00 PM, Alan Bateman wrote:
I looked through this installment and aside from an aside from an
alignment
Hi,
Here is a new webrev in the series that addresses using ServiceLoader in
JAXP for JDK 8.
7169894: JAXP Plugability Layer: using service loader
This changeset addresses modification in the javax.xml.transform
package.
It is similar to changes proposed for the javax.xml.parsers
package [1],
Am 18.12.2012 05:15, schrieb Mandy Chung:
On 12/17/12 8:13 AM, Ulf Zibis wrote:
Am 17.12.2012 16:23, schrieb Alan Bateman:
I mostly agree with your argument that this is a new tool and that we should be consistent with
GNU-style options. So what was the final bid is, is it --classpath or
Thanks Chris!
On 12/18/2012 12:53 AM, Chris Hegarty wrote:
Looks ok to me Joe.
-Chris
On 18 Dec 2012, at 08:47, Joe Wanghuizhe.w...@oracle.com wrote:
Hi,
This is the 2nd of the three [findbug] issues. The field fVersion is simply
made final.
webrev:
On 12/18/2012 12:55 AM, David Holmes wrote:
Joe,
On 18/12/2012 6:47 PM, Joe Wang wrote:
Hi,
This is the 2nd of the three [findbug] issues. The field fVersion is
simply made final.
webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8003261/webrev/
Obviously it was known that this was a
Hi Daniel,
The call: T provider = findServiceProvider(type) in static T T
find(ClassT type, String factoryId, ClassLoader cl, String
fallbackClassName) ignored factoryId, and assumed it's the same as
type.getName(). I looked back I had the same bug in my original patch.
-Joe
On 12/18/2012
Not that it's particularly important, but it's /possible/ clients are
relying on the non-compile time constant nature of this field causing it
not to be inlined into client class files, rather than the ability to
switch the version string. So it may be a good idea to add the final,
but make it
On 12/18/12 6:29 PM, Joe Wang wrote:
Hi Daniel,
The call: T provider = findServiceProvider(type) in static T T
find(ClassT type, String factoryId, ClassLoader cl, String
fallbackClassName) ignored factoryId, and assumed it's the same as
type.getName(). I looked back I had the same bug in my
Changeset: 0fabdf676395
Author:martin
Date: 2012-12-17 18:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0fabdf676395
8004863: Infinite Loop in KeepAliveStream
Reviewed-by: chegar
! src/share/classes/sun/net/www/http/KeepAliveStream.java
+
Hi Daniel,
Looks great! I see you've added many verifications.
One minor note, creationMethod is used in place of the object instance
for the creationMethod.invoke call, although it's ignored for a static
method anyways. Is there a reason for doing that?
-Joe
On 12/18/2012 8:42 AM,
On 12/18/2012 10:18 AM, Peter Levart wrote:
On 12/17/2012 11:39 PM, Remi Forax wrote:
On 12/17/2012 11:14 PM, Peter Levart wrote:
On 12/17/2012 10:26 PM, Mandy Chung wrote:
On 12/17/12 7:36 AM, Peter Levart wrote:
Hi David and others,
Here's a patch that eliminates one of two fields in
On 12/18/2012 10:00 AM, Daniel Fuchs wrote:
On 12/18/12 6:29 PM, Joe Wang wrote:
Hi Daniel,
The call: T provider = findServiceProvider(type) in static T T
find(ClassT type, String factoryId, ClassLoader cl, String
fallbackClassName) ignored factoryId, and assumed it's the same as
On 12/18/12 1:09 AM, Paul Sandoz wrote:
On Dec 18, 2012, at 7:02 AM, Mandy Chungmandy.ch...@oracle.com wrote:
Hi Daniel,
There are currently several different FactoryFinder class in the JAXP
implementation and there might be slight difference in each of them. Do you
know if it has been
On 12/18/12 9:06 AM, Ulf Zibis wrote:
Am 18.12.2012 05:15, schrieb Mandy Chung:
On 12/17/12 8:13 AM, Ulf Zibis wrote:
Am 17.12.2012 16:23, schrieb Alan Bateman:
I mostly agree with your argument that this is a new tool and that
we should be consistent with GNU-style options. So what was the
On 12/18/12 8:42 AM, Daniel Fuchs wrote:
Hi,
Here is a new webrev in the series that addresses using ServiceLoader in
JAXP for JDK 8.
7169894: JAXP Plugability Layer: using service loader
This changeset addresses modification in the javax.xml.transform
package.
It is similar to changes
Hello,
Please review these changes to add core reflection support to recognize
default methods:
8005042 Add Method.isDefault to core reflection
http://cr.openjdk.java.net/~darcy/8005042.0/
Thanks,
-Joe
On 12/18/2012 09:43 PM, Joe Darcy wrote:
Hello,
Please review these changes to add core reflection support to
recognize default methods:
8005042 Add Method.isDefault to core reflection
http://cr.openjdk.java.net/~darcy/8005042.0/
Thanks,
-Joe
Looks good.
Rémi
Looks good to me. Will a JLS reference be added in when defined? It seems kind
of odd to mention JLS and not provide a ref.
Nice use of annotations in the test. I will steal this technique and can think
of tests where I should have used it.
Mike
On Dec 18 2012, at 12:43 , Joe Darcy wrote:
On 18/12/2012 20:43, Joe Darcy wrote:
Hello,
Please review these changes to add core reflection support to
recognize default methods:
8005042 Add Method.isDefault to core reflection
http://cr.openjdk.java.net/~darcy/8005042.0/
Thanks,
-Joe
This looks okay to me except that I would
Code looks good, Joe. There is just one grammatical nit with the comment:
* A default method is a non-abstract method, that is a method with
512 * a body, declared in an interface type.
that is should have a comment after it.
Thanks,
Jim
On 12/18/2012 03:43 PM, Joe Darcy wrote:
On 12/18/12 12:43 PM, Joe Darcy wrote:
Hello,
Please review these changes to add core reflection support to
recognize default methods:
8005042 Add Method.isDefault to core reflection
http://cr.openjdk.java.net/~darcy/8005042.0/
Looks good to me.
For the test:
56
Excuse me, a comma.
On 12/18/2012 04:20 PM, Jim Gish wrote:
Code looks good, Joe. There is just one grammatical nit with the comment:
* A default method is a non-abstract method, that is a method with
512 * a body, declared in an interface type.
that is should have a comment
On 12/18/12 9:06 PM, Mandy Chung wrote:
In FactoryFinder.newInstanceNoServiceLoader method, L223, 226 -
NoSuchMethodException will be thrown if such method doesn't exist.
creationMethod will not be null.
Thanks - yes - you're right of course - no need to check for null...
L236 - this change
On 12/18/12 7:38 PM, Joe Wang wrote:
Hi Daniel,
Looks great! I see you've added many verifications.
One minor note, creationMethod is used in place of the object
instance for the creationMethod.invoke call, although it's ignored for
a static method anyways. Is there a reason for doing
Changeset: 250f0acf880c
Author:mcimadamore
Date: 2012-12-18 22:16 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/250f0acf880c
8005193: New regression test test/tools/javac/lambda/BadMethodCall2.java fails
Summary: Bad golden file in negative test
Reviewed-by: jjh
!
Hello,
On 12/18/2012 01:17 PM, Mike Duigou wrote:
Looks good to me. Will a JLS reference be added in when defined? It seems kind
of odd to mention JLS and not provide a ref.
Yes; once there is a particular JLS section available to reference, this
documentation should be updated to
+1
Thanks,
David
On 18/12/2012 9:55 PM, Alan Bateman wrote:
On 18/12/2012 11:45, Joel Borggrén-Franck wrote:
New webrev after renaming the fields:
cr.openjdk.java.net/~jfranck/8004699/webrev.01/
I'll post matching HotSpot changes to hs-dev later today.
Thanks for the rename, looks fine to
It's not 100% obvious to me whether this refers to a default implementation
in an interface, a class which inherits that default implementation and
does not override it, or both. Is that worth clarifying in the doc, rather
than forcing readers to check the JLS citation?
On Tue, Dec 18, 2012 at
Changeset: 6d977f61af5e
Author:darcy
Date: 2012-12-18 14:49 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d977f61af5e
8004699: Add type annotation storage to Constructor, Field and Method
Reviewed-by: darcy, dholmes
Contributed-by: joel.fra...@oracle.com
!
On 12/18/2012 2:23 PM, Daniel Fuchs wrote:
On 12/18/12 8:00 PM, Joe Wang wrote:
On 12/18/2012 10:00 AM, Daniel Fuchs wrote:
On 12/18/12 6:29 PM, Joe Wang wrote:
Hi Daniel,
The call: T provider = findServiceProvider(type) in static T T
find(ClassT type, String factoryId, ClassLoader cl,
Alan, Ulf,
I updated the jdeps CLI per the discussion we had.
$ jdeps --help
Usage: jdeps options classes...
where classes can be a pathname to a .class file, a directory, a JAR file,
or a fully-qualified classname or wildcard *. Possible options include:
-s --summary
On 19/12/2012 3:49 AM, Tom Hawtin wrote:
Not that it's particularly important, but it's /possible/ clients are
relying on the non-compile time constant nature of this field causing it
not to be inlined into client class files, rather than the ability to
switch the version string. So it may be a
On 19/12/2012 7:29 AM, Jim Gish wrote:
Excuse me, a comma.
On 12/18/2012 04:20 PM, Jim Gish wrote:
Code looks good, Joe. There is just one grammatical nit with the comment:
* A default method is a non-abstract method, that is a method with
512 * a body, declared in an interface type.
On 19/12/2012 8:40 AM, Louis Wasserman wrote:
It's not 100% obvious to me whether this refers to a default implementation
in an interface, a class which inherits that default implementation and
does not override it, or both. Is that worth clarifying in the doc, rather
than forcing readers to
Could we say that, in so many words, in the Javadoc?
On Tue, Dec 18, 2012 at 4:12 PM, David Holmes david.hol...@oracle.comwrote:
On 19/12/2012 8:40 AM, Louis Wasserman wrote:
It's not 100% obvious to me whether this refers to a default
implementation
in an interface, a class which inherits
On 19/12/2012 10:16 AM, Joe Darcy wrote:
On 12/18/2012 04:12 PM, David Holmes wrote:
On 19/12/2012 8:40 AM, Louis Wasserman wrote:
It's not 100% obvious to me whether this refers to a default
implementation
in an interface, a class which inherits that default implementation and
does not
On 12/18/2012 04:12 PM, David Holmes wrote:
On 19/12/2012 8:40 AM, Louis Wasserman wrote:
It's not 100% obvious to me whether this refers to a default
implementation
in an interface, a class which inherits that default implementation and
does not override it, or both. Is that worth clarifying
On 12/18/12 6:17 AM, Alan Bateman wrote:
I've refreshed the webrev here to take in another change from Joe to
the root element handling in PropertiesDefaultHandler.
http://cr.openjdk.java.net/~alanb/8004371/webrev.03/
I'd like to get this into jdk8/tl in the next few days if possible.
On
On 12/18/2012 04:20 PM, David Holmes wrote:
On 19/12/2012 10:16 AM, Joe Darcy wrote:
On 12/18/2012 04:12 PM, David Holmes wrote:
On 19/12/2012 8:40 AM, Louis Wasserman wrote:
It's not 100% obvious to me whether this refers to a default
implementation
in an interface, a class which inherits
On 19/12/2012 10:24 AM, Joe Darcy wrote:
On 12/18/2012 04:20 PM, David Holmes wrote:
On 19/12/2012 10:16 AM, Joe Darcy wrote:
On 12/18/2012 04:12 PM, David Holmes wrote:
On 19/12/2012 8:40 AM, Louis Wasserman wrote:
It's not 100% obvious to me whether this refers to a default
implementation
Thanks Tom. I changed it as you suggested.
I did initially remove the string and have main print out getVersion()
instead, but I reverted it with a 2nd thought same as you, that it's
/possible/ someone might be using it :)
New webrev is here:
+1
--
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 Dec 18, 2012, at 8:51 PM, Joe Wang huizhe.w...@oracle.com wrote:
Thanks Tom. I changed it as you
On 12/18/2012 3:43 PM, David Holmes wrote:
On 19/12/2012 3:49 AM, Tom Hawtin wrote:
Not that it's particularly important, but it's /possible/ clients are
relying on the non-compile time constant nature of this field causing it
not to be inlined into client class files, rather than the ability
Thanks :)
On 12/18/2012 6:16 PM, Lance Andersen wrote:
+1
--
http://oracle.com/us/design/oracle-email-sig-198324.gif
http://oracle.com/us/design/oracle-email-sig-198324.gifLance
Andersen| Principal Member of Technical Staff | +1.781.442.2037
tel:+1.781.442.2037
Oracle Java Engineering
1
On 19/12/2012 12:21 PM, Joe Wang wrote:
On 12/18/2012 3:43 PM, David Holmes wrote:
On 19/12/2012 3:49 AM, Tom Hawtin wrote:
Not that it's particularly important, but it's /possible/ clients are
relying on the non-compile time constant nature of this field causing it
not to be inlined into
Changeset: e8b54ae97344
Author:jviswana
Date: 2012-12-12 13:28 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8b54ae97344
8004316: Printer - tempfile having incorrect extension
Reviewed-by: bae, jgodinez
! src/solaris/classes/sun/print/UnixPrintJob.java
Changeset:
On 12/18/2012 7:08 PM, David Holmes wrote:
On 19/12/2012 12:21 PM, Joe Wang wrote:
On 12/18/2012 3:43 PM, David Holmes wrote:
On 19/12/2012 3:49 AM, Tom Hawtin wrote:
Not that it's particularly important, but it's /possible/ clients are
relying on the non-compile time constant nature of
Changeset: 15b32367b23c
Author:joehw
Date: 2012-12-18 21:11 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/15b32367b23c
8003261: static field is public but not final
Summary: add final to fVersion field, and make it a non-compile time constant.
Reviewed-by: hawtin, lancea,
60 matches
Mail list logo
