Clean up the use of deprecated numeric constructors

[BradWalker]

This change cleans up the use of old deprecated numeric constructors..

Warnings like this will no longer happen:

[repeat] /home/bwalker/src/netbeans/java/testng/src/org/netbeans/modules/testng/AbstractTestGenerator.java:1700: warning: [deprecation] Float(float) in Float has been deprecated
[repeat]                     defValue = maker.Literal(new Float(0.0F));
[repeat]    

The newer implementation favor factory methods like valueOf() or parseFloat() since they are likely to
yield significantly better space and time performance by caching frequently requested values.

Also, the compiler/VM can do a better job of accessing the actual numeric values using autobox/unbox.

Most of these changes are in the enterprise/ide/java/profiler modules.

There are also some places that were changed to use the diamond operator.

---

^Add meaningful description above

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

[mbien]

hi Brad,
the current code inspection in NB for this is not optimal. There is a PR in queue which attempts to fix some of it #3240

for example

-            int timeout = new Integer(startingStateTimeout);
+            int timeout = Integer.valueOf(startingStateTimeout);

should be Integer.parseInt(startingStateTimeout), since the target type (int timeout) is primitive.

@lkishalmi has also a PR here #2498 which attempts the same cleanup. I don't know the state of it, maybe he can comment.

[BradWalker]

hi Brad, the current code inspection in NB for this is not optimal.

I fixed the cases where the code should be calling parseInt() instead of valueOf().

There is a PR in queue which attempts to fix some of it #3240

I looked at this. My efforts stem from trying to reduce the warning messages. This PR #3240 , while admirable, are more comprehensive than what I'm proposing.

@lkishalmi has also a PR here #2498 which attempts the same cleanup. I don't know the state of it, maybe he can comment.

I looked at the work he did and I'm happy to take it over if that helps. But, the work that @lkishalmi was doing was really more comprehensive than what I was trying to do.

I'm simply trying to keep my changes "small" and self contained. This way the impact is very minimal.

@mbien , how do the changes look now?

[lkishalmi]

As of mine at #2498 some tests are failing especially around the Clipboard handling (if I remember well) which I was not able to resolve. Probably doing this in smaller steps would be better. I'm going to close #2498 in favor of Brad's efforts.

[mbien]

@BradWalker I took a quick look and it looks fine to me, could you mention in the commit which areas of NB the cleanup is covering? Otherwise they all will look the same in the log.

[mbien]

I am sure you know, but I just wanted to add that we have to be super careful in refactorings like this, if some code does identity comparisons with ==, it can break. Thats the reason why #2498 got stuck.

        System.out.println(new Integer(5) == new Integer(5));       // false
        System.out.println(new Integer(5) == Integer.valueOf(5));   // false
        System.out.println(5 == new Integer(5));                    // true
        System.out.println(5 == Integer.valueOf(5));                // true
...

[BradWalker]

I am sure you know, but I just wanted to add that we have to be super careful in refactorings like this, if some code does identity comparisons with ==, it can break. Thats the reason why #2498 got stuck.

Agreed.. That's why I really try to do everything by hand. So, hopefully, I don't introduce an error as a result of the work.