Re: Swing Dev Add LookFeel support for AIX platform
On 14:45 Tue 13 Dec , Neil Richards wrote: On Tue, 2011-12-13 at 14:42 +, Neil Richards wrote: On Tue, 2011-12-13 at 10:36 +0800, Sean Chou wrote: On Mon, Dec 12, 2011 at 7:33 PM, Neil Richards neil.richa...@ngmr.net wrote: On Tue, 2011-12-06 at 11:14 +0800, Sean Chou wrote: Hi, I'm not sure what to do for it next, shall I create a bug for it now ? But I don't think the bug system support AIX platform. I remembered it would report something like we are not supporting the platform. Hi Sean, Looking at the options available on the Java bug submission site [1], it looks like: Release: OpenJDK Operating System: Generic / Other would be the most appropriate choices to make. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU I tried once, and it was dropped because the platform is not supported. -- Best Regards, Sean Chou Hmm, in that case, perhaps someone from Oracle can help in creating a suitable Java bug id under which this change can be made? From the OpenJDK census [1], I see that both Mario and I are currently committers in the jdk8 project. As jdk8 is under review control, I believe you'll need some affirmation from someone who is a reviewer. Such a person is currently likely to be from Oracle, and so may be able to help in creating the associated bug id. Hope this helps. Regards, Neil Oops, forgot to give the trailed link to the OpenJDK census. Regards, Neil [1] http://openjdk.java.net/census -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU This seems to have dragged on an unduly long time for such a simple patch. The patch looks good to me. The only minor point I'd make is that the comment '// determine another OS here' should probably be under where the AIX if block is added, not above it. According to the census, I have jdk8 reviewer status so this should count as a review. However, as we're still stuck with the antiquated bug system at present, we still need someone at Oracle to give it a bug ID. So if an Oracle employee would be so kind as to do so, this can finally be pushed. It's only about two months old... -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: Request for review: More cause-chaining for InternalError
On 14:16 Tue 23 Aug , Sebastian Sickelmann wrote: Am 22.08.2011 21:19, schrieb Joe Darcy: Sebastian Sickelmann wrote: Am 17.08.2011 03:11, schrieb joe.da...@oracle.com: Hello. On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote: Hi, some time ago, i wrote[5] with Joe and David about advancing some exception-types to the 4 standard ctors. The first Exception i have looked at was InternalError and now(after some struggeling with gnumake and hg) my patches for reviewing are ready. I uploaded them at [4] I split the changes into 3 parts. 1. Added 2 ctors to InternalError and VirtualMachineError[1] 2. Use the two ctors of InternalError[2] (based on [1]) 3. Chain Rootcause into InternalError**[3] (based also on [1]) I think part 1 and 2 are uncritical. Part 3 is more critical because it changes behavior (exception-chaining). But i don't think that part 3 is unimportable, because in case of an InternalError (use should not be able to recover) there shouldn't be a problem with a little longer exception-chain. Is there someone who what to sponsor this or parts of it? [1] https://bugs.openjdk.java.net/attachment.cgi?id=233 [2] https://bugs.openjdk.java.net/attachment.cgi?id=234 [3] https://bugs.openjdk.java.net/attachment.cgi?id=235 [4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201 [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html I am willing to sponsor this work and I've filed bug 7080020 Add conventional constructors to InternalError for it. For adding constructors to InternalError (or VirtualMachineError), the push that adds the constructors should include some usage of them. Therefore, at least portions of 1) and 2) above should be combined. If there are easy to find usages of a cause for VirtualMachineError, then those should be included at the same time any new constructors are added there. VirtualMachineError is changed because it is the abstract super class of InternalError so use of the VirtualMachineError ctors is inside of the InternalError ctors There is some currently Oracle-internal paperwork which needs to be filed to make an API change; I'll file that paperwork once there is verification on whether updates to both InternalError and VirtualMachineError will be included in this round of work. The paperwork needs to be approved before the change is pushed and typically takes a few days to be processed. OK. That much work for just chaining up exceptions. I am happy that i needn't to do this paperwork. I hope it's virtual paperwork. ;-) I will post the change in 2 webrevs than. One for the smaller part (Change of the InternalError itself + some small changes initCause usage to ctor parameter) And one for the bigger part (Chain all uses of InternalError with the root-cause if any root-cause exists) i must rebase it again. Will post webrev url at the other thread in short. Hello. The internal API paperwork went through; I've just pushed a changeset with the additional constructors and some usage of them to replace calls to initCause methods: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130 Thanks, -Joe Thanks for commiting. My email-adress has a typo but that isn't a real problem ;-) I have rebased my additional chainings of InternalError on your commit. The webrev is: http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_c43af666d130/ Reviews are welcome for this too. This looks fine to me; mostly trivial stuff. - Sebastian -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: hg: jdk8/tl/jdk: 7082727: VirtualMachineError should declare its serialVersionUID
On 16:43 Thu 25 Aug , joe.da...@oracle.com wrote: Changeset: 624cc18a6cf9 Author:darcy Date: 2011-08-25 09:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624cc18a6cf9 7082727: VirtualMachineError should declare its serialVersionUID Reviewed-by: alanb ! src/share/classes/java/lang/VirtualMachineError.java Is there a general policy on serialVersionUIDs within the JDK i.e. that they are declared? I've seen a few warnings during builds, and I'm wondering what the correct fix is in the majority of cases. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Enhance toString() to return structured info, for certificate and probably more
On 10:41 Thu 25 Aug , Weijun Wang wrote: Hi All I was talking with Xuelei on how to better display certificate info. There are 3 cases we can currently think of: 1. debug output 2. keytool/jarsigner output 3. Java plugin display The 1st one is the most primitive one and can be a single string, the 2nd is also a string but have some format and needs to localized, the third is a series of Swing controls. But the contents of all 3 are the same, and hopefully can be provided in a single method. Each consumer can just display it in its own style, with no need to understand Certificate fields, OIDs, etc. It's just like XSLT transformation of XML files. So what shall I do? Let toString() outputs a long string in XML or JSON? I be against that. It goes against the usual expectation of toString output being (fairly) human-readable. Or, create a new method describe() or toDescription() that returns a UnmodifiableMap (based on a LinkedHashMap to preserve order)? I prefer the latter because there is no need to parse the output, and at least in the case of certificate, since a certificate contains extensions, it's very easy to stuff several maps inside another one. The map's keys are strings, and values can be another map or a simple data object, say, primitive, string, or Date. So this needs a new interface Descriptable. It can either be: interface sun.security.util.Descriptable; sun.security.x509.X509CertImpl implements Descriptable; sun.security.x509.Extension implements Descriptable; or interface java.security.Descriptable; java.security.cert.X509Certificate implements Descriptable; java.security.cert.Extension implements Descriptable; or if there are other people find it useful, it can be inside the java.util package. This sounds like a good idea to me, but would there be a standard set of keys and values? Especially if it's going to be part of java.security, the keys and values should be part of the method specification. This becomes a harder task if it's generalised into java.util. BTW, it should be Describable :-) What's your ideas? Do you also need such a method? Thanks Max -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Request for Review: Chain more Exceptions (RuntimeException)
On 07:01 Thu 18 Aug , Sebastian Sickelmann wrote: Hi, i have created a fix for fixing Exception-Chains in case of an rethrown RuntimeException. I am not quite sure if this is inside the scope of what i discussed[0][1] with Joe. But it is fixed in the same manner as the patches there. http://oss-patches.24.eu/openjdk8/RuntimeException/REBASED_ON_07ad16388170/ Someone who wants to review / sponsor this? Looks good to me. Nice cleanup. -- Sebastian [0] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007399.html -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]
On 17:11 Tue 02 Aug , Alan Bateman wrote: Xuelei Fan wrote: : 1. I noticed the copyright date of a few files are unchanged, please update them before you push the changes. This has come up a few times but I don't think it is strictly required. Kelly or one of the release engineers run a script over the forest periodically to fix up the date range. The nice thing (in my view anyway) about not changing the headers is that it avoids clutter in the patch and webrev. It also makes it a bit easier to transport patches to other releases. I was thinking the same thing. Copyright header changes mixed into other patches are a nightmare as regards backporting. -Alan -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [Fwd: Code review request: 7072353 JNDI libraries do not build with javac -Xlint:all -Werror]
On 09:24 Wed 03 Aug , Joe Darcy wrote: On 8/3/2011 12:42 AM, David Holmes wrote: Alexandre Boulgakov said the following on 08/03/11 04:44: On 8/2/2011 2:19 AM, Xuelei Fan wrote: 3017 VectorObject temp = (Vector)extractURLs(res.errorMessage); You may not need the conversion any more, the return value of extractURLs() has been updated to 2564 private static VectorString extractURLs(String refString) The cast is needed to go from VectorString to VectorObject. Raw types should be avoided (here and elsewhere there are casts to raw Vector). I'm surprised (generics continue to surprise me) that despite all our advances in type-inference etc that the compiler can not tell that a VectorT is-a VectorObject. :( That is because in general a VectorT is not a VectorObject because of the way subtyping works. As with arrays, it all looks fine until you want to change the container; consider VectorString vs = new Vector(); ... VectorObject vo = vs; // Assume this was okay to alias an object vector and a string vector vo.add(new Integer(1)); // Add an Integer to a list of strings, boom! Using wildcards makes the subtyping work along the type argument axis. Exactly. What I wondered on reading this is why it needs to be cast to a VectorObject anyway. That would only reduce type safety as you say. -Joe -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac -Xlint:all, -deprecation -Werror
On 21:44 Thu 28 Jul , jonathan.gibb...@oracle.com wrote: Changeset: 7525866a4046 Author:jjg Date: 2011-07-28 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7525866a4046 7068616: NIO libraries do not build with javac -Xlint:all,-deprecation -Werror Reviewed-by: alanb, chegar Contributed-by: alexandre.boulga...@oracle.com ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/Makefile ! make/java/nio/Makefile ! make/java/sun_nio/Makefile ! make/sun/nio/Makefile ! make/sun/nio/cs/Makefile ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Reflect.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/cs/FastCharsetProvider.java ! src/share/classes/sun/nio/cs/StreamDecoder.java ! src/share/classes/sun/nio/cs/ThreadLocalCoders.java ! src/share/classes/sun/nio/fs/Util.java ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/ch/PendingIoCache.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Is there some (very welcome) focus on fixing these errors at the moment? If so, is this across this board or just the jdk tree (or even parts of the jdk tree)? I fixed a few a while back during the OpenJDK7 cycle, though only enough to get it to build with -Werror enabled (and not -Xlint). Sadly, it's still such a slow process to get patches in that I haven't done more on this. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: hg: jdk8/tl/jdk: 7068616: NIO libraries do not build with javac -Xlint:all, -deprecation -Werror
On 16:47 Thu 28 Jul , Alexandre Boulgakov wrote: On 7/28/2011 4:43 PM, Dr Andrew John Hughes wrote: On 21:44 Thu 28 Jul , jonathan.gibb...@oracle.com wrote: Changeset: 7525866a4046 Author:jjg Date: 2011-07-28 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7525866a4046 7068616: NIO libraries do not build with javac -Xlint:all,-deprecation -Werror Reviewed-by: alanb, chegar Contributed-by: alexandre.boulga...@oracle.com ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/Makefile ! make/java/nio/Makefile ! make/java/sun_nio/Makefile ! make/sun/nio/Makefile ! make/sun/nio/cs/Makefile ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Reflect.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/cs/FastCharsetProvider.java ! src/share/classes/sun/nio/cs/StreamDecoder.java ! src/share/classes/sun/nio/cs/ThreadLocalCoders.java ! src/share/classes/sun/nio/fs/Util.java ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/ch/PendingIoCache.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Is there some (very welcome) focus on fixing these errors at the moment? If so, is this across this board or just the jdk tree (or even parts of the jdk tree)? I'm working on removing javac warnings throughout the security, networking, and core libraries for a summer internship. Oh nice one! Very welcome work. But I guess that's not even the whole jdk tree, right? And definitely not corba? -Sasha I fixed a few a while back during the OpenJDK7 cycle, though only enough to get it to build with -Werror enabled (and not -Xlint). Sadly, it's still such a slow process to get patches in that I haven't done more on this. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Regression in OpenJDK8 Makefiles
On 17:12 Wed 27 Jul , Kelly O'Hair wrote: On Jul 27, 2011, at 4:28 PM, Dr Andrew John Hughes wrote: On 11:58 Wed 27 Jul , Kelly O'Hair wrote: On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote: Hi, Can someone please tell me why: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119 reverted my earlier fix: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0 without any discussion? My apologies, the webrev should have been made public. The correct fix would have been to bump the boot source language/target class versions to 7, not erase the lines altogether. Unfortunately, that did not work with jdk7 as a boot Why was this? I don't understand why anything would fail with javac -source 7 -target 7 over just javac. Basically, we never really know what the BOOT javac will accept. I was referring more to the actual build failure when you tried this. If we're requiring 7 support as a minimum for bootstrapping, surely we know it will support this. I assume that if we use the default for javac, that the BOOT java can run them. This is the assumption that has not always held in my experience. Being explicit means that a newer javac can be used with an older VM. snip... If the BOOT jdk was jdk8, I would want these sources built for jdk8 and run with a jdk8, it should just work. This seems to contradict what you're saying about the files ending up in the image. Why does it matter if they use the minimum supported version? Presumably an OpenJDK8 VM will be able to run 1.7 class files. But an OpenJDK7 VM wouldn't be able to run 1.8 class files if these are the default produced by the bootstrap javac. -kto -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method
On 12:49 Tue 19 Jul , Joe Darcy wrote:
Agreed; I've posted a BlenderRev corresponding to the current patch at:
http://cr.openjdk.java.net/~darcy/7007535.4/BR-7007535.html
What is BlenderRev? Google finds others posted by Oracle employees but
not how to generate them.
Thanks,
-Joe
Mike Duigou wrote:
This looks good to me but I agree with David that it's probably important
to look at the generated javadoc and specdiff output before finalizing.
Mike
On Jul 18 2011, at 00:51 , Joe Darcy wrote:
Peter and David.
Thanks for the careful review; the @throws information still needs its own
{@inheritDoc}; I've uploaded a webrev with this and other corrections:
http://cr.openjdk.java.net/~darcy/7007535.4
More comments interspersed below.
Thanks,
-Joe
Peter Jones wrote:
Hi Joe,
On Jul 15, 2011, at 1:49 AM, David Holmes wrote:
On 14/07/2011 12:21 PM, joe.da...@oracle.com wrote:
Please code review my JDK 8 changes for
7007535: (reflect) Please generalize Constructor and Method
http://cr.openjdk.java.net/~darcy/7007535.3
To summarize the changes, a new superclass is defined to capture the
common
functionality of java.lang.reflect.Method and
java.lang.reflect.Constructor.
That superclass is named Executable along the lines of
javax.lang.model.ExecutableElement, which models constructors and
methods in
the JSR 269 language model.
Both specification and implementation code are shared. To preserve the
right
@since behavior, it is common that in Method/Constructor the javadoc
for a
method will now look like:
/**
* {@inheritDoc}
* @since 1.5
*/
Unless they have fixed/changed javadoc (entirely possible) it used to be
that the above would not cause @throws declarations for unchecked
exceptions to be inherited - you have/had to explicitly repeat them as:
@throws exception-type {@inheritDoc}
Yes, that would seem to be needed for some of the inherited getters of
generics info, which specify unchecked exception types.
Since Executable is being created in JDK 8, it would be incorrect for
methods in that class to have an @since of 1.5; adding the @since in
Method/Constructor preserves the right information.
In Executable.java, getAnnotation and getDeclaredAnnotations do have
@since 1.5-- oversight?
Yes; that was incorrect.
In Constructor.java and Method.java, getExceptionTypes has @since 1.5,
but that method has existed in those classes since 1.1.
Fixed.
In Executable.java:
216 /**
217 * Returns an array of {@code Class} objects that represent the
formal
218 * parameter types, in declaration order, of the method
219 * represented by this {@code Method} object. Returns an array
of length
220 * 0 if the underlying method takes no parameters.
221 *
222 * @return the parameter types for the method this object
223 * represents
At least {@code Method} needs to be generalized, and perhaps all
occurrences of method?
Corrected.
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: JDK 8 code review request for 7007535: (reflect) Please generalize Constructor and Method
On 19:21 Wed 13 Jul , joe.da...@oracle.com wrote:
Hello.
Please code review my JDK 8 changes for
7007535: (reflect) Please generalize Constructor and Method
http://cr.openjdk.java.net/~darcy/7007535.3
To summarize the changes, a new superclass is defined to capture the
common functionality of java.lang.reflect.Method and
java.lang.reflect.Constructor. That superclass is named Executable
along the lines of javax.lang.model.ExecutableElement, which models
constructors and methods in the JSR 269 language model.
Both specification and implementation code are shared. To preserve the
right @since behavior, it is common that in Method/Constructor the
javadoc for a method will now look like:
/**
* {@inheritDoc}
* @since 1.5
*/
Since Executable is being created in JDK 8, it would be incorrect for
methods in that class to have an @since of 1.5; adding the @since in
Method/Constructor preserves the right information.
I assume this is why we have some methods in the subclass that just
call the superclass.
It would have been natural to also move common fields to Executable;
however, HotSpot treats the Constructor and Method type specially and
relies on the existing field ordering. Since altering the field layout
would require coordinated HotSpot changes, I'm opting to not perform
such a change right now. At least one abstract accessor method is
declared in Executable to still allow code sharing even though the
required field is not present. In other cases, package private instance
methods on Executable are passed the needed state from overridden public
methods in Method/Constructor.
All java/lang/reflect regression tests pass on a full build with these
changes.
The changes look good (though hard to read in places due to additional
whitespace changes mixed in). Nice to see these two finally being grouped
together.
Thanks,
-Joe
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Heads up, new jaxp source drop
On 07:26 Fri 20 May , Kelly O'Hair wrote: As soon as we figure out how to restrict changes to particular source files and protect them from intentional or accidental edits. I just have not had the time to deal with this kind of change. I thought that's what our existing review process was for? -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Heads up, new jaxp source drop
On 17:53 Thu 19 May , Kelly O'Hair wrote: Heads up. The jdk7/tl forest has a new jaxp source drop dependency. 7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bdf77cbd9958 The new source drop bundle is called: jaxp145_01.zip So if you have your own ALT_DROPS_DIR cache, you need to add this file: http://download.java.net/jaxp/1.4.5/jaxp145_01.zip The changes involve minor source copyright/license corrections only. -kto Can we not just have the code back in the repository rather than all these tarballs with unknown changes? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Reviewer needed - fix for regression test LastErrorString
On 5 May 2011 20:45, Alan Bateman alan.bate...@oracle.com wrote: Pavel Tisnovsky wrote: Hi all, I'd like to push fix for regression test java/io/IOException/LastErrorString.java to OpenJDK7 and OpenJDK6. This fix ensures that no system-important files can be erased and/or rewritten by this test even if root started JTreg. Fixed test also tries all various combinations of file attributes. Webrev is available at: http://cr.openjdk.java.net/~ptisnovs/jtreg-jdk-test-LastErrorString-fix/ Can anybody please review it? Thank you in advance, Pavel Tisnovsky I agree that this test should be fixed but I don't know about jdk7 as it's being stabilized now and only critical changes are allowed. Pavel submitted the patch for OpenJDK7, not jdk7. From a quick glance it looks like you've added the @test tag to both files so I assume jtreg will want to run it twice. Have you tried the test on Windows? I assume it will at least fail with Unrecognized system if run with Cygwin. In general it's best to avoid scripts if you can - in this case have you considered created an unreadable and unwriteable file in java instead? We don't build on Windows. -Alan. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Need reviewers: Update of jaxp 1.4.5 source drop bundle
On 07/04/2011, Dalibor Topic dalibor.to...@oracle.com wrote: On 3/3/11 3:01 AM, Dr Andrew John Hughes wrote: How do we know what the actual changes are between these tarballs? Is there some JAXP repository somewhere these are derived from, with appropriate tagging? Afaik, the JAXP API and implementation are supplied by the upstream JAXP developers in the GlassFish JAXP project, i.e. http://jaxp.java.net/ . The source code repository is at http://java.net/projects/jaxp-sources/sources/svn/show http://java.net/projects/jaxp-sources/sources/svn/show/tags shows no tags in the last six months. What does this tarball correspond to? cheers, dalibor topic -- -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Trivial review: 7032364 Add jvm.cfg file for ARM and PPC architectures
On 30 March 2011 08:09, David Holmes david.hol...@oracle.com wrote: http://cr.openjdk.java.net/~dholmes/7032364/webrev/ More pieces to support SE Embedded. David When are these files installed? Will they interfere with Zero/Shark installs on ARM PPC? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Need reviewers: Update of jaxp 1.4.5 source drop bundle
On 2 March 2011 19:48, Alan Bateman alan.bate...@oracle.com wrote: Kelly O'Hair wrote: Need reviewer for change in jaxp source drop bundle 7023289: jaxp 1.4.5 development jdk7 2nd integration http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-145dev1/webrev/ Joe or someone from the JAXP team may want to comment on the specific changes in this new source bundle. -kto The update to jaxp.properties looks okay to me. -Alan The problem with this drop tarball method is the jaxp.properties update is all you can see. How do we know what the actual changes are between these tarballs? Is there some JAXP repository somewhere these are derived from, with appropriate tagging? When we had the source code in the repository, we could at least see what changes were being made. Having to track down and patch some JAXP issues recently has been a nightmare with this drop tarball system. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Zlib level in JDK7
On 22 February 2011 17:26, Phil Race philip.r...@oracle.com wrote: On 2/20/2011 9:39 AM, Dr Andrew John Hughes wrote: On 15 February 2011 20:23, Phil Racephilip.r...@oracle.com wrote: On 2/15/2011 6:07 AM, Dr Andrew John Hughes wrote: Yes, IcedTea uses system libraries for everything bar LCMS, where local changes in OpenJDK mean we are still forced to use the in-tree version. There hasn't been any success upstreaming these changes, though I haven't looked at LCMS 2.x. LittleCMS 1.x didn't provide the support necessary to pass JCK. So we talked to the LittleCMS maintainer and he added the necessary APIs in 2.0 JDK 7 has had LittleCMS 2.0 for almost 6 months now and that is included without any code modifications, so I think it should now be possible to use a system library, although we didn't do the work to actually enable that, so its built into a JDK library which has the littlecms code and the glue code. We need to provide the ability to separate these. When we pushed LCMS 2.0, I asked for a bug to be filed to remember to do this work but I can't find it in the database. I'll ask for that to be filed if it wasn't already. NB It didn't seem super-urgent since we pulled in LCMS 2.0 relatively soon after its release we thought shipping distros weren't likely to have the library upgrade anyway, but that's probably changing. -phil. Hi Phil, Thanks for making me aware of this. I briefly glanced at some for the release notes for LCMS 2 when it was released, and saw something that may support the missing functionality, but never had chance to look in detail. I've also not had chance to look at OpenJDK 7 recently, so it's great to hear that support has already gone in. Do you have any idea as to whether this would be safe to backport to OpenJDK 6? I presume it doesn't alter any public API. It ought to be OK. If someone else wants to take on the work that is :-) Consider it on my TODO list ;-) I've not seen any use of OpenJDK 7 by distros as yet. We've managed with the other libraries without in-tree support by using local patching. There's a big libraries patch in IcedTea that would be nice to integrate but it would need considerable work to do optional system linking rather than the current brute force of deleting the in-tree version and always linking. There's also no TCK for 7 yet, which is I believe what caught many of the issues with missing LCMS support before. I don't know how distros would want to present/package the 7 EA builds so I'm not too surprised they aren't common. We believe LCMS 2.0 should pass JCK, but I don't know if a full JCK run has been performed against a fully open 7 build since it went in. A 6-open backport would find any problems there. I wasn't aware there was a JCK for 7 yet. At least, not one under the same terms as the one used for OpenJDK6. I did a quick survey of distro support for LCMS 2. It's in Gentoo (which is what made me aware of it), but Ubuntu, Debian and Fedora all seem to still be on the 1.x series. So it doesn't seem to be changing yet. Maybe OpenJDK could be the kick they need to support it? ;-) yep. -phil. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: sun.cpu.isalist
2011/2/14 Dmytro Sheyko dmytro_she...@hotmail.com: Hi, I can see that such system property as sun.cpu.isalist is not set on Linux, but it is set on Solaris and Windows. What is the purpose of this property and shouldn't it be set on Linux as well? Thanks, Dmytro On Solaris, it includes the results of a call to sysinfo(SA_ISALIST, list, sizeof(list)): http://www.opensolarisforum.org/man/man2/sysinfo.html SI_ISALIST Copy into the array pointed to by buf the names of the variant instruction set architectures executable on the current system. The names are space-separated and are ordered in the sense of best performance. That is, earlier-named instruction sets might contain more instructions than later-named instruction sets; a program that is compiled for an earlier-named instruction set will most likely run faster on this machine than the same program compiled for a later-named instruction set. Programs compiled for an instruction set that does not appear in the list will most likely experience performance degradation or not run at all on this machine. The instruction set names known to the system are listed in isal- ist(5); these names might not match predefined names or compiler options in the C language compilation system. This command is obsolete and might be removed in a future release. See getisax(2) and the Linker and Libraries Guide for a better way to handle instruction set extensions. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Fix for JDK Double.parseDouble infinite loop
On 7 February 2011 21:48, Mark Wielaard m...@klomp.org wrote: On Wed, February 2, 2011 17:16, Andrew Haley wrote: The post on http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ This is hitting more and more media. e.g. http://www.channelregister.co.uk/2011/02/07/java_denial_of_service_bug/ Since it seems to be a pretty serious security/denial of service attack maybe we could at least get the fix into IcedTea6 and warn the various distros they should apply it asap for their users? Cheers, Mark I'll add it tomorrow. I expect new IcedTea6 releases soon to coincide with the Oracle SSR; see http://www.oracle.com/technetwork/topics/security/alerts-086861.html -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock
On 16 December 2010 16:39, Neil Richards neil.richa...@ngmr.net wrote: On 13 December 2010 20:04, Neil Richards neil.richa...@ngmr.net wrote: On 13 December 2010 18:46, Alan Bateman alan.bate...@oracle.com wrote: I haven't looked at your patch in detail yet but I suspect there may be similar issues in other places (like j.u.Hashtable) once you are done with Vector. You are correct, there is a similar issue in Hashtable. I'm currently in the process of working up another fix and testcase for that, which I hope to submit separately shortly. I now notice that there isn't a bug in Java bug database exactly for the problem in Hashtable - though it's obviously related to 6934356, and to 4741471 (which removed writeObject() synchronization from the unsynchronized collection classes). (As in Vector, the problem in Hashtable has existed since 1.4). In this case, can I raise an entry in the OpenJDK bug database for the problem in Hashtable, or do I need to get it raised in the Java bug database? Commits to OpenJDK still require a bugs.sun.com ID. There was a plan nearly two years ago to actually make the OpenJDK bugzilla more useful (see http://openjdk.java.net/groups/web/bugzilla.html) but I've not heard of any progress on this. While we're still stuck with the bugs.sun.com system, It's easiest to just ask one of the Oracle developers to allocate a bug ID. They seem to be able to do so fairly instantaneously whereas it takes a lot longer externally. http://openjdk.java.net/guide/producingChangeset.html tells you how to provide an appropriate Mercurial changeset for commit. Commit comments are in a rigid format controlled by a proprietary jcheck script running on the OpenJDK servers and this will reject commit matches that don't match the format or have a duplicate bug IDs as well as patches which don't meet the whitespace formatting requirements (and probably numerous other checks that we don't know about). Any guidance gratefully received, Thanks, Neil PS: What is the standard way of referring to a bug from one system or the other? Or are the bug numbers from each system sufficiently far apart to avoid ambiguity that way? -- Unless stated above: Work email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Improved Java Collection APIs
On 19 November 2010 15:49, John Platts john_pla...@hotmail.com wrote: Here are improvements that I really want to see to Java Collection APIs: - Addition of an equality comparator interface. - An wrapper that wraps a java.util.Comparator as a equality comparator. - Map and set classes that allow an equality comparator to be used instead of the equals() method or identity comparisons - New map and set interfaces that behave like the existing java.util.Map and java.util.Set interfaces. Unlike the contract of the java.util.Map and java.util.Set interfaces, the contract of the new map and set interfaces will not require that o1 be considered to be equal to o2 when o1 != o2 and o1.equals(o2) are both true. The new map and set interfaces will still require that o1 be considered equal to o2 whenever o1 == o2 is true. - New collection interfaces which define versions of search and removal operations that take an additional equality comparator argument. This enables search and removal operations to use an equality comparator to determine equality instead of relying on the equals method, an identity comparison, or the java.util.Comparator.compare method. - Additional concurrent collection classes. Some of these classes will require synchronized modification, while supporting thread-safe unsynchronized access and concurrent iteration. - Support for collections synchronized on a read-write lock. - Addition of methods that iterates through the collection and invokes a callback. This is useful in cases where the callback object can be pre-allocated, since iteration using a java.util.Iterator object usually requires an iterator to be allocated each time an iteration takes place. Feel free to post patches to add these features. Then they can be reviewed and maybe added to the JDK. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: 6989466: Miscellaneous compiler warnings in java/lang, java/util, java/io, sun/misc native code
On 6 October 2010 21:56, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: On 6 October 2010 21:37, Alan Bateman alan.bate...@oracle.com wrote: This batch eliminates a bunch of compiler warnings from the native code: http://cr.openjdk.java.net/~alanb/6989466/webrev/ It also fixes an incorrect usage of memset found along the way. -Alan. This looks good from reading the patch. I'll give it a test build. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 It builds and there seem to be notably less warnings. The first I see now is: ../../../src/solaris/bin/java_md.c: In function 'LocateJRE': ../../../src/solaris/bin/java_md.c:871:19: warning: cast from pointer to integer of different size ../../../src/solaris/bin/java_md.c: In function 'ContinueInNewThread0': ../../../src/solaris/bin/java_md.c:1084:14: warning: cast from pointer to integer of different size and then some in the net code. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: jvm load too many classes
On 31 July 2010 21:31, Rémi Forax fo...@univ-mlv.fr wrote: Le 30/07/2010 21:59, Mandy Chung a écrit : Osvaldo Doederlein wrote: I wonder if these numbers have some variation per platform? Yes, there are some platform-dependent classes and so some loaded classes are different on different platform. For me (on Windows; 32-bit JDKs), the results of this test (java -verbose:class | grep Loaded | wc -l) are: 1.5.0_22: 239 1.6.0_21: 274 1.7.0-ea-b103: 403 I ran the helloworld. The number of loaded classes running different jdk versions are fairly close. What test case did you use? $ grep Loaded hw.verbose.jdk5u22 | wc -l 303 $ grep Loaded hw.verbose.jdk6u21 | wc -l 323 $ grep Loaded hw.verbose.jdk7 | wc -l 329 There is a big diff (at least on linux) if you just try to print the help of the VM, i.e pass no argument. jdk1.6.0_21: 274 classes jdk1.7.0b103: 364 classes I join the diff. Some classes of java.text.*, java.util.ResourceBundle* and some classes related to locale and currency are loaded eagerly. Rémi The diff from 1.5 to 1.6 is not bad, but JDK7 seems right now to be a heavy regression... FWIW for such a simple test. For one thing, these core-boot classes all come off the CDS file so their classloading effort is relatively very small, and the delta will certainly be much smaller for even the smallest real-world app. Right. -verbose:class prints out all loaded classes regardless of coming from CDS archive or not. The number of loaded classes is one metric to the startup while class loading time + clinit time are other important metrics. So these loaded classes has small impact to the startup time especially with CDS is enabled. Mandy A+ Osvaldo 2010/7/30 Mandy Chung mandy.ch...@oracle.com: Yongqiang Yang wrote: hi, I just type command java under openjdk1.6, then the jvm will load 308 classes, including java/launcher/LauncherHelp, java/util/ResourceBundle, java/util/Currency, java/util/Locale, java/net/URL When I use jdk1.5, the jvm just load about 180 classes, not including the classes above. Could someone figure out something wrong? New features and bug fixes in a new release could lead to more classes get loaded at startup. We have done some work to lazily load classes if appropriate (see CR 6798873: Reduce the number of classes loaded and class dependencies). Mandy Is the jdk7 here an OpenJDK build or an Oracle-provided binary? There's likely to be a difference between the two, due to the replacement of proprietary classes (e.g. Pisces renderer, lcms freetype code in OpenJDK which isn't used by the proprietary version). -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
