java的swing被什么取代了—javaswing被淘汰 收藏 0

盘点 6 个被淘汰的 Java 技术，它们都曾经风光过

大家好啊，今天栈长给大家分享下我的开发历程中，我知道的那些被淘汰的技术或者框架，有些我甚至都没有用过，但我知道它曾经风光过。

废话不多说，下面我要开始吹了……

1、Swing

下面这个是用 swing 开发的：

图来源网络，有没有似曾相识的感觉？懂的自然懂！

栈长去年中秋也用过 swing：

这个中秋，我用 Java 画了一个月饼！

Swing 算是 Java 早期代替 AWT 的桌面应用 GUI 开发工具包，一个听到就已经淘汰的技术，给我的感觉就是丑丑丑！现在与 AWT 一起在时间这个长河里长眠。

如果 Java GUI 库发展历程分为三代，可以是：

AWT > SWING > JAVAFX

随着 JavaFx 的发布，加速 SWING 的被淘汰。下面这个是用 JavaFx 开发的：

图来源：zhihu.com/question/54498643/answer/271632290

现在 JavaFx 也有十来年了，虽然这篇帖子也在说 JavaFx 淘汰了的，只是现在桌面应用不是主流吧，我也没用过不敢乱说，JavaFx 在桌面应用开发应该还是有一席之地的。

2、JSF

JSF：Java Server Faces

JSF是一种用于构建 Java Web 应用程序的表现层框架，和 Struts 一样性质的框架。

图来源：https://javabeat.net/jsf-2/

国内用 JSF 的比较少，有也是老系统了，国外应该还有用 JSF 的，不过随着 Spring MVC, Spring Boot 的横空出世，JSF 应该也是过时的技术了。

3、EJB

EJB也是个神器，只见其影，未见其身。前些年，在网上各个面试题还有它的身影，现在估计很难见到了。

EJB：Enterprise Java Beans，即：企业Java Beans

Sun公司发布的文档中对 EJB 的定义是：EJB 是用于开发和部署多层结构的、分布式的、面向对象的 Java 应用系统的跨平台的构件体系结构。

简单来说，EJB就是部署分布式系统用的，就是把A程序放在服务器上，通过B客户端来调用，并且是跨平台的。

图来源：oreilly.com

因为 EJB 过于复杂和笨重，调试非常麻烦，现在都被轻量级的 RPC 框架（Dubbo）及轻量级 Restful 形式的分布式框架 （Spring Cloud） 替代了。

4、JSP

JSP 全称：Java Server Pages，是由早期的 Sun 公司发布的一种动态网页开发技术，即在 HTML 网页代码中嵌入 JSP 标签的 Java 代码实现动态网页。

JSP 代码示例：

这个示例只是简单的调用 JSP 的内置 out 对象在页面输出展示一句话。

JSP 的本质其实就是 Servlet，JSP 文件被编译之后，就变成了 Servlet Java 类文件，因为 JVM 虚拟机只能识别 Java 字节码文件，而不能识别 JSP 文件。

在 JSP 的时代，那时候还没有前后端分离的说法，JSP 可以包揽全部，即实现静态页面，又实现动态代码逻辑，全部都在一个 JSP 文件里面。这样，一个程序员既是前端，又是后端。

但是，现如今在前后端分离的热潮下，前后端分工明确，后端只负责业务逻辑的接口开发，前端负责调用后端接口再做页面数据封装展示，JSP 几乎是被淘汰了。

虽然 JSP 是被前后端分离取代了，但并不说明 JSP 没有用了，不是所有系统都是前后端分离的，比如说一个只有两三个页面的动态系统，JSP、Servlet足以搞定，你总不能上页面模板引擎、各种框架，或者再上前后端分离吧？

5、Struts

Struts2 那些年可谓是风光无限啊，Struts2 + Spring + Hibernate 三大框架一起组成了 “SSH“————牛逼哄哄的 Java Web 框架三剑客。

Struts 这篇就不多说了，具体看这篇：Struts2 为什么被淘汰？

6、Memcached

