提示的错误信息： INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project core-java-9: Compilation failure [ERROR] exporting a package from system module java.base is not allowed with --release [ERROR] [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn <args> -rf :core-java-9     问题和解决 出现上面错误的原因是 JDK9 开始，–release 和 --add-exports 参数不能同时使用。 在我们的项目编译的时候添加了 --add-exports 参数。 这个会在 JDK 9 的时候报错。     我们可以把这个参数从编译环境中删除。   https://www.isharkfly.com/t/java-release/15702

作为 IT 搬砖人，一直都认为键盘没有什么太大关系。 每次都是公司发什么用什么。     但随着用几年后，发现现在的键盘经常出问题，比如说调节音量的时候通常莫名其妙的卡死，要不就是最大音量要不就是最小音量。 按键 M 不知道什么原因巨难按下去，有时候还感觉莫名其妙的卡在哪里。 回想这么多年，用的都是 104 键，一直没有来得及用什么比较好的机械键盘，随后发现键盘这东西就应该是生产力工具，不好的键盘确实有点感觉影响心情，遂决定换个键盘。 选型 正是对罗技见面的一些些失望，所以就先给看看有什么比较好的选项。 键盘用途：键盘的主要用途是工作需要，基本上不玩游戏，所以，游戏键盘就在考虑范围之内了，同时也并不需要类似游戏键盘的那种炫酷灯光。 连通性：随时可能需要会联通 iPad 和电脑，主流编程使用的计算机是 Windows 的计算机，不太希望使用 2.4G 的接收器，因为这个 2.4 G的接收器还需要占据一个 USB 接口。上网刷评测的时候说在连通性上，有线的肯定是要好过于无线的，但日常的工作就是调试程序，输入文本和邮件沟通。这种延迟对应该不会构成任何影响。简单点来说就是需要具有无线联通能力。 手感：已经有点受够了罗技这种普通键盘的手感了，想换下机械键盘。还记得读书的那个时候感觉都是机械键盘的天下和带轨迹球的鼠标，现在全是光电鼠标了，绕了一圈又绕回去了。 真是时间是一个挺有意思的东西，用了一圈居然又用回去了。 罗技 如果说考虑键盘就不得不说罗技这个牌子了。 用过的很多键盘都是罗技的，主要是性能比较稳定，兼容性没有问题，随便插上就能用，同时也因为家里和公司用的都是这个牌子，键盘鼠标换用也很方便。 这次主要原因也是罗技的键盘出了问题，所以想着就能不能抛开这牌子换一个牌子看看。 罗技也又机械键盘，上面的价格在 179 美元左右，叫做 MX 机械键盘系列。 MX Mechanical大概不是机械键盘里的顶格产品。但是MX Mechanical的优势在于对罗技生态的兼容性极佳，Options+Flow使用体验还是非常棒的。如果你使用的是罗技办公鼠标尤其是MX系列的旗舰办公鼠标的话，这个吸引力会非常大。 NuPhy 这个键盘应该就是在高颜值上，每款做得都非常漂亮。 对我们这种工科屌丝来说可能吸引并不是很大。     不过从官网上发的图片来看，每款都是那么炫酷。 HHKB 这个牌子还是最近在搜索键盘的时候才记起来还有这么个牌子。 最主要的是在日本以外的市场不是那么好买，更重要的是这个价格还是有点高的。如果不是特别发烧的这种级别，可能大部分人都不会入手这个牌子。 更何况这个键盘本身就是小键盘，对一般的使用者来说还是有一定的使用曲线的，不是和其他键盘都一样拿来就能用的那种。 可能还真是念旧了，第一眼居然是看上了 HHKB，而且还选的是和最古老的机械键盘相同的颜色布局。 下单 纠结了一顿饭的时间，决定下单 HHKB。 亚马逊上的价格是 299，然后查询了下官网，官网的价格也是 299。 本着多一事不如少一事的想法，就官网下单了，如果不着急的话，可以选择免邮费，就是时间长点。     有一种 3000 块钱的包可以买，1 块钱的邮费绝对不能出的感觉。 虽然有输入 Coupon 折扣码的地方，但 Google 到处找了下都没有找到可用的 Coupon，感觉就是压根不打算打折的意思。 有点过分了。 收到键盘时候的样子。     是非常简单的包装盒，说以前是有键帽拔除器的，现在这个也没有了，貌似也省掉了。   有点找到了大学时候学习计算机的感觉。     收到键盘后的第一件事情 收到键盘后的第一件时间就是调整 DIP。 本文提及的键盘配置方案，适用于包括 HHKB Pro 2 在内的大部分现役产品。 对 HHKB 机身后方的六个开关，我推荐使用如下的配置： Windows: 开启 1 3 4 号开关 MacOS: 开启 2 3 4 号开关 第 6 号开关是自动休眠。 关于自动休眠的情况就是，如果设置了自动休眠，那么休眠的时间是 30 分钟，当键盘休眠 后，不能通过敲打任何键盘的方式重新进行连接。 经过我的试验，是需要重新摁一下电源键才能重新打开电源。 如果第 6 号开关设置为 ON 的话，那么就不会对键盘进行休眠。唯一的问题就是电源消耗更快。 对我们的日常使用来说，应该还是需要把这个开关设置为不要休眠。 Windows 和 Mac 的模式 有关 Windows 和 Mac 模式的区别上，可以看看这个表。     从表里面可以看出来，HHKB 键盘对 Mac 的电脑兼容更多的模式。 主要区别就是对比 Windows 模式而言，Mac 的模式还多了一个对电源的控制。 可以通过 HHKB 的功能键对电源进行控制，Windows 模式下，没有这个功能。   https://www.isharkfly.com/t/topic/15659

完整的错误信息为： [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.3.1:resources (default-resources) on project core-java-io: filtering C:\WorkDir\Repository\iSharkfly-Docs\java-tutorials\core-java-modules\core-java-io\src\main\resources\dirCompressed.zip to C:\WorkDir\Repository\iSharkfly-Docs\java-tutorials\core-java-modules\core-java-io\target\classes\dirCompressed.zip failed with MalformedInputException: Input length = 1 -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn <args> -rf :core-java-io     问题和解决 出现上面错误的原因是在资源文件进行拷贝的时候的校验问题。 我们需要拷贝一个 zip 的资源文件，但是 Maven 在拷贝的时候会进行校验，这会导致拷贝失败。 所以我们可以添加配置： <nonFilteredFileExtensions> <nonFilteredFileExtension>zip</nonFilteredFileExtension> </nonFilteredFileExtensions> 到 插件 maven-resources-plugin 中。 添加后的完整插件配置为： <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-resources-plugin</artifactId> <version>${maven-resources-plugin.version}</version> <configuration> <encoding>UTF-8</encoding> <nonFilteredFileExtensions> <nonFilteredFileExtension>zip</nonFilteredFileExtension> </nonFilteredFileExtensions> </configuration> </plugin>     当完成上面的配置后，资源文件就可以顺利在编译的时候拷贝了。   https://www.isharkfly.com/t/java-maven-dircompressed-zip-failed-with-malformedinputexception/15694

错误的信息为： [ERROR] Failed to execute goal on project image-processing: Could not resolve dependencies for project com.ossez:image-processing:jar:0.0.2-SNAPSHOT: Failed to collect dependencies at org.openimaj:core-image:jar:1.3.10 -> org.op enimaj:core:jar:1.3.10 -> vigna.dsi.unimi.it:jal:jar:20031117: Failed to read artifact descriptor for vigna.dsi.unimi.it:jal:jar:20031117: The following artifacts could not be resolved: vigna.dsi.unimi.it:jal:pom:20031117 (absen t): Could not transfer artifact vigna.dsi.unimi.it:jal:pom:20031117 from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [openimaj-maven (http://maven.openimaj.org/, default, releases+snapshots), openimaj-snapshots-maven (http://snapshots.openimaj.org/, default, releases+snapshots)] -> [Help 1]     问题和解决 错误的原因在于 ：vigna.dsi.unimi.it:jal:jar:20031117 这个包没有找到。 这个包的仓库地址为：ICM Repository （http://maven.icm.edu.pl/artifactory/repo/） 需要把这个仓库添加到项目中。   https://www.isharkfly.com/t/java-image-processing/15691  

提示的具体信息为： [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.3.1:resources (default-resources) on project core-java-8: filtering C:\WorkDir\Repository\iSharkfly-Docs\java-tutorials\core-java-modules\core-java -8\src\main\resources\formats_fr.properties to C:\WorkDir\Repository\iSharkfly-Docs\java-tutorials\core-java-modules\core-java-8\target\classes\formats_fr.properties failed with MalformedInputException: Input length = 1 -> [Help 1]     问题和解决 上面提示的错误原因在于属性文件使用了非英语字符，但是属性文件没有使用 UTF-8 编码。 这会导致程序识别的错误。     检查属性文件的编码格式，需要修改为 UTF-8 编码。   https://www.isharkfly.com/t/java-maven/15690

概述 在本文中，我们将会 对 UUIDs 和基于时间的 UUIDs（time-based UUIDs） 进行一些探讨。 当我们在对基于时间的 UUIDs 进行选择的时候，总会遇到一些好的方面和不好的方面，如何进行选择，也是我们将要简要探讨的内容。 同时我们还会对可能会使用类库进行一些比较和探索，以便于我们更好的做出选择。 UUIDs 和 基于时间的 UUIDs UUID 的全称是 Universally Unique Identifier，中文为通用唯一识别码。 当生成 UUID 的时候，系统总会自动生成一个 128 位的 UUID。基于 UUID 的生产算法的不同，我们会有不同的版本。 UUID 的主要目的就是用来在全世界中唯一标识一个数据，而且需要保证生成的 UUID 在全世界范围内是不重复的。因此我们可以用来标识一个上下文，包括数据库系统，计算机系统中的消息，分布式系统中的对象等等。 为了实现这个目标，我们需要确保哪怕是在同一个时间瞬间生成的 UUID 也是不相同，这样能够让我们更好的利用 UUID 在分布式计算机系统中标识存在的对象。 基于时间的 UUID，通过字面就可以了解到，这个 UUID 是基于时间的，实际上这个 UUID 存在 UUID 设计中的第一版。 这个版本是基于随机数的，使用的基数为每 100 纳秒为一个单位，时间的起点为1582年10月15日。同时还需要加上当前计算机的网卡物理地址（MAC）。 在后续的版本中，UUID （v6 和 v7）也是基于时间的 UUID 生成算法，可以说是基于 UUID v1 的更新版本。 UUID v1 因为是基于时间的，所以具有排序功能，这个在对数据库的设计上就很有帮助，当我们使用 UUID v1 来作为 PK（主键）的时候，我们就知道了，我们创建的这条记录的时间戳是什么时候，这个对我们在对数据进行调试和问题分析的时候就很有帮助了。 有优势就自然会有劣势，因为我们是基于时间创建 UUID 的，那么在同一个系统产生 UUID 冲突的可能性就会大很多，假设在同一个时间点，我们创建了很多个 UUID，那么大概率就会有出现冲突，重复出现的情况。 在本文的后部分，我们会对这个可能出现的情况进行一些探索。 另外一个原因，就是在 UUID v1 版本中使用主机地址这种做法会潜在的增加系统的安全性问题。这就是 UUID v6 尝试希望解决的问题。 对比程序 为了对可能出现的 UUID 冲突进行演示。我们尝试使用程序来对比可能出现 UUID 冲突的可能性。 这个程序，将会创建 128 个线程，在每个线程中将会生成 100,000 个 UUID。 首先我们对需要使用的变量来进行一些初始化： int threadCount = 128; int iterationCount = 100_000; Map<UUID, Long> uuidMap = new ConcurrentHashMap<>(); AtomicLong collisionCount = new AtomicLong(); long startNanos = System.nanoTime(); CountDownLatch endLatch = new CountDownLatch(threadCount); 如上面的程序所表示的内容，我们定义了 128 个线程，在这 128 个线程中，我们会循环 100,000 次。 同时，我们还初始化了一个 ConcurentHashMap 把我们生成的 UUID 存储到 ConcurentHashMap 中。 同时，我们还会记录出现 UUID 冲突的次数。 为了记录程序的性能，我们对程序开始时间和程序的结束也都进行了存储。在最后我们定义了一个 latch 等待所有线程的执行完成。 当定义完成后变量后，我们就需要启动线程并对线程序进行执行。 for (long i = 0; i < threadCount; i++) { long threadId = i; new Thread(() -> { for (long j = 0; j < iterationCount; j++) { UUID uuid = Generators.timeBasedGenerator().generate(); Long existingUUID = uuidMap.put(uuid, (threadId * iterationCount) + j); if(existingUUID != null) { collisionCount.incrementAndGet(); } } endLatch.countDown(); }).start(); } 在 UUID 的创建过程中，我们使用了 fasterxml 包中的 Generators，这个 Generators 使用的是 java.util.UUID 类来创建的。 在创建 UUID v1 的使用，使用 fasterxml 是我们常用的做法。 当 UUID 创建后，我们就把创建好的 UUID 存储到 Map 中，UUID 为 map 的 Key，当我们的 UUID 重复出现冲突的时候，Map 将会提示错误，我们程序就会捕获这个错误，然后把出现错误的计数器 + 1。 endLatch.await(); System.out.println(threadCount * iterationCount + " UUIDs generated, " + collisionCount + " collisions in " + TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startNanos) + "ms"); 在程序的最后，CountDownLatch 的 await() 方法会等待所有的线程完成。 当所有线程完成后，我们就会把结果打印在计算机屏幕上。 下面就让我们开始对程序进行运行。 12800000 UUIDs generated, 0 collisions in 16913ms 上面出现了程序的运行结果，我们可以看到并没有出现…

概述 使用 Base64 编码来对 UUID（Universally Unique Identifiers） 存储在一些特定的场合被广泛的使用。使用 Base64 对比直接使用 UUID 进行存储来说能够更多的节约空间。   本文对这方面的相关内容和问题进行探讨。   在这里，使用 Base64 来对 UUID 进行存储，涉及到一些类型的转换的。Base64 是编码算法，在实际使用的时候我们更多会用到 Byte 数组的方式来进行编码的。这样我们就比较明确在对其进行 Base64 转换之前，我们应该要先干什么了。 使用 byte[] 和 Base64.Encoder Base64.Encoder 就能够提供 byte[] 的 Base64 编码了，我们先使用这个最简单的方式来进行处理。 编码 首先我们需要给出的 UUID 位中创建出我们需要的 byte 数组。 我们先获得 UUID 的 most significant bits 和 least significant bits，然后放入我们 byte 数组中的 0-7 和 8-15 的位置。 程序代码如下： private byte[] convertToByteArray(UUID uuid) { byte[] result = new byte[16]; long mostSignificantBits = uuid.getMostSignificantBits(); fillByteArray(0, 8, result, mostSignificantBits); long leastSignificantBits = uuid.getLeastSignificantBits(); fillByteArray(8, 16, result, leastSignificantBits); return result; } 上面的代码中还有一个 fillByteArray 方法，这个方法，这个方法将会把我们的 bit 存如 byte array 数组中，同时还会移动 8 位。 方法的代码如下： void fillByteArray(int start, int end, byte[] result, long bits) { for (int i = start; i < end; i++) { int shift = i * 8; result[i] = (byte) ((int) (255L & bits >> shift)); } } 当我们获得 byte 数组后，我们就可以调用 JDK 的 Base64.Encoder 方法来直接进行编码了成一个 Base64 加密字符串了。 完整的测试代码如下： UUID originalUUID = UUID.fromString("cc5f93f7-8cf1-4a51-83c6-e740313a0c6c"); @Test void givenEncodedString_whenDecodingUsingBase64Decoder_thenGiveExpectedUUID() { String expectedEncodedString = "UUrxjPeTX8xsDDoxQOfGgw=="; byte[] uuidBytes = convertToByteArray(originalUUID); String encodedUUID = Base64.getEncoder().encodeToString(uuidBytes); assertEquals(expectedEncodedString, encodedUUID); } 解码 把我们获得的 UUID Base64 字符串进行解码，我们可以使用完全相反的方法： @Test public void givenEncodedString_whenDecodingUsingBase64Decoder_thenGiveExpectedUUID() { String expectedEncodedString = "UUrxjPeTX8xsDDoxQOfGgw=="; byte[] decodedBytes = Base64.getDecoder().decode(expectedEncodedString); UUID uuid = convertToUUID(decodedBytes); } 首先把 Base64 字符串解码成 Byte 数组，然后调用我们的转换方法，把我们获得 byte 数组转换成为 UUID 对象。 UUID convertToUUID(byte[] src) { long mostSignificantBits = convertBytesToLong(src, 0); long leastSignificantBits = convertBytesToLong(src, 8); return new UUID(mostSignificantBits, leastSignificantBits); } 在上面的方法中，我们分别对 UUID 中需要使用的 most significant bits 和 less significant bits 分别进行转换，然后再组合在一起。 转换的方法如下： long convertBytesToLong(byte[] uuidBytes, int start) { long result = 0; for(int i = 0; i < 8; i++) { int shift = i * 8; long bits = (255L & (long)uuidBytes[i + start]) <<…

getMostSignificantBits() 方法的一些介绍： getMostSignificantBits 这个方法主要用于在 UUID 中获取高64 位的有效位后返回 Long 数据类型。 在获取最高有效位时不会引发异常。 对应的还有一个 getLeastSignificantBits() 方法。 这个方式是从 UUID 中获取低 64 位的有效位返回 Long数据类型。 如查看 UUID 的数据结构，我们能看到 UUID 是拆分 2 部分的。 https://www.isharkfly.com/t/java-uuid-getmostsignificantbits-leastsignificantbits/15683

UUID 是有多个版本的，如何查看 UUID 是那个版本，可以用 UUID 对象中的 version() 方法。 创建 UUID 对象： UID originalUUID = UUID.fromString("cc5f93f7-8cf1-4a51-83c6-e740313a0c6c"); uuid.version(); 上面方法显示 UUID 的版本为 4。 Version 4 （基于随机数） UUID-v4 组成 UUID v4 的位是随机生成的，没有固有逻辑（除了第三段首个数字，该数字标识版本号），不包含命名空间、设备信息、时间信息。 故，UUID-v4 最容易理解、应用也最为广泛。   https://www.isharkfly.com/t/uuid/15684

概述 在本文中，我们将会对 Java 特性预览背后的动机进行一些探索，对比当前使用 Java 的版本提供了哪些实验性的功能，以及如何在不同的 IDE 工具中启用这个功能。 为什么使用特性预览 如你对 Java 版本的发行计划不太熟悉的话，那么需要了解的是 Java 目前是每 6 个月将会发行一个版本。在发行新的版本的时候会提供一些新的特性。 Java 特性预览这个功能，将能够让用户提前了解一些 Java 将会在新版本中使用的功能，同时也能让 Java 团队能够更多的获得用户的反馈意见。 我们都知道 Java 被在很多大中小系统中使用，哪怕是实现中的一点点瑕疵或者糟糕的糟糕的设计都会带来很多意想不到情况和损失。 又因 Java 系统的广泛应用，这种损失通常是非常巨大的。 如何能够确保每一个发行的 Java 版本能够稳定的发布和升级，同时也能够满足 Java 社区的需要就成了一个问题。 针对 JEP-12 的改进，Java 提供了针对 VM（虚拟机）和语言特性的预览功能。通过这种方式 Java 社区能够在环境中直接测试新的功能，同时这些功能也不会影响到服务器的开发和使用。 Java 团队会基于社区中的反馈而对预览的功能会进行一些调整，同时会针对后续的发行版本而对提供的新的特性进行多次修改。 在最后，新特性可能会成为官方正式的发布版本，当然提供的一些新特性可能会在后续的官方正式发布版本中被完全的删除。 预览一些实验性特性 Java 的预览特性是针对正在开发中的特性，并且这些特性还在接受评估。所以这些特性还没有完全确定，所以很多特性可能会在新的发行版本中出现，当然很多也可能会被完全抛弃。 正是因为 Java 对品质的要求，针对 JDK 的不版本的实现，都会要求在 JDK 发布的时候同时也包含有实验性的特性预览。但是，针对最后的发布版本，这种实验性的预览功能是不会提供的。 特性预览只是让 Java 社区提前知道 Java 团队目前正在干什么和计划要干什么的一种方式。需要明确的是，不要把这些可能还会删掉的特性和功能包含到你的发行版本中。 下面是 JEP-12 有关预览特性的定义，官方的链接地址在：https://openjdk.org/jeps/12。 如你有兴趣的话，可以直接阅读官方的原文。 使用预览特性 Java 预览特性在默认情况下是关闭的。为了启用这个功能，我们必须使用启用预览参数，使用这个参数将会把所有的特性一次性全部启用。 Java 编译器（JVM）和 Java 的版本必须保持一致。 让我们来尝试使用 JDK 13 中提供的 String 字符串块功能。 String query = """ SELECT 'Hello World' FROM DUAL; """; System.out.println(query); 上面的功能只能够在 JDK 13 及其后续版本中使用，所以为了使用这个功能，你需要安装 JDK 13 到你的计算机中。 使用 Eclipse 如果拷贝上面的代码到 Eclipse 中，你的 Eclipse 是不会进行进行正确编译的，在编译的过程中将会提示代码错误。 提示的内容是：如果需要这个功能请使用 JDK 13 的 String 字符串块功能。 这个时候，我们在我们的项目中单击右键，然后在弹出的菜单中选择属性。 然后进入到 Java 编辑器，这个时候我们就可以为我们的这个项目或者整个 Workspace 启用预览特性。 同时，我们还不能选择 使用默认编译器设置（Use default compliance settings）这个选项，这样可以让我们能够对 Java 13 的特性进行预览。 因目前我们使用的编译器版本比较高，为 JDK 17 的版本，所以在预览选项这里就只能对 JDK 21 的版本进行预览了。     IntelliJ IDEA 针对使用不同的 IDE，我们也希望我们的预览功能能够在 IDEA 中也可以使用。 与 Eclipse 相同，IDEA 也有这个方面的配置，你只需要在 IDEA 中修改配置即可。 配置是在语言结构上。 单击语言结构上的 SDK 默认，往下拉，就可以看到针对新版本的选项。     同时还可以看到那些版本是支持新特性预览的，那些版本是不支持新特性预览的。 整体来说，IntelliJ IDEA 的新特性预览功能做得要比 Eclipse 更好一些。 Maven 针对 Maven 项目，因 Maven 项目的配置都会依赖 pom.xml 来进行，对 IDE 的修改，可能在某些时候没有效果。 如果是这个情况的话，那你需要打开你的 pom.xml 文件，在 pom.xml 文件中找到针对编译有关的插件配置，然后再插件配置中添加 compilerArgs 参数。 具体的示例如下： <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>13</source> <target>13</target> <compilerArgs> --enable-preview </compilerArgs> </configuration> </plugin> </plugins> </build> 针对上面的修改，同样也能让你的 IDE 能够识别到。 使用命令行 在编译期间，Java 有 2 个参数来控制启用预览的功能，请参考下面的编译命令： javac --release 13 --enable-preview ClassUsingTextBlocks.java 如果当前使用的 JDK 版本是不支持的预览功能的，那么使用上面的命令将会得到错误的提示。 例如 JDK 14 的版本是不支持预览的，在命令行中，如果我们把命令行的中的 13 替换成 14 的话，都那么编译器将会提示我们错误。 在实际的开发环境中，在命令行中使用预览功能的可能性非常小，设置我们都不会使用命令行的方式来编译我们的 Java 代码。 上面提出这种编译方式的目的就是告诉大家，我们还是有这个选项的，主要还是能够让大家了解我们是有这 2 个参数提供的。 在运行时，Java 只需要 enable-preview 参数就可以启用预览功能。 java --enable-preview ClassUsingTextBlocks 需要注意的是，在这里如果你的 JDK 版本和预览的版本不匹配的话，你的程序是没有办法运行的。 结论 在本篇文章中我们主要针对 Java 提供的特性预览功能进行了一些讨论。 在实际使用的时候，我们确实也会遇到一些，这些情况就是项目使用的 JDK 版本比较低，但是下载的 JDK 编译的 Jar 包版本又比较高，这就导致了无法编译的情况。 我们会考虑使用 Java 的预览功能来查看下代码的兼容性。 比如说，当前项目使用的 JDK 版本为 8，但是我们项目中的一个依赖却使用了 JDK 11 来编译了包，所以我们可能会把我们的编译器版本提升下到 JDK 11 来查看代码的兼容情况。 如你只是针对自己的项目的话，Java 新特性功能用得就比较少，主要是对架构师而言，他们需要确定下代码的兼容性，以便于在对 JDK 是否可以进行升级上做出判断。   https://www.isharkfly.com/t/java/15682