Deprecation warnings

[Tom Rodriguez]

Thomas Wuerthinger wrote:
> We could define our own Integer class and avoid using java.lang.Integer.

 From what I can see, most places will happily work with Integer.valueOf 
instead.  There are some places where we are testing things like boxing 
elimination and we want to actually create an Integer instance that's 
different than the one boxing would return.  I think fixing all the 
deprecations and then seeing which unit tests fail and reverting it in 
those would probably find most of the issues.  We're still stuck with 
some of the deprecation warnings though.  We could do something hacky 
like have a deprecrated function we call from those same locations just 
so a SuppressWarning("deprecation") isn't an error, like our own wrapper 
around new Integer(v) that we always deprecate.  Horrible but so are the 
deprecation warnings.

tom

>
> - thomas
>
>> On 01 Feb 2017, at 19:55, Tom Rodriguez<tom.rodriguez at oracle.com>  wrote:
>>
>>
>>
>> Doug Simon wrote:
>>>> On 1 Feb 2017, at 19:42, Andrew Haley<aph at redhat.com>   wrote:
>>>>
>>>> /nfs/zebedee/home/graal/aph/truffle/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java:388: warning: [deprecation] Integer(int) in Integer has been deprecated
>>>> 		literals.put("return", new Integer(17));
>>>>
>>>> There are too many of these.  Shall I just fix them all?
>>> No - we’re stuck with those because these methods are not deprecated on jdk8. So if you use SuppressWarnings, you’ll get a warning on jdk8 about an unnecessary suppression!
>> Well they can be changed to use valueOf instead, though for test cases I think we'll need to make sure we don't actually care about object identity.  Those I think we're stuck with.  That's going to be a very painful deprecation warning for lots of people.
>>
>> tom
>