Re: Request for review: Rework cause-chaining in Exceptions was:JDK 8 code review request for 6380161 (reflect) Exception from newInstance() not chained to cause.
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. 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. Cheers, -Joe
Re: Request for review: Rework cause-chaining in Exceptions was:JDK 8 code review request for 6380161 (reflect) Exception from newInstance() not chained to cause.
Sebastian Sickelmann wrote: It would be great to have a webrev for them. I rebased my patches on dd218ad64d5c of http://hg.openjdk.java.net/jdk8/tl/jdk/ The patches are here: https://bugs.openjdk.java.net/attachment.cgi?id=236 (diff view: https://bugs.openjdk.java.net/attachment.cgi?id=236&action=diff) https://bugs.openjdk.java.net/attachment.cgi?id=237 (diff view: https://bugs.openjdk.java.net/attachment.cgi?id=237&action=diff) https://bugs.openjdk.java.net/attachment.cgi?id=238 (diff view: https://bugs.openjdk.java.net/attachment.cgi?id=238&action=diff) Is there a way to create webrev on my linux box (ubuntu)? Is there a good description for it? I have another(RuntimeException) patch here: https://bugs.openjdk.java.net/attachment.cgi?id=239 (diff view: https://bugs.openjdk.java.net/attachment.cgi?id=239&action=diff) Maybe i can create a webrev on my own for this. -- Sebastian If you are on Linux then webrev is easy to use. It's located in the top-level repo in the make/scripts directory, just do webrev.ksh -N to generate a webrev from the files that "hg status" indicates has changed. The output will go to a webrev directory that you can publish on any http servers. -Alan
Re: Request for review: Rework cause-chaining in Exceptions was:JDK 8 code review request for 6380161 (reflect) Exception from newInstance() not chained to cause.
Am 16.08.2011 13:35, schrieb Alan Bateman: 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? I don't have cycles but I can generate a webrev (essentially browsable diffs) for you that would make this easy to review. Do you mind re-basing your patches so that they can be applied to jdk8/tl/jdk? I think Sasha got in before you and has already changesd several places to use multi-catch that are in your patches too. -Alan. It would be great to have a webrev for them. I rebased my patches on dd218ad64d5c of http://hg.openjdk.java.net/jdk8/tl/jdk/ The patches are here: https://bugs.openjdk.java.net/attachment.cgi?id=236 (diff view: https://bugs.openjdk.java.net/attachment.cgi?id=236&action=diff) https://bugs.openjdk.java.net/attachment.cgi?id=237 (diff view: https://bugs.openjdk.java.net/attachment.cgi?id=237&action=diff) https://bugs.openjdk.java.net/attachment.cgi?id=238 (diff view: https://bugs.openjdk.java.net/attachment.cgi?id=238&action=diff) Is there a way to create webrev on my linux box (ubuntu)? Is there a good description for it? I have another(RuntimeException) patch here: https://bugs.openjdk.java.net/attachment.cgi?id=239 (diff view: https://bugs.openjdk.java.net/attachment.cgi?id=239&action=diff) Maybe i can create a webrev on my own for this. -- Sebastian
Second try... Readable Collections Interfaces.
(This bounced or got hung up the first time I sent it.)
Hi Guys,
I work on Gosu, a JDK-based language, and I was talking w/ Charles Nutter
and Ola Bini today (ed: now last week) at OSCON, and a general idea that
I've been kicking around for a long time came up. They both didn't think it
was crazy, so I figured I'd bounce it off this mailing list. Apologies if
this has been discussed before.
Here's the problem I have: I'd like to return my mutable collections to
consumers as an immutable collection.
Now, I know I can wrap my collections in immutable versions, but that isn't
really what I want: I'm less concerned that the implementation is actually
immutable, but I'd like the consumer of my collections to *know* statically
that they aren't supposed to mutate the collection I'm handing them. Tt a
practical level, the wrapping approach necessitates me either wrapping the
mutable collection I've got in my class every time I return it or to
maintain a second reference to the wrapped class, both of which are ugly.
So, what I think I want is an interface like, for example, ReadableList,
which has only the readable methods on List and none of the mutators. And,
presumably, that would extend a ReadableCollection, which would have only
the readable methods on Collection, and so on. (One point that Josh Bloch
made was that Iterable breaks this, but I *think* you could introduce a
ReadableIterator interface without the remove() method and use covariance
return types in the mutable collections to make it all work out.) I could
then return my mutable Lists as this interface, and send a strong signal to
the caller that they shouldn't mutate them. (If they downcast... hey, we
are all adults here, right?)
Some sample code:
class MyClass {
List someNames = ...
public ReadableList getSomeNames() {
return someNames;
}
}
So callers of MyClass#getSomeNames() will know that I don't intend for them
to mutate the list. And, of course, it would be nice if these interfaces
worked properly with the for() statement, etc.
As a side note, I like the name ReadableList vs. the more obvious
ImmutableList, since java.util.List would extend this interface and it isn't
an ImmutableList.
Anyway, this is obviously a very rough idea, but I'd like to hear what
people think and what problems might come up when implementing it.
Thanks,
Carson
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: Request for review: Rework cause-chaining in Exceptions was:JDK 8 code review request for 6380161 (reflect) Exception from newInstance() not chained to cause.
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? I don't have cycles but I can generate a webrev (essentially browsable diffs) for you that would make this easy to review. Do you mind re-basing your patches so that they can be applied to jdk8/tl/jdk? I think Sasha got in before you and has already changesd several places to use multi-catch that are in your patches too. -Alan.