Redis 这几年的大热，现在已经替代 Memcached 成为缓存技术的首要中间件，作为大厂的带头兵，在 BAT 里面，Redis 也已经逐渐取代了 Memcached，广泛使用 Redis 作为缓存应用方案。

为什么 Redis 能后来居上呢？

1）速度更快

Memcached 使用的是多线程模型，既然是多线程，就会因为全局加锁而带来性能损耗。而 Redis 使用的是单线程模型，没有锁竞争，速度非常快。

相关阅读：Redis 到底是单线程还是多线程？

2）数据类型更丰富

Memcached 数据类型非常单一，只支持 String 数据类型，在业务实现上就非常有瓶颈。

而 Redis 支持 string(字符串)、hash(哈希)、list(列表)、set(集合)、zset(sorted set:有序集合) 等……丰富的数据类型可以让 Redis 在业务上大展拳脚。

这也是 Redis 能代替 Memcached 最重要的原因之一。

相关阅读：Redis 的 8 大应用场景！

并且，Memcached 值最大上限为：1M，而 Redis 最大可以到：1GB。

3）数据持久化

Memcached 不支持持久化，Redis 支持。

缓存服务器断电后，Memcached 的数据是不能恢复的，而 Redis 可以将数据保久化在磁盘中，服务器重启的后可以加载再次使用，不会造成数据断电丢失。

比如，有些数据是直接放在缓存数据库中的，其他地方可能没有备份，如果丢失了，那可能会造成业务影响，这也是 Redis 非常有用的一个保障特性。

总结

好了，今天栈长列举了 6 个经典的即将被淘汰的技术或框架，虽然这些技术现在面临淘汰，但它们曾经也风光过，值得敬畏。

另外，虽然这些技术要被淘汰了，但不说明它们没有用了，它们依然在被运用，只是现在不是主流了。

最后，在大家的开发历程中，你都遇到过哪些曾经很风光，但现在即将被淘汰的技术呢？欢迎大家留言分享讨论~

关注我，分享更多好玩的Java技术～

大牛带你深入Java核心知识点图形程序设计：Swing概述+创建框架

到目前为止，我们编写的程序都是通过键盘接收输入，在控制台屏幕上显示结果。绝大多数用户并不喜欢这种交互方式。现代的程序早已不采用这种操作方法，网络程序更是如此。

从本章开始，我们将介绍如何编写使用图形用户界面（GUI）的Java程序。其中，主要讲述如何编写定义屏幕上的窗口大小和位置的程序；如何在窗口中采用多种字体显示文本；如何显示图像等等。这些都是需要掌握的编程技能，在后续章节中，将会使用这些技术编写一些很有趣味的程序。

在Java 1.0刚刚出现的时候，包含了一个用于基本GUI程序设计的类库，Sun将它称为抽象窗

口工具箱（Abstract Window Toolkit，AWT）。基本AWT库采用将处理用户界面元素的任务委派给每个目标平台（Windows、Solaris、Macintosh等等）的本地GUI工具箱的方式，由本地GUI工具箱负责用户界面元素的创建和动作。例如，如果使用最初的AWT在Java窗口中放置一个文本框，就会有一个低层的“对等体”文本框，用它来实际地处理文本输入。从理论上说，结果程序可以运行在任何平台上，但观感（look and feel）的效果却依赖于目标平台，因此，Sun公司的口号是“一次编写，随处使用”。

对于简单的应用程序来说，基于对等体方法的效果还是不错的，但是，要想编写依赖于本地用户界面元素的高质量、可移植的图形库就会显现出缺陷了。例如，菜单、滚动条和文本域这些用户界面元素，在不同的平台上，操作行为存在着一些微妙的差别。因此，要想给予用户一致的、可预见性的界面操作方式是相当困难的。而且，有些图形环境（如X11/Motif）并没有像Windows或Macintosh这样丰富的用户界面组件集合。这也就将基于对等体的可移植库限制在了“最小公分母”的范围内。其结果使AWT构建的GUI应用程序看起来没有Windows或Macintosh应用程序显示的那么漂亮，也没有提供那些平台用户所认知的功能。更加糟糕的是，在不同平台上的AWT用户界面库中存在着不同的bug。研发人员必须在每一个平台上测试他们的应用程序，因此人们嘲弄地将AWT称为“一次编写，到处调试”。

