@Supported design issues

[Daniel Latrémolière]

> 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