various tweaks & fixes

Mostly for
https://github.com/libgdx/libgdx/issues/2359
https://github.com/libgdx/libgdx/issues/2524
https://github.com/libgdx/libgdx/issues/2441
https://github.com/libgdx/libgdx/issues/2436

IMO, the level of effort required to write code that cannot throw a class
cast exception (ie has no warnings when all the generics warnigns are
enabled) is too much for the "problem" it solves. You have a good point
that classes extending libgdx would gain the warning, but then people who
turn on those warnings (or who don't turn them off, since for some godawful
reason it is on by default) are signing up for the extra pain. ;)



On Tue, Nov 4, 2014 at 1:23 PM, vaxquis <notifications@github.com> wrote:

> In gdx/src/com/badlogic/gdx/utils/Json.java:
>
> > @@ -141,7 +155,7 @@ public void setUsePrototypes (boolean usePrototypes) {
> >
> >  	/** Sets the type of elements in a collection. When the element type is known, the class for each element in the collection does
> >  	 * not need to be written unless different from the element type. */
> > -	public void setElementType (Class type, String fieldName, Class elementType) {
> > +	public void setElementType (Class<?> type, String fieldName, Class<?> elementType) {
>
> While I agree they can be considered noise with no semantic value, they
> indicate that the class *is* in fact generic, otherwise it's visually
> identical to any other class. I wouldn't have any problem with internal lib
> code choices; the main problem with this approach is that when using a
> libGDX-based projects *and* wanting to have rawtype warnings generated
> for the non-lib-side code (and I assume that's the Java standard, at least
> Bloch, Oracle's Java tutorials & default settings of IDEs), the classes
> overriding libGDX has to adhere to libGDX method type signatures,
> generating the warnings themselves. For private or package private
> fields/methods I don't see a slightest problem with Class, yet for
> protected and public fields it makes inheritance without code smells
> impossible.
>
> Still, I can agree it's an arguable case, mainly because the generics
> themselves sometimes produce nasty problems with erasures etc, so if you're
> confident the API has to stay non-standard (Bloch, EJ2nd, items 23/24), I
> can only agree with it. It's just that while I disagreed with standards on
> many occasions, with every passing month I'm more and more convinced they
> are the way to go, due to POLA. For seasoned Java programmers, a
> JLS-compliant & Bloch-compliant lib code is much easier to use, mainly
> because they use it everyday.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/libgdx/libgdx/pull/2542/files#r19799368>.
>