在1996年，Netscape创建了一种称为IFC（Internet Foundation Class）的GUI库，它采用了与AWT完全不同的工作方式。它将按钮、菜单这样的用户界面元素绘制在空白窗口上，而对等体只需要创建和绘制窗口。因此，Netscape的IFC部件在程序运行的所有平台上的外观和动作都一样。Sun与Netscape合作完善了这种方式，创建了一个名为Swing（有时称为Swing集）的用户界面库。Swing可作为Java 1.1的扩展部分使用，现已成为JDK 1.2标准库的一部分，

就像Duke Ellington所说的那样：“如果没有Swing，Java图形界面就没有任何意义”。现在，Swing是不对等基于GUI工具箱的正式名字。它已是Java基础类库（Java Foundation Class，JFC）的一部分。完整的JFC十分庞大，其中包含的内容远远大于Swing GUI工具箱。JFC特性不仅仅包含了Swing组件，而且还包含了一个可访问的API、一个2D API和一个可拖拽的API。

注意：Swing没有完全替代AWT，而是基于AWT架构之上。Swing仅仅提供了能力更加强大的用户界面组件。尤其在采用Swing编写的程序中，还需要使用基本的AWT处理事件。从现在开始，“Swing”是指“被绘制的”非对等体用户界面类；“AWT”是指像事件处理这样的窗口工具箱的低层机制。

当然，在用户屏幕上显示基于Swing用户界面的元素要比显示AWT的基于对等体组件的速度慢一些。鉴于以往的经验，对于任何一台现代的计算机来说，微小的速度差别无妨大碍。另外，由于下列几点无法抗拒的原因，驱使人们选择Swing：

• Swing拥有一个丰富、便捷的用户界面元素集合。

• Swing对低层平台依赖的很少，因此与平台相关的bug很少。

• Swing给予不同平台的用户一致的感观效果。

所有这些意味着Swing拥有履行Sun提出的“一次编写，到处运行”承诺的能力。

不过，上面第三点存在着一个潜在的问题：如果在所有平台上用户界面元素看起来都一样，那么，它们就有可能与本地控件不一样，而这些平台的用户对此可能并不熟悉。

Swing采用了一种很巧妙的方式来解决这个问题。在程序员编写Swing程序时，可以为程序指定专门的“观感”。

例如，图7-1和图7-2展示了同一个程序在Windows 和Motif平台下运行的观感。

注意：尽管本书并没有打算介绍有关设定“观感”的方式，但Java程序员可以对已存在的观感进行扩展，甚至还可以设计全新的观感。设计Swing组件的绘制方式是一个很繁琐的过程。有些程序员已经做过一些这样的工作，尤其是将Java移植到信息亭（kiosk）终端和手持设备这样的非传统平台上。请参阅 http://www.javooto.com，其中包含了一系列有趣的观感实现。

JDK 5.0引入了一种被称为Synth的新观感方式，使用它处理比较容易。在Synth中，可以通过指定图像文件和XML描述符定义一种新观感，而不需要编写任何代码。

此外，Sun开发了一种被称为“Metal”的独立于平台的观感。现在，市场上人们将它称为“Java观感”。不过，绝大多数程序员还继续沿用着“Metal”这个术语，在本书中也将这样称呼。

有些人批评Metal有点笨重，而在版本5.0中看起来却焕然一新（请看图7-3）。

现在，Metal外观支持多种主题，每一种主题的颜色和字体都有微小的变化。

默认的主题叫做“Ocean”。在本文中，所有的图形程序都将采用Swing的Metal观感和Ocean主题。

注意：绝大多数Java用户界面程序设计都采用Swing，但有一个特别的例外。Eclipse集成开发环境使用了一种与AWT类似，且被称为SWT的图形工具箱，它可以映射到不同平台的本地组件上。

有关SWT的描述可以在网站http://www.eclipse.org/ articles/找到。

