Hi David,

just asked a question cause I think we missed some double exception
wrapping we can avoid so if you can clarify that but all issues got fixed
for me except that question. Thanks a lot for the hard work!

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>


Le ven. 13 mai 2022 à 20:18, David Blevins <[email protected]> a
écrit :

> > On May 13, 2022, at 9:22 AM, Romain Manni-Bucau <[email protected]>
> wrote:
> >
> > Le ven. 13 mai 2022 à 16:57, David Blevins <[email protected]> a
> > écrit :
> >
> >>> On May 12, 2022, at 11:17 PM, Romain Manni-Bucau <
> [email protected]>
> >> wrote:
> >>>
> >>> Hi David,
> >>>
> >>> Just had a look and it seems it is mainly about ensuring we'll move
> >> master
> >>> to 1.3.0-SNAPSHOT (can need a thread at least for visibility)
> >>
> >> Good idea.  Created a thread on 1.3 with the motivations so that is
> >> documented on list and we can get feedback if any.
> >>
> >>> and cleaning
> >>> up ExceptionMessages (simpleName impl) then we can move forward I
> think.
> >>
> >> Is there any chance for some flexibility on that method?
> >>
> >> My big concern is that if I push back we'll find ourselves in a debate
> on
> >> calling class.getSimpleName() vs using string manipulation and that will
> >> come at the expense of time we could spend collaborating on more
> >> fun/impactful things.  We're likely another 3 or 4 PRs before we could
> get
> >> the items in the reports addressed and 1.3 out the door.
> >>
> >
> > Im fine with current code if there is some enforcement (tests) we dont
> > support any other Type cases - thinking it is harder than simplifying the
> > impl i proposed it but while we have something simple to grok for all
> > supported types i m actually fine.
>
> I really appreciate that.  Class names can get quite strange, hence my
> reticence with any string manipulation approach.
>
> I've updated the PR to handle WildcardType and GenericArrayType and added
> more explicit tests.  As before there is a fallback of calling
> getTypeName() in case we see something unknown.
>
> Let me know if there's a common Type derivative I should add.
>
>
> -David
>
>

Reply via email to