Re: Re: JUnit 4.12-beta-1 is released

On Mon, Aug 11, 2014 at 11:28 PM, Chris [email protected] [junit] <
[email protected]> wrote:

>
> Hi,
>
> to some extent, I think it was the fault of our code using it, which seems
> overly restrictive:
> if (<something> &&
> exception.getClass().equals(org.junit.internal.AssumptionViolatedException.class))
>

I think you could use Class.isAssignableFrom(Class) instead, but if you
could give more context, I could give a better suggestion. More context
would also allow me to update the release notes to warn about this.

I believe we introduced the external AssumptionViolatedException so that
projects would not have to import internal classes. If introducing the
external AssumptionViolatedException causes a lot of problems, then maybe
we need to just accept that AssumptionViolatedException should not have
been internal but we can't do anything about it.

>
>
> By the way, the removal of "exit()" from JUnitSystem was a bit annoying as
> I ended having to copy in MainRunner (from your tests) into our project as
> we're also testing some System.exit conditions.
>

I filed https://github.com/junit-team/junit/issues/975 to track this.

On the one hand, it would be nice if we were free to make
non-backwards-compatible changes to internal classes. On the other hand, we
have had some classes that were internal when they shouldn't have been. In
this particular case, it would be trivial to add the method back (and the
method is trivial to maintain going forward), so IMHO we should add it back.


>  I can see why it is nicer to remove a test-only API from the source part,
> but when the cost is 290 lines of MainRunner to save JUnitSystem subclasses
> from writing a 3-line method, then I'm not so sure it is a gain. But I can
> live with it.
>

JUnitSystem is an internal class. If you believe we should have an external
version, could you please file a feature request and outline your use case?

-- Kevin