Raw type warnings? In my experience, barely anyone even notices them let alone fixes them. :/
On 4 June 2017 at 16:57, Ralph Goers <[email protected]> wrote: > It is reasonable but I really dislike having to tell users they need to > change their code to get rid of the new warnings. > > Ralph > > > On Jun 4, 2017, at 9:48 AM, Gary Gregory <[email protected]> wrote: > > > > Hi, > > > > I was about to merger the branch GenericMapMessageSimple when I realized > > something... Right now, all the code compiles and runs cleanly and the > > Clirr check passes. > > > > But... > > > > Because of the new implementation declares MapMessage with generics, we > do > > get compiler warnings about MapMessage not being used with generics. > > > > What I propose is that we declare a subclass called StringMapMessage > which > > allows all call sites to be changed from MapMessage to StringMapMessage > and > > eliminate compiler warnings. For more advanced use cases (like mine), I > can > > use MapMessage with generics or declare my own subclass. > > > > I like MapMessage and a new StringMapMessage subclass better than the > > initial proposal of a new GenericMapMessage and MapMessage subclass. > > > > What do you guys think? > > > > Gary > > > > > > On Sat, Jun 3, 2017 at 9:21 PM, Ralph Goers <[email protected]> > > wrote: > > > >> It seems OK to me. > >> > >> Ralph > >> > >>> On Jun 3, 2017, at 6:45 PM, Matt Sicker <[email protected]> wrote: > >>> > >>> I like the type erasure allowing for easier BC idea for sure. > >>> > >>> On 3 June 2017 at 14:08, Gary Gregory <[email protected]> wrote: > >>> > >>>> On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers < > [email protected] > >>> > >>>> wrote: > >>>> > >>>>> From a backward compatibility point of view changing that would be a > >>>>> problem. Also, StructuredDataMessage extends MapMessage and expects a > >>>>> String. That said, there must be a way to make it generic but have > the > >>>>> default be a String. For example, you could create a > GenericMapMessage > >>>>> that expects <String, T> and has most or all of the logic from > >> MapMessage > >>>>> and then have MapMessage extend it as GenericMapMessage<String>. > >>>>> > >>>> > >>>> Hi, > >>>> > >>>> I created two branches: > >>>> > >>>> GenericMapMessage adds a class called GenericMapMessage with > MapMessage > >> as > >>>> the subclass. Clirr check passes > >>>> > >>>> GenericMapMessageSimple modifies MapMessage with the same new code > that > >> is > >>>> in GenericMapMessage. Clirr check passes > >>>> > >>>> Since generics are erased, BC should not be an issue i neither case. > The > >>>> branch GenericMapMessageSimple is my preference since it does not add > a > >> new > >>>> class. > >>>> > >>>> I opted to add "with" method instead of "put" methods since we already > >> have > >>>> a "with" method. No need to have both "put" and "with" methods IMO. > >>>> > >>>> Thoughts? > >>>> > >>>> Gary > >>>> > >>>> > >>>>> Ralph > >>>>> > >>>>>> On Jun 2, 2017, at 2:04 PM, Gary Gregory <[email protected]> > >>>> wrote: > >>>>>> > >>>>>> Hi All: > >>>>>> > >>>>>> We make a big deal that our logger APIs take Object messages instead > >> of > >>>>>> Strings, but over in org.apache.logging.log4j.message.MapMessage > the > >>>>> values > >>>>>> are Strings, not Objects. > >>>>>> > >>>>>> Is that deliberate? > >>>>>> > >>>>>> That's proving to be a restriction for me... > >>>>>> > >>>>>> Any thoughts on allowing for the same kind of typing as in > >>>>>> javax.jms.MapMessage? > >>>>>> > >>>>>> Thank you, > >>>>>> > >>>>>> Gary > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Matt Sicker <[email protected]> > >> > >> > >> > > > -- Matt Sicker <[email protected]>
