Discussion about fixing deprecation in jdk.hotspot.agent

[Magnus Ihse Bursie]

Hi everyone,

As a follow-up to the ongoing review for JDK-8241618, I have also looked 
at fixing the deprecation warnings in jdk.hotspot.agent. These fall in 
three broad categories:

* Deprecation of the boxing type constructors (e.g. "new Integer(42)").

* Deprecation of java.util.Observer and Observable.

* The rest (mostly Class.newInstance(), and a few number of other odd 
deprecations)

The first category is trivial to fix. The last category need some 
special discussion. But the overwhelming majority of deprecation 
warnings come from the use of Observer and Observable. This really 
dwarfs anything else, and needs to be handled first, otherwise it's hard 
to even spot the other issues.

My analysis of the situation is that the deprecation of Observer and 
Observable seems a bit harsh, from the PoV of jdk.hotspot.agent. Sure, 
it might be limited, but I think it does exactly what is needed here. So 
the migration suggested in Observable (java.beans or 
java.util.concurrent) seems overkill. If there are genuine threading 
issues at play here, this assumption might be wrong, and then maybe 
going the j.u.c. route is correct.

But if that's not, the main goal should be to stay with the current 
implementation. One way to do this is to sprinkle the code with 
@SuppressWarning. But I think a better way would be to just implement 
our own Observer and Observable. After all, the classes are trivial.

I've made a mock-up of this solution, were I just copied the 
java.util.Observer and Observable, and removed the deprecation 
annotations. The only thing needed for the rest of the code is to make 
sure we import these; I've done this for three arbitrarily selected 
classes just to show what the change would typically look like. Here's 
the mock-up:

http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01

Let me know what you think.

/Magnus