Answer requested!!! was: Re: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException (original) (raw)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Fri Dec 2 05:54:25 UTC 2011

Am 01.12.2011 16:12, schrieb Sean Mullan:

On 11/22/2011 11:45 PM, Sebastian Sickelmann wrote:

It's been a long time ago. Had someone had the time to think about this:

Am 29.10.2011 13:17, schrieb Sebastian Sickelmann: Sorry i linked the wrong webrev for Solution 3.

Am 27.10.2011 16:50, schrieb Sebastian Sickelmann: Some time ago (see below) i ask what would be the right solution to refactor exception initialization to?

Solution 1: Disallow calls to initCause after creation, if there was an exception-cause-functionality in this class before it was introduced to Throwable. Solution 2: Disallow calls to initCause after creation with in ctor which has a cause parameter. Solution 3: Disallow calls to initCause after creation, if and only if there are ctors that allows us to specify the cause at creation time.

If i investigated it right:: * Solution 1 is used by in the Exceptions in core-libs. * Exceptions that had no cause-chain prior to Throwable's-cause-chain uses Solution 2. * Personally i found Solution 3 is the most intuitive for the users javax/xml/security- Exceptions had cause-chaining prio to Throwable introduces them. jx/x/s-Exceptions are actually not refactored to solution 2 like the other exceptions in core-libs that had cause-chaining prior to Throwable. Before my change-request for jx/x/s-Exceptions i changed some in core-libs (InternalError and VirtualMachineError) to provide exception-chaining. These use Solution 2 like all other exceptions that provided exception-chaining after it where introduced by Throwable. My personal view of this is that i think it may be valueable to change all to Solution 3 or at least merge all Solutions to one Solution(maybe Solution 2) and get rid of Solution 1. I created a webrev[0] for jx/x/s-Exceptions that implements Solution 2 (this can be used for all those Exceptions that used Solution 1 too). webrev[0] looks like it is using Solution 1. Looking at the diffs for KeySelectorException, the ctors that don't supply cause parameters are still forbidden from subsequently calling initCause. >>> The problem with Solution 3 is that bahavoir compatibility is not given >>> and some code may break. Can you please explain what you think the compatibility issues are in more detail? I would also like to see the diffs for solution 2 before I give you my opinion. --Sean And I created a webrev[1] for jx/x/s-Exceptions that implement Solution 3 for comparision. [0] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/70118044/index.html

[1] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/70118046/index.html The 3 solutions I mentioned are solutions that can be commonly discussed for a solution choosing for all Exceptions in OpenJDK.

Webrev[0] shows solution 1 for jx/x/s-Exceptions. From the users perspective (outside view) solution 1 and 3 are completely similar.

Solution 2 are used widely in jdk codebase in Exceptions that had no chaining before it was introduced globally throught java/lang/Throwable. An Example for Solution2 is java/lang/RuntimeException. An webrev that show this jx/x/s-Exception is webrev[1]

Solution 3 is actually not used by any Exception in JDK (or I haven't found them)

The problem i see is that we now have 2 ways exception-chaining might work.

We should only support one solution. If we introduce the commonly used exception-ctors for every class (which i actually try) we can switch over to an solutions that is consistent for the user. I think every Exception that gives the user the choice to use exception-chaining via a ctor-variant that supports chaining should disallow changes of the exception-chain via initCause even when the exception is created with an ctor that doesn't had chaining parameters. This is what i call Solution 3.

Unfortunately Solution 3 introduces an behavior-incompatibility. In JDK every think is fine and we can make all the changes that are needed to do (replace all initCause calls with the right ctor-choice). But in the outside world there maybe users that rely on the feature of plumbing up the exception chain after creation. Those will get an Exception when they call initCause. Maybe we can warn them to not use initCause anymore through marking initCause deprecated. And switch over to solution 3 over several releases (maybe OpenJDK9 or 10)

Sorry for the misleading webrev-mappings in my previous mails. Hope to cleared thinks up now (with my wired english ;-) ).

-- Sebastian

[0] Solution 1 http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html [1] Solution 2 http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_6/index.html

More information about the core-libs-dev mailing list