最后，给大家一个忠告，如果使用过Visual Baisc或C# 编写Microsoft Windows应用程序，就应该了解这些产品提供的图形布局工具和资源编辑器带来的便利。这些工具可以用来设计应用程序的外观，然后生成大部分（有时是全部）GUI代码。尽管也有一些Java程序设计的GUI构造器，但它们与相应的Windows工具相比较起来还很不成熟。不管怎样，要想完全地掌握图形用户界面程序（乃至有效地使用这些工具），就需要知道如何手工地创建用户界面。当然，通常需要编写大量的代码。

在Java中，顶层窗口（就是没有包含在其他窗口中的窗口）被称为框架（frame）。在AWT库中有一个称为Frame的类，用于描述顶层窗口。这个类的Swing版本名为JFrame，它扩展于Frame类。JFrame是极少数几个不绘制在画布上的Swing组件之一。因此，它的修饰部件（按钮、标题栏、图标等）由用户的窗口系统绘制，而不是由Swing绘制。

警告：大多数的Swing组件类都以“J”开头，例如，JButton、JFrame等等。在Java中有Button和Frame这样的类，但它们属于AWT组件。如果偶然地忘记了书写“J”，程序仍然可以进行编译和运行，但是将Swing和AWT组件混合在一起使用将会导致视觉和行为的不一致。

在本节中，将介绍有关Swing的JFrame的常用方法。例7-1给出了一个在屏幕中显示一个空框架的简单程序。如图7-4所示。

例7-1 SimpleFrameTest.java

下面逐行地讨论一下这个程序。

Swing类位于javax.swing包中。包名javax表示这是一个Java扩展包，而不是核心包。Swing类实际上是对Java 1.1的扩展。由于Swing类不是核心层次的一部分，所以尽可能地将Swing类加载到Java 1.1兼容的浏览器中（浏览器的安全管理器不允许添加任何以“java.”开头的包）。在Java 2平台上，Swing包不再是扩展部分，而是核心层的一部分。任何与Java 2兼容的Java实现都必须提供Swing类。不过，为了与Java 1.1代码兼容，保留了javax名字。（实际上，Swing包最早是com.sun.java.swing，后来在Java 2的beta版本中简化为java.awt.swing，最后在Java 2后期的beta版本中又改回为com.java.swing，在Java程序员的抗议呼声下，最终改为javax.swing。）

在默认情况下，框架的大小为0×0像素，这种框架没有什么实际意义。我们定义了一个子类SimpleFrame，它的构造器将框架大小设置为300×200像素。在SimpleFrameTest类的main方法中，程序将由创建一个SmpleFrame对象开始运行。

接下来，我们定义了用户关闭这个框架时的响应动作。对于这个程序而言，我们只是让程序退出。选择这个响应动作的语句是：

frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

在包含多个框架的程序中，不能因为用户关闭了其中的一个框架就让程序退出。在默认情况下，用户关闭窗口时只是将框架隐藏了起来，而程序并没有终止。

简单地构造一个框架并不自动显示出来，框架起初是不可见的。这就给程序员了一个机会，可以在框架第一次显示之前往其中添加组件。为了显示框架，main方法需要调用框架的setVisible方法。

然后，main方法退出。需要注意，退出main并没有终止程序，终止的只是主线程。目前显示的框架激活了用户界面线程，以保持程序处于激活状态。

注意：在JDK 5.0以前的版本中，可以使用JFrame类从超类Window继承show方法。Window类的超类是Component，其中也有一个show方法。在JDK 1.2中不提倡使用Component.show。如果想要显示一个组件，建议调用setVisible(true)。然而，JDK 1.4以前的版本，并没有反对使用Window.show方法。事实上，这个方法很实用，它可以让窗口可见，且置于其他窗口的前面。遗憾的是，由于不提倡使用它，随之也失去了这一好处，JDK 5.0也不赞成使用show显示窗口。

图7-4中显示的是运行例7-1程序的结果，它只是一个很乏味的顶层窗口。在这个图中看到的标题栏和外框装饰（比如，重置窗口大小的拐角）都是由操作系统绘制的，而不是Swing库。如果在X Windows下运行同样的程序，对框架的装饰是不一样的。Swing库负责绘制框架内的所有内容。在这个程序中，只用默认的背景色填充了框架。

