What's the recommendation for the legitimate usage of the deprecated
property? In my case, a gemFire property is deprecated, but "start locator"
command still has an option to turn on that property (the option is
deprecated as well, but we are still obligated to keep it in the code). In
this case, which option is favorable?
1. use the @SuppressWarnings({"deprecation") on the method that uses that
property
2. do not refer that property but use the string literal instead?
3. anything else?
On Fri, May 8, 2020 at 1:34 PM John Blum <jb...@pivotal.io> wrote:
> Regarding...
>
> *> public interface A is returning Region and not Region<K,V> is that an
> acceptable suppression?*
>
> I think Geode API/Framework (e.g. PDX) (production) code should be very
> explicit and *not* use *rawtypes*, or even *wildcard* types, for that
> matter, as far as possible.
>
> To be clear, I am saying sometimes in tests, *rawtypes* are useful.
>
> Again, all of these things should be applied responsibly and judiciously,
> with intent, especially in production code.
>
> Use of *Java Generics* in code can cause as much grief for a user as it
> does help in other cases (as Jake alluded to), so it needs to be careful
> crafted, especially in public APIs as it affects more than test code, but
> even application code that might require references to Geode objects.
>
> -j
>
>
> On Fri, May 8, 2020 at 1:30 PM Mark Hanson <mhan...@pivotal.io> wrote:
>
> > It is slightly different, but here is a case I recently found.
> >
> > List<VersionTag> versionTags = versions.getVersionTags();
> >
> > This method is internal though.
> > public List<VersionTag> getVersionTags() {
> > return Collections.unmodifiableList(this.versionTags);
> > }
> >
> > Thanks,
> > Mark
> >
> >
> > > On May 8, 2020, at 1:25 PM, Mark Hanson <mhan...@pivotal.io> wrote:
> > >
> > > How does everyone feel about situations involving raw types?
> > >
> > > Such as public interface A is returning Region and not Region<K,V> is
> > that an acceptable suppression?
> > >
> > > Thanks,
> > > Mark
> > >
> > >> On May 8, 2020, at 1:20 PM, John Blum <jb...@pivotal.io> wrote:
> > >>
> > >> Agreed, but the following (inside tests) does not work in all cases,
> > i.e.
> > >>
> > >> Region<String, String> region...
> > >>
> > >> Particularly if "region" is passed to a method with a different type
> > >> signature.
> > >>
> > >> I am trying to find/think of the situation I encounter from time to
> > time,
> > >> even when I use the *wildcard* signature (i.e. Region<?, ?>), but
> cannot
> > >> currently find it (*#ugh*).
> > >>
> > >> Anyway, the point is, if the test is really not concerned with the
> type
> > of
> > >> values (*keys*, *values*) being stored in the mock *Region* then
> > rawtypes (or
> > >> sometimes Region<?, ?>) are useful in some cases since the point of
> the
> > >> test is not about the data but perhaps about *Region* configuration in
> > >> general, so adding types detracts (adds undue noise) to the code under
> > test
> > >> (IMO).
> > >>
> > >> It depends and is subjective.
> > >>
> > >> I agree, though, in general, @SuppressWarnings should be kept to a
> > minimum
> > >> and used only when necessary.
> > >>
> > >> -j
> > >>
> > >> On Fri, May 8, 2020 at 1:09 PM Kirk Lund <kl...@apache.org> wrote:
> > >>
> > >>> Actually there is an alternative to using @SuppressWarnings for
> Mockito
> > >>> mocks:
> > >>>
> > >>> Region<String, String> region = cast(mock(Region.class));
> > >>>
> > >>> private static <T> T cast(Object object) {
> > >>> return (T) object;
> > >>> }
> > >>>
> > >>> Personally, I'd prefer to see warnings or workarounds like above than
> > see
> > >>> lots of @SuppressWarnings littered throughout our code base. I think
> > it's a
> > >>> smell of bad code.
> > >>>
> > >>> On Fri, May 8, 2020 at 12:44 PM Jacob Barrett <jbarr...@pivotal.io>
> > wrote:
> > >>>
> > >>>>
> > >>>>
> > >>>>> On May 8, 2020, at 12:41 PM, Donal Evans <doev...@pivotal.io>
> wrote:
> > >>>>>
> > >>>>> Is there a consensus on what constitutes a benign warning? I think
> > the
> > >>>> only
> > >>>>> times I use @SuppressWarnings is in parameterized tests to suppress
> > the
> > >>>>> unused method warning for the parameters method, or for unchecked
> > >>> casts,
> > >>>> as
> > >>>>> below:
> > >>>>>
> > >>>>> PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
> > >>>>> when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
> > >>>>>
> > >>>>> where the thenReturn() would complain, since it's expecting to
> > return a
> > >>>>> Region<Object, Object>.
> > >>>>>
> > >>>>> Would these be considered things that could safely just be ignored
> > (and
> > >>>> so
> > >>>>> for which I can turn off inspection), or is the use of
> > >>> @SuppressWarnings
> > >>>>> here warranted?
> > >>>>
> > >>>> This is a legitimate suppression. There is no other way to correct
> the
> > >>>> dysfunctional nature of Java Generics than to @SuppressWarnings. In
> > this
> > >>>> case though only that statement should be suppressed.
> > >>>>
> > >>>> -Jake
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >> --
> > >> -John
> > >> Spring Data Team
> > >
> >
> >
>
> --
> -John
> Spring Data Team
>
--
Cheers
Jinmei
