That isn't at all what @deprecated means.
"Encouraged for new development" doesn't mean everything else is
@deprecated.
These are all part of the Java SE platform spec, and are documented as
such
and are fully supported .. a focus on compatibility is very important
to a lot
of our customers, even if that's not you.
Sorry if I have not clearly read, but it is not my opinion on Swing.
Just for explaining reasons of my opinion (if you found some others
people thinking like me) and not really arguing (person-specific then
usually near useless), I will give you some texts inducing this personal
point of view on Swing.
---
When to Deprecate
When you design an API, carefully consider whether it supersedes an old
API. If it does, and you wish to encourage developers (users of the API)
to migrate to the new API, then deprecate the old API.
http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/deprecation/deprecation.html
---
6. Is JavaFX replacing Swing as the new client UI library for Java SE?
Yes. However, Swing will remain part of the Java SE specification for
the foreseeable future, and therefore included in the JRE. While we
recommend developers to leverage JavaFX APIs as much as possible when
building new applications, it is possible to extend a Swing application
with JavaFX, allowing for a smoother transition.
http://www.oracle.com/technetwork/java/javafx/overview/faq-1446554.html#6
---
[JEP 161]
The primary motivation for this feature is to allow applications that do
not require the entire Java SE Platform to run on resource-constrained
devices. An application that does not use the Swing/AWT/2D graphics
stack, e.g., or which uses Java FX instead, can achieve considerable
space savings by running on top of a Profile that does not include those
APIs.
[... CDC migration to JavaSE ...]
As a secondary benefit, this feature is likely to enable faster download
times for applications that bundle their own Java Runtime Environment (JRE).
http://openjdk.java.net/jeps/161
---
JavaFX applications have implicit dependency on the availability of Java
and JavaFX runtimes, and while existing deployment methods provide a
means to validate the system requirements are met -- and even guide the
user to perform required installation/upgrades -- they do not fully
address all of the important scenarios.
In particular, here are few examples:
the user may not have admin permissions to install new system software
if the application was certified to run in the specific environment
(fixed version of Java and JavaFX) then it may be hard to ensure user
has this environment due to an autoupdate of the system version of
Java/JavaFX (to ensure they are secure). Potentially, other apps may
have a requirement for a different JRE or FX version that your app is
incompatible with.
your distribution channel may disallow dependencies on external
frameworks (e.g. Mac AppStore)
https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx
