RFR: jsr166 jdk9 integration wave 12
jbluettduncan at gmail.com
Thu Oct 20 13:04:41 UTC 2016
Ah, I see. Thanks for answering my questions Martin.
Sounds like there's no real benefit then to using guava-testlib in this
changeset instead of CollectionTest. And even if the benefit of using it
was considered to be high enough in the future, it would probably need its
own JSR, since I presume it would be applicable to a number of places in
the jdk, making it a humongous change.
Overall, it seems sensible to wait until e.g. JUnit 5 develops a worthwhile
solution to the dynamic test generation problem, at which point we could
then consider it for writing exhaustive tests for the jdk collections.
On 20 October 2016 at 04:45, Martin Buchholz <martinrb at google.com> wrote:
> On Wed, Oct 19, 2016 at 4:40 PM, Jonathan Bluett-Duncan <
> jbluettduncan at gmail.com> wrote:
>> Hi Martin,
>> By collections infrastructure, do you mean something like the collection
>> testers in guava-testlib?
>> If so, I agree that JUnit 5's dynamic tests look promising for
>> implementing such an infrastructure. I admit I don't have all the context
>> here, but would using guava-testlib in the meantime be a viable medium- or
>> short-term solution? Or would its dependence on JUnit 3/4 make switching
>> impractical? Or, perhaps, has development into CollectionTest gone so far
>> that, for that reason instead, it would be impractical until switch, at
>> least until something superior using e.g. JUnit 5's dynamic tests is made?
> I'm embarrassed to say I'm not familiar enough with guava's testlib.
> Guava does have generic collection oriented tests, and even runs them on
> jdk classes. (Someone on the jdk quality team should be running the guava
> tests using development jdks!). I'm not familiar enough with the tools to
> work on this myself, but I encourage someone who is to do that.
> I see that guava testlib does have:
> and that the infrastructure there is vaguely similar to what I ended up
> doing. JDK version skew is a problem, because openjdk development is
> focused on jdk9, while guava is still trying to digest jdk8.
More information about the core-libs-dev