注意：在JDK 1.4中，可以调用frame.setUndecorated(true) 关闭所有框架装饰。

注意：在前面的例子中编写了两个类，一个用于定义框架类，另一个包含了创建和显示框架对象的main方法。在很多程序中，经常会发现main方法被包装成一个很简捷的类，如下所示：

从某种意义上说，调用框架类中的main方法的代码启动程序是比较简单的。这样不必引入其他的辅助类。然而，有相当多的程序员感觉这种程序风格有点混乱。

因此，更愿意将启动程序的类与定义用户界面的类分开。

明天讲框架定位和在面板中显示信息~~

Java 17新特性

Java 17计划于 9 月 14日发布，来自不同供应商的版本将在当天或之后发布。Java 17 的特别之处当然是 Oracle 和 OpenJDK 社区都决定这将是一个长期支持版本，就像 Java 11 和之前的 Java 8 一样。

自从从 Java 10 开始引入快速发布节奏以来，除 Oracle 之外的许多供应商都加紧生产具有各种级别支持的生产就绪二进制文件，包括Amazon、Azul、BellSoft、Microsoft、SAP和

Eclipse Adoptium（以前为AdoptOpenJDK）。

下面是新的特性：

• macOS 上的 AArch64 支持

此版本中添加的突出功能之一是支持AArch64上的macOS ，增加了Apple 去年发布的新 CPU 系列 (M1) 的支持。对于在这些平台上运行的人来说，这并不是什么新闻，因为一些供应商已经发布了支持这种架构的 JDK 版本，甚至将支持一直回溯到 Java 8。 尽管如此，官方批准版本仍然很重要平台未来的维护和支持。为了比较，Java 9 中添加了对 Linux/AArch64 平台的支持，Java 16 中添加了对 Windows/AArch64 的支持。

• 密封类

Sealed Classes 特性已完成其预览阶段，现在是 Java 17 中语言和平台的标准部分，如JEP 409 中所定义。密封类允许开发人员显式声明类型的允许子类型，从而防止其他人无意中扩展或实现它。

• 其他新功能

Java 17 还为在 macOS 上运行的 AWT/Swing 应用程序带来了新的渲染管道 ( JEP 382 )，使用 Apple 的 Metal API 而不是 OpenGL，以及用于生成随机数的新 API 和增强功能 ( JEP 356 )。

其他限制或弃用功能：

• JDK内部元素强封装

JEP 403强封装 JDK 的所有内部元素，除了 关键的内部 API，如sun.misc.Unsafe. 不再可能通过单个命令行选项访问。将 JDK 从默认的宽松强封装转换为默认 强封装。

在Java9中，如果用户尝试使用反射或喜欢绕过使用其他内部 API 的正常限制，则会发出运行时警告。还添加了命令行参数来控制此行为。在 Java 16 中，默认设置从发出警告更改为通过抛出异常拒绝访问，但仍保留命令行参数以更改行为。

现在在 Java 17 中，进一步删除了这些命令行参数，当然也能禁用此限制，这意味着对这些内部 API 的所有未经授权的访问现在都被强封装。

好处：

1. 继续提高 JDK 的安全性和可维护性
2. 鼓励开发人员从使用内部元素迁移到使用标准 API，以便他们和他们的用户可以轻松升级到未来的 Java 版本。

• 始终严格的浮点语义

恢复 Always-Strict Floating-Point Semantics ( JEP 306 )。Java 1.2 引入了对 Java 中默认浮点语义的更改，实质上允许 JVM 以牺牲一点点浮点精度来换取性能。对于需要应用严格语义的方法和类，引入了一个关键字strictfp。从那时起，新的指令集被添加到 CPU 中，导致在没有过度开销的情况下操作严格的浮点语义，因此不再有默认和严格语义的动机。

Java 17 删除了以前的默认语义，所有浮点运算现在都严格执行。该关键字strictfp仍然存在，但没有效果并产生编译时警告。

