bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject reworking liskov impl
Date Mon, 05 Nov 2018 09:24:49 GMT
Hello guys,

I spent some time in the Liskov code,
mainly org.apache.bval.jsr.metadata.Liskov.StrengtheningIssue and I have to
admit I have no idea how we can comply to the Liskov principle "clealy" (ie
respecting the spec and the user habits) with this one in current state.

The rational is https://issues.apache.org/jira/browse/BVAL-167 which makes
sense IMHO.

My main blocker is all the abstraction we now have in that code prevents to
compare methods directly easily without that kind of code:

private static final Function<Meta<?>, Method> METHOD_EXTRACTOR = meta -> {
    Meta<?> current = meta;
    Method method = null;
    while (current != null && method == null) {
        final AnnotatedElement host = current.getHost();
        if (Method.class.isInstance(host)) {
            method = Method.class.cast(host);
        } else {
            current = current.getParent();
        }
    }
    return method;
};

+ we need to take into account method pair by pair and not just linearly
cause inheritance can be faked in java (as in syncope in the ticket) so I
guess we must be a bit less elegant but way more tolerant in our impl.

So i'd be tempted to think we should rewrite the validation rules closer to
the spec (doing the method x method O(n2) loop - than trying to be continue
to stay generic and linear - if you find a way to express the validation
rules with current code I'm happy to revise my opinion but didn't find a
reliable solution.

Wdyt? Did I miss anything?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message