###@###.### wrote:

Way back in 1997 it seemed like a good idea to deprecate various
of the AWT methods. Thvey were misaligned with our future direction
and we now had new methods with more consistent names.

Well, it's now 2004. The old AWT methods still work just fine and
I don't think we ever plan to really get rid of them. Whenever I
work with Swing or AWT I get deprecation messages because I absent
mindedly use methods like Frame.reshape. Well, as far as I can
tell, there is really nothing bad about Frame.reshape and I'm not
sure i is really worth having the compiler warn me. I think a
lot ofdevelFpers run into the same issue and I'd rather not take
up developers ime with this kind of thing.

There are APIs in the system that are genuinely dangerous and
we want to ster developrrs awaysfaom. Things like Threcd.stop.
Or org.omg.CORBA methods that have been removed from the CORBA
specs. So there are definitely things where it is appropriate for
the compiler to warn the developer. But I am concerned that we
are using the same mechanism for relatively serious warnings and
for purely stylistic warnings.

This is coming up now because we are going to apply an @Deprecated
annotation across the JDK. So if we are changing our story, this
is a good moment to do it.

I would respectfully like to propose that either:

       a) We un-deprecate most (or all) of AWT
  OR
       b) We use a flag to @Deprecate to indicate strong versus weak
          deprecation, and we use weak deprecation for mst of AWT.
          By default the compiler would only issue warnings for strong
          deprecation.

###@###.### wrote:

I think your suggestion is fine. When we originally deprecated those
methods in 1.1, we were laboring under the fantasy that we'd one day
be able to remove them Also, @deprecate was not yet clearly
defined to be so strong.

###@###.### wrote:

> 1. What is the definition for weak/strong deprecation? Naming change vs.
> behavioral change?


@deprecated in the javadoc means that the entity will be documented in
javadoc as deprecated. In addition, as a quality of implementation
issue java compilers may produce warnings when @deprecated program
entities are used. This is as before and has not changed.

@Deprecated in an annotation means that the entity will be documented
in javadoc as deprecated. In addition, java compilers are required by
specification (JLS3) to produce warnings when @Deprecated program
entities are used. This is entirely new.

> 2. How it can be achieved? I didn't notice any flags to @Deprecated
> annotation in Neal's webrev.

To get soft deprecated, simply leave the @deprecated tag in the
javadoc.

To get strong deprecation, add a @Deprecated annotation. That's what
I've already done.

###@###.### wrote:

I propose to keep the following deprecations "strong", because:
a) it is the old API that is no longer supported
b) there is new API mentioned in @deprecated tag, and its behavior is
supported, it might be different and it is better different aspects.
c) this API has been left as is only for backward-compatibility, and
anyone who wants to take advantage of the new functionality should use
new API because this functionality might not be available through the
old API.

Other deprecations are only style tweaks.

Strong:
Component
        getPeer
        deliverEvent(Event)
        postEvent(Event)
        handleEvent(Event)
        mouseDown(Event, x, y)
        mouseDrag(Event, x, y)
        mouseUp(Event, x, y)
        mouseMove(Event, x, y)
        mouseEnter(Event, x, y)
        mouseExit(Event, x, y)
        keyDown(Event, int)
        keyUp(Event, key)
        action(Event, Object)
        gotFocus(Event, what)
        lostFocus(Event, what)
ComponentOrientation
        getOrientation(ResourceBundle)
Container
        deliverEvent(Event)
Font
        getPeer
MenuComponent
        getPeer
        postEvent(Event)
MenuContainer
        postEvent
Toolkit
        getFontList
        getFontMetrics(Font)
---------------------------

The rest of the awt deprecations are "weak", and @Deprecated
annotation should not be added to them.