• 删除实验性 AOT 和 JIT 编译器

删除实验性的基于 Java 的提前 (AOT) 和即时 (JIT) 编译器。该编译器自推出以来几乎没有什么用处，维护它所需的工作量很大。

Java 9 引入了提前 (AOT) 编译作为使用 Graal 编译器（一种用 Java 编写的 JIT 编译器）的实验性功能。Java 10 使用添加的 JVMCI 接口使 Graal 编译器可用作 OpenJDK 中的 JIT 编译器。

在JEP 410 中，AOT 和 JIT 编译器已被删除。

• 删除RMI 激活

RMI Activation 在JEP 407 中被删除，在 Java 8 中成为可选的，最终在 Java 15 中被弃用并标记为删除。 RMI Activation 启用了一种通过 RMI 激活分布式对象按需资源的方法，但几乎没有用，并且今天存在更好的替代方案。RMI 的其余部分不受激活部分的影响。

• 删除Applet API

Applet API 终于在JEP 398 中被标记为删除，它之前在 Java 9 中被弃用。 Applet API 提供了一种将 Java AWT/Swing 控件嵌入到浏览器网页中的方法，但今天没有现代浏览器支持这一点，所以在过去十年或更长时间里，Applet 基本上是无关紧要的。

• 弃用安全管理器

毫无疑问，最大的弃用是安全管理器（JEP 411）。安全管理器自 Java 1.0 以来一直存在，通常旨在限制 Java 可以在本地机器上执行的操作，例如限制对文件、网络等的访问，或通过禁止使用反射来尝试沙箱不可信代码，以及某些 API。

安全管理器的弃用始于 Java 12，其中添加了一个禁止使用它的命令行参数，从 Java 18 开始，该命令行参数将默认为禁止在运行时设置安全管理器。Java 17 中的更改意味着在尝试从命令行或在运行时动态设置安全管理器时，JVM 将产生运行时警告。

孵化器和预览功能

许多人想知道 Java 17 是否会有任何孵化器和预览功能，因为它被提升为一个长期支持的版本，并且可能支持一个改变或长时间没有被淘汰的功能似乎是不明智的。但是我们来了，Java 17 有两个孵化器模块和一个预览语言功能！

• Vector API

Vector API ( JEP 414 ) 正在经历其第二个孵化器阶段。该 API 使开发人员能够表达向量计算，然后 JIT 编译器可以将其编译为运行 JVM 的 CPU 架构所支持的适当向量指令（例如，利用 SSE 和 AVX 指令集）。

以前，开发人员要么必须依赖标量操作，要么必须使用/开发特定于平台的本机库。在 Java 中实现 Vector API 还可以为当前架构没有必要指令的事物提供优雅的回退，而是必须回退以以不同的方式计算。

虽然不是此 JEP 的一部分，但 Vector API 的标准化也使 JDK 中的类能够使用它。诸如 Arrays.mismatch 之类的方法，如今在某些平台上具有固有的矢量化实现，可以重写以使其全部在 Java 中运行，从而无需在 JVM 中编写和维护多个特定于平台的实现。

• 外部函数和内存 API

另一个孵化器模块是外来函数和内存 API ( JEP 412 )，它在技术上是 Java 16 中两个先前孵化器模块的合并和演变：外来链接器 API ( JEP 389 ) 和外来内存访问 API ( JEP 393 )。这两个组合允许使用用 Java 编写的静态类型代码访问本机代码和内存的方法，目的是能够在这种情况下取​代 JNI 的使用。

• Switch模式匹配

Java 17 中的最后一个语言预览功能是包含用于 switch 的模式匹配 ( JEP 406 )。此语言功能扩展了 switch 表达式和语句，使其还能够基于类型进行 switch，类似于模式匹配引入的 instanceof ( JEP 394 )语法，该语法在 Java 16 中标准化。

以前，如果您想根据对象的动态类型执行不同的操作，您需要使用 instanceof 检查创建一个 if-else if 链，例如：

结合使用 switch 表达式和 switch 的新模式匹配，它可以简化为：

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com