: I agree that having to write "MatcherAssert.assertThat" each time is
: tedious and makes my code ugly. So finally I try to avoid this nice
: construction. Not satisfying.
This right there is the "twist" of the knife in my heart.
The 2 lines of code below are both very similar in terms of ease of
writing/reading, but the one that produces a message that might actually
be helpful in the event that it fails is the one we actively make harder
for devs to write...
assertTrue( obj instanceof Foo );
assertThat( obj, instanceOf(Foo.class) );
...guess which one is in our code base 14 times, and which one is in our
code base 700+ times?
: > Basically it removes a ton of deprecated usages. If/when we upgrade Junit
: > we should hopefully have much less to do.
It seems disingenuous for us, as a project, to say "We care so much about
avoiding deprecated methods we're going to make it harder for contributers
to write good unit tests" when at the sametime we actively prevent the
compiler from printing warnings about deprecations...
$ grep deprecation gradle/java/javac.gradle
"-Xlint:-deprecation",
...but let's go with it, and assume forbidden-api is just a stop gap
measure until we eventually manage to eliminate all deprecated code usage
from the code base...
: > It came in as part of
: > https://github.com/apache/solr/pull/947#issuecomment-1279651282
: >
: > I linked to one of the comments there since this was discussed on the PR.
I'm going to highlight the 2 key sentence in this comment...
>> So we can't override assertThat in SolrTestCase since its
>> static and comes from Assert which is what LuceneTestCase
>> derives from. ForbiddenApis correctly complains that we
>> can't just override the static method and instead knows
>> that Assert#assertThat is still being called.
Unless I'm missing something major...
1. The first sentence is true, but inaccurate.
2. The second sentence is false, but accurate. :)
1) java does not allow overloading -- in the strict polymorphic sense --
of static methods, but that is completley irelevant to us. What matters
is that java *does* allow static method "hiding" -- (re)defining a static
method using the same signature as a static method provided by your based
class, ensuring that other code in your class (or subclasses) that attempt
to invoke that method signature will get your version of it. (unless the
use the fully qualified name of your parent class) ...
https://docs.oracle.com/javase/tutorial/java/IandI/override.html
2) AFAICT Forbidden APIs *incorrectly* complains that you are calling a
forbidden method if you "hide" a forbidden static method by defining a new
impl of that method signature in your code -- even though the new impl is
what actaully gets called...
https://github.com/policeman-tools/forbidden-apis/issues/237
...so if/when forbidden-apis #237 can be resolved, we can have the best of
both worlds.
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
