Thanks Dawid! So my take-away is that this is just pilot error on my part,
not something intrinsic to the code.
I don't know enough about the code to say for sure, but to me that
FaultyIndexInput's count field should be reset before each test
(shouldn't propagate from test to test, effectively
Hi Erick,
I filed LUCENE-5916 and attached a patch. Check it out and commit it
in -- I would like you to understand on a concrete example why the
patched code will work and the previous code didn't. :)
Dawid
On Mon, Sep 1, 2014 at 8:24 AM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
Just curious, is there any case where you might genuinely need non-final
static members in a test class? I guess it wouldn't catch all cases, but
something in setup/teardown which bans that using introspection might catch
at least the obvious cases..
On 1 Sep 2014 14:01, Dawid Weiss
Awww, man, do I have to? I didn't write the test, I just accidentally
tripped it by messing up the tests command ;)..
Seriously, thanks! It's always a Good Thing to dive a little deeper,
I'll try to get my head around it today.
Erick
On Mon, Sep 1, 2014 at 6:00 AM, Dawid Weiss
Just curious, is there any case where you might genuinely need non-final
static members in a test class?
To be honest you shouldn't have any static initializers at all,
including final fields (unless they're really immutable, simple data
types). The reason for this is that static initializers
Awww, man, do I have to? I didn't write the test, I just accidentally
tripped it by messing up the tests command ;)..
Stop moaning, soldier! :)
Seriously, thanks! It's always a Good Thing to dive a little deeper,
I'll try to get my head around it today.
You don't *have to*, but it wouldn't
Dawid:
Sorry, I didn't make it clear that I intended to commit it to both trunk
and 4.x, running full test suite now.
I looked it over and I see what you were talking about. I hadn't looked
before, my error invoking the tests and producing this error was getting in
the way of my _real_ test and
No big deal, Erick. Thanks for catching this, it wasn't a trivial issue!
Dawid
On Mon, Sep 1, 2014 at 10:16 PM, Erick Erickson erickerick...@gmail.com wrote:
Dawid:
Sorry, I didn't make it clear that I intended to commit it to both trunk and
4.x, running full test suite now.
I looked it
On Mon, Sep 1, 2014 at 8:54 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl
wrote:
To be honest you shouldn't have any static initializers at all,
including final fields (unless they're really immutable, simple data
types). The reason for this is that static initializers (including
those for
Yes. It's hard to ban it completely; unless it's a constant primitive
an assignment to a field will be moved to a static initializer. I
would personally disallow it, but I can also feel the pain others must
feel when they're forced to @BeforeClass every single thing, however
trivial...
Dawid
On
It's because the exception is triggered in a static class
FaultyIndexInput (initialized in a static context
TestFieldsReader#beforeClass). When you ask for -Dtests.iters, only
the tests (methods) are duplicated, the static context remains the
same. So the count variable in FaultyIndexInput is
Thanks Dawid! So my take-away is that this is just pilot error on my part,
not something intrinsic to the code.
Erick
On Sun, Aug 31, 2014 at 12:46 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl
wrote:
It's because the exception is triggered in a static class
FaultyIndexInput (initialized in
I'm seeing the fairly easily-reproducible error below on trunk.
Unfortunately it doesn't reproduce with the seed. I'm wondering if anyone
has an inkling what's going on here?
I did manage to notice that I screwed up the command I was _intending_ and
actually issued the command below, although I
13 matches
Mail list logo
