Log for YSITD
#content {
margin-top:20px;
margin-left:20px;
margin-right:20px;
margin-bottom:20px;
border: 1px solid 000000;
}
margin-top:20px;
margin-left:20px;
margin-right:20px;
margin-bottom:20px;
border: 1px solid 000000;
}
假設在搜尋框輸入 test
然後按下 Enter
我的想法是他會到：
www.google.com/search?q=test
所以大概就是這樣：
使用者輸入字串之後按下 Enter
將會導向到 www.google.com/search?q=(字串)
要怎麼實現？
然後按下 Enter
我的想法是他會到：
www.google.com/search?q=test
所以大概就是這樣：
使用者輸入字串之後按下 Enter
將會導向到 www.google.com/search?q=(字串)
要怎麼實現？
那我離個題
PHP5->PHP7砍了一堆5就要砍的舊東西
這時一堆人來罵7亂砍東西你說合理嗎?
Arch更新了 但他也公告了 而且也不是今天公告明天就改
我覺得你用了一個東西要知道他怎用
更新時他改了什麼是使用者的義務
不然我建議你買服務 讓人把你的東西處理的好好的
PHP5->PHP7砍了一堆5就要砍的舊東西
這時一堆人來罵7亂砍東西你說合理嗎?
Arch更新了 但他也公告了 而且也不是今天公告明天就改
我覺得你用了一個東西要知道他怎用
更新時他改了什麼是使用者的義務
不然我建議你買服務 讓人把你的東西處理的好好的
@koru1130 你要不要試試看在windows安裝firefox chromium obs ffmpeg mpv vs_code libreoffice java hexchat 和在linux上那個比較快比較方便好用
现在我也来离个题
如果有天 Windows 变得更加开源了，大量的 Linux 用户进来。你感觉到 Windows 变了，变得更加稳定了，感觉 Windows 内部的架构明朗了许多，你觉得更有信心了。信心来自哪里呢？来自于你理解整个架构。有天你如期更新了，却发现到你开机不能，开机了也辨别不到你所安装的程序，你很疑惑，究竟你干了什么，找来找去也找不到问题，你才发现官网通告说 “肥肠抱歉，我们更新了你的东西，你应该 xxxx 做"。啊啦！你修好了，你就吐槽 Windows 系统做到很烂，烂在更新包竟然会导致你的系统不正常运作。啊竟然没有做到更新 bugfixes 也没有分离配置…… 这样那样客观的建议。
结果被一群 Linux 派的精英主义分子抨击说，用 Arch 的说"RTFM 啦，官网不是写了吗？活该！"，Kernel developers 说 “你看看你，竟然不看看 patch 就更新，活该“, Crux Linux 的说 "你应该用了假的包管理器吧？"， Windows 的官方回答说：“我们都写了官方通告了，连解决方案都写了，还做了好人，更新了 Manual, 你的问题你家的事“
如果有天 Windows 变得更加开源了，大量的 Linux 用户进来。你感觉到 Windows 变了，变得更加稳定了，感觉 Windows 内部的架构明朗了许多，你觉得更有信心了。信心来自哪里呢？来自于你理解整个架构。有天你如期更新了，却发现到你开机不能，开机了也辨别不到你所安装的程序，你很疑惑，究竟你干了什么，找来找去也找不到问题，你才发现官网通告说 “肥肠抱歉，我们更新了你的东西，你应该 xxxx 做"。啊啦！你修好了，你就吐槽 Windows 系统做到很烂，烂在更新包竟然会导致你的系统不正常运作。啊竟然没有做到更新 bugfixes 也没有分离配置…… 这样那样客观的建议。
结果被一群 Linux 派的精英主义分子抨击说，用 Arch 的说"RTFM 啦，官网不是写了吗？活该！"，Kernel developers 说 “你看看你，竟然不看看 patch 就更新，活该“, Crux Linux 的说 "你应该用了假的包管理器吧？"， Windows 的官方回答说：“我们都写了官方通告了，连解决方案都写了，还做了好人，更新了 Manual, 你的问题你家的事“
<!DOCTYPE html>
<html lang="en">
<head>
<!-- byStarTW 製作範本 -->
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<!-- Tocas UI：CSS 與元件 -->
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/tocas-ui/2.3.3/tocas.css">
<!-- Tocas JS：模塊與 JavaScript 函式 -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/tocas-ui/2.3.3/tocas.js"></script>
<title> {網站標題} </title>
<!-- Tocas UI: 自適應設定 -->
<style type="text/css">
html {
margin-top:20px;
border: 1px solid 000000;
font-size: 16px;
}
// 在行動裝置上將字體轉換成 `14px` 大小。
@media (max-width: 768px) {
html {
font-size: 14px;
}
}
</style>
</head>
<body>
<div class="ts narrow container">
<!-- 網站主體 -->
<!-- 網站編碼請設定為 UTF-8-->
<!-- 請善用 Tocas UI 的範例 & 素材 -->
</div>
</body>
</html>WordPress某一些第三方插件因此關閉，雖然對我來說沒有差
但架構大轉換在Firefox，有很多插件作者不滿覺得要重寫，因此宣布棄坑(新程式碼做得到但作者不爽開發)
但架構大轉換在Firefox，有很多插件作者不滿覺得要重寫，因此宣布棄坑(新程式碼做得到但作者不爽開發)
JRE下的rt.jar:
这个文件是极为重要的一个文件，rt是runtime的缩写，即运行时的意思。是java程序在运行时必不可少的文件。
里面包含了java程序员常用的包，如java.lang，java.util，java.io，java.net,java.applet等
1. rt.jar 默认就在 根classloader的加载路径里面 放在claspath是多此一举
不信你可以去掉classpath里面的rt.jar
然后用 java -verbose XXXX 的方式运行一个简单的类 就知道 JVM的系统根Loader的路径里面 不光rt.jar jre/lib下面的大部分jar 都在这个路径里
这个文件是极为重要的一个文件，rt是runtime的缩写，即运行时的意思。是java程序在运行时必不可少的文件。
里面包含了java程序员常用的包，如java.lang，java.util，java.io，java.net,java.applet等
1. rt.jar 默认就在 根classloader的加载路径里面 放在claspath是多此一举
不信你可以去掉classpath里面的rt.jar
然后用 java -verbose XXXX 的方式运行一个简单的类 就知道 JVM的系统根Loader的路径里面 不光rt.jar jre/lib下面的大部分jar 都在这个路径里
The problem is that Java 9 JDK has different file structure, e.g. tools.jar and rt.jar
are completely gone. These files are used by the IDEs to work with JDK. From this articles it seems IntelliJ Idea does not support Java 9:
https://youtrack.jetbrains.com/issue/IDEA-145206
are completely gone. These files are used by the IDEs to work with JDK. From this articles it seems IntelliJ Idea does not support Java 9:
https://youtrack.jetbrains.com/issue/IDEA-145206
Q每周精要。
马上订阅

中文
Java 9终于要包含Jigsaw项目了 1喜欢
登陆InfoQ，与你最关心的话题互动。
E-mail
密码
使用Google账号登录使用Microsoft账号登录使用Weibo账号登录
忘记密码？没有帐号？立即注册


关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。

内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。

获取更新
设置通知机制以获取内容更新对您而言是否重要
作者 Nicolai Parlog ，译者 张卫滨 发布于 2016年2月3日
估计阅读时间: 2 分钟
添加至阅
读列表
查看我的
阅读列表
当Jigsaw在Java 9中最终发布时，这个项目的历史已经超过八年了。
在最初的几年中，它必须要与另外两个类似的Java规范请求（Java Specification Request）进行竞争，这两个规范名为JSR 277 Java模块系统（Java Module System）以及JSR 294 增强的模块化支持（Improved Modularity Support）。它还导致了与OSGi社区的冲突，人们担心Jigsaw项目会成为不必要且不完备的功能性重复，逼迫Java开发人员必须在两种互不兼容的模块系统中做出选择。
在早期，这个项目并没有充足的人手，在2010年Sun并入Oracle的时候，甚至一度中断。直到2011年，在Java中需要模块系统的强烈需求被重申，这项工作才得到完全恢复。
接下来的三年是一个探索的阶段，结束于2014年的7月，当时建立了多项Java增强提议（ Java Enhancement Proposal），包括JEP 200 模块化JDK（Modular JDK）、JEP 201 模块化源码（Modular Source Code）和JEP 220 模块化运行时镜像（Modular Run-Time Image），以及最终的JSR 376 Java平台模块系统（Java Platform Module System）。上述的最后一项定义了真正的Java模块系统，它将会在JDK中以一个新JEP的形式来实现。
在2015年7月，JDK划分为哪些模块已经大致确定（参见JEP 200），JDK的源码也进行了重构来适应这种变化（参见JEP 201），运行时镜像（run-time image）也为模块化做好了准备（参见JEP 220）。所有的这些都可以在当前JDK 9的预览版中看到。
针对JSR 376所开发的代码很快将会部署到JDK仓库中，但是令人遗憾的是，现在模块化系统本身尚无法体验。（目前，Java 9的预览版本已经包含了模块化功能。——译者注）
驱动力
在Jigsaw项目的历史中，它的驱动力也发生过一些变化。最初，它只是想模块化JDK。但是当人们意识到如果能够在库和应用程序的代码中也使用该工具的话，将会带来非常大的收益，于是它的范围得到了扩展。
不断增长且不可分割的Java运行时
Java运行时的大小在不断地增长。但是在Java 8之前，我们并没有办法安装JRE的子集。所有的Java安装包中都会包含各种库的分发版本，如XML、SQL以及Swing的API，不管我们是否需要它们，都要将其包含进来。
对于中等规模（如桌面PC和笔记本电脑）以上的计算设备来说，这不算是什么严重的问题，但是对于小型的设备来说，这就很严重了，比如在路由器、TV盒子和汽车上，还有其他使用Java的小地方。随着当前容器化的趋势，在服务器领域也有相关的要求，因为减少镜像的大小就意味着降低成本。
Java 8引入了 compact profile的功能，它们定义了三个Java SE的子集。在一定程度上缓解了这个问题，但是它们只有在严格限制的场景下才能发挥作用，profile过于死板，无法涵盖现在和未来所有使用JRE部分功能的需求。
JAR/Classpath地狱
JAR地狱和Classpath地狱是一种诙谐的说法，指的是Java类加载机制的缺陷所引发的问题。尤其是在大型的应用中，它们可能会以各种方式产生令人痛苦的问题。有一些问题是因为其他的问题而引发的，而有一些则是独立的。
无法表述依赖
JAR文件无法以一种JVM能够理解的方式来表述它依赖于哪些其他的JAR。因此，就需要用户手动识别并满足这些依赖，这要求用户阅读文档、找到正确的项目、下载JAR文件并将其添加到项目中。
而且，有一些依赖是可选的，只有用户在使用特定功能的特性时，某个JAR才会依赖另外一个JAR。这会使得这个过程更加复杂。
Java运行时在实际使用某项依赖之前，并不能探测到这个依赖是无法满足的。如果出现这种情况，将会出现NoClassDefFoundError异常，进而导致正在运行的应用崩溃。
像Maven这样的构建工具能够帮助解决这个问题。
传递性依赖
一个应用程序要运行起来可能只需依赖几个库就足够了，但是这些库又会需要一些其他的库。问题组合起来会变得更加复杂，在所消耗的体力以及出错的可能性上，它会呈指数级地增长。
同样，构建工具能够在这个问题上提供一些帮助。
遮蔽
有时候，在classpath的不同JAR包中可能会包含全限定名完全相同的类，比如我们使用同一个库的两个不同版本。因为类会从classpath中的第一个JAR包中加载，所以这个版本的变种将会“遮蔽”所有其他的版本，使它们变得不可用。
如果这些不同的变种在语义上有所差别，那将会导致各种级别的问题，从难以发现的不正常行为到非常严重的错误都是有可能的。更糟糕的是，问题的表现形式是不确定的。这取决于JAR文件在classpath中的顺序。在不同的环境下，可能也会有所区别，例如开发人员的IDE与代码最终运行的生产机器之间就可能有所差别。
版本冲突
如果项目中有两个所需的库依赖不同版本的第三个库，那么将会产生这个问题。
如果这个库的两个版本都添加到classpath中的话，那么最终的行为是不可预知的。首先，因为前面所述的遮蔽问题，两个版本的类中，只会有一个能够加载进来。更糟糕的是，如果某个类位于一个JAR包中，但是它所访问的其他类却不在这个包中，这个类也能够加载。所导致的结果就是，对这个库的代码调用将会混合在两个版本之中。
在最好的情况下，如果试图访问所加载的类中不存在的代码，将会导致明显的NoClassDefFoundError错误。但是在最坏的情况下，版本之间的差别仅仅是在语义上，实际的行为会有细微的差别，这会引入很难发现的bug。
识别这种情况所导致的难以预料的行为是很困难的，也无法直接解决。
复杂的类加载机制
默认情况下，所有的类由同一个ClassLoader负责加载，在有些场景下，可能有必要引入额外的加载器，例如允许用户加载新的类，对应用程序进行扩展。
这很快就会导致复杂的类加载机制，从而产生难以预期和难以理解的行为。
在包之间，只有很弱的封装机制
如果类位于同一个包中，那Java的可见性修饰符提供了一种很棒的方式来实现这些类之间的封装。但是，要跨越包之间边界的话，那只能使用一种可见性：public。
因为类加载器会将所有加载进来的包放在一起，public的类对其他所有的类都是可见的，因此，如果我们想创建一项功能，这项功能对某个JAR是可用的，而对于这个JAR之外是不可用的，这是没有办法实现的。
手动的安全性
包之间弱封装性所带来的一个直接结果就是，安全相关的功能将会暴露在同一个环境中的所有代码面前。这意味着，恶意代码有可能绕过安全限制，访问关键的功能。
从Java 1.1开始，有一种hack的方式，能够防止这种状况：每当进入安全相关的代码路径时，将会调用SecurityManager，并判断是不是允许访问。更精确地讲，它应该在每个这样的路径上都进行调用。过去，在有些地方遗漏了对它们的调用，从而出现了一些漏洞，这给Java带来了困扰。
启动性能
最后，Java运行时加载并JIT编译全部所需的类需要较长的时间。其中一个原因在于类加载机制会对classpath下的所有JAR执行线性的扫描。类似的，在识别某个注解的使用情况时，需要探查classpath下所有的类。
目标
Jigsaw项目的目标就是解决上面所述的问题，它会引入一个语言级别的机制，用来模块化大型的系统。这种机制将会用在JDK本身中，开发人员也可以将其用于自己的项目之中。
需要注意的是，对于JDK和我们开发人员来说，并不是所有的目标都具有相同的重要性。有一些与JDK具有更强的相关性，并且大多数都对日常的编程不会带来巨大的影响（这与最近的语言修改形成了对比，如lambda表达式和默认方法）。不过，它们依然会改变大型项目的开发和部署。
可扩展性的平台
JDK在模块化之后，用户就能挑出他们需要的功能，并创建自己的JRE，在这个JRE中只包含他们需要的模块。这有助于在小型设备和容器领域中，保持Java作为关键参与者的地位。
在这个提议的规范中，允许将Java SE平台及其实现分解为一组组件，开发人员可以把这些组件组装起来，形成自定义的配置，里面只包含应用实际需要的功能。—— JSR 376
可靠的配置
通过这个规范，某个模块能够声明对其他模块的依赖。运行时环境能够在编译期（compile-time）、构建期（build-time）以及启动期（launch-time）分析这些依赖，如果缺少依赖或依赖冲突的话，很快就会发生失败。
强封装
Jigsaw项目的一个主要目标就是让模块只导出特定的包，其他的包是模块私有的。
模块中的私有类就像是类中的私有域。换句话说，模块的边界不仅确定了类和接口的可见性，还定义了它的可访问性。——Mark Reinhol
马上订阅

中文
Java 9终于要包含Jigsaw项目了 1喜欢
登陆InfoQ，与你最关心的话题互动。
密码
使用Google账号登录使用Microsoft账号登录使用Weibo账号登录
忘记密码？没有帐号？立即注册


关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。

内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。

获取更新
设置通知机制以获取内容更新对您而言是否重要
作者 Nicolai Parlog ，译者 张卫滨 发布于 2016年2月3日
估计阅读时间: 2 分钟
添加至阅
读列表
查看我的
阅读列表
当Jigsaw在Java 9中最终发布时，这个项目的历史已经超过八年了。
在最初的几年中，它必须要与另外两个类似的Java规范请求（Java Specification Request）进行竞争，这两个规范名为JSR 277 Java模块系统（Java Module System）以及JSR 294 增强的模块化支持（Improved Modularity Support）。它还导致了与OSGi社区的冲突，人们担心Jigsaw项目会成为不必要且不完备的功能性重复，逼迫Java开发人员必须在两种互不兼容的模块系统中做出选择。
在早期，这个项目并没有充足的人手，在2010年Sun并入Oracle的时候，甚至一度中断。直到2011年，在Java中需要模块系统的强烈需求被重申，这项工作才得到完全恢复。
接下来的三年是一个探索的阶段，结束于2014年的7月，当时建立了多项Java增强提议（ Java Enhancement Proposal），包括JEP 200 模块化JDK（Modular JDK）、JEP 201 模块化源码（Modular Source Code）和JEP 220 模块化运行时镜像（Modular Run-Time Image），以及最终的JSR 376 Java平台模块系统（Java Platform Module System）。上述的最后一项定义了真正的Java模块系统，它将会在JDK中以一个新JEP的形式来实现。
在2015年7月，JDK划分为哪些模块已经大致确定（参见JEP 200），JDK的源码也进行了重构来适应这种变化（参见JEP 201），运行时镜像（run-time image）也为模块化做好了准备（参见JEP 220）。所有的这些都可以在当前JDK 9的预览版中看到。
针对JSR 376所开发的代码很快将会部署到JDK仓库中，但是令人遗憾的是，现在模块化系统本身尚无法体验。（目前，Java 9的预览版本已经包含了模块化功能。——译者注）
驱动力
在Jigsaw项目的历史中，它的驱动力也发生过一些变化。最初，它只是想模块化JDK。但是当人们意识到如果能够在库和应用程序的代码中也使用该工具的话，将会带来非常大的收益，于是它的范围得到了扩展。
不断增长且不可分割的Java运行时
Java运行时的大小在不断地增长。但是在Java 8之前，我们并没有办法安装JRE的子集。所有的Java安装包中都会包含各种库的分发版本，如XML、SQL以及Swing的API，不管我们是否需要它们，都要将其包含进来。
对于中等规模（如桌面PC和笔记本电脑）以上的计算设备来说，这不算是什么严重的问题，但是对于小型的设备来说，这就很严重了，比如在路由器、TV盒子和汽车上，还有其他使用Java的小地方。随着当前容器化的趋势，在服务器领域也有相关的要求，因为减少镜像的大小就意味着降低成本。
Java 8引入了 compact profile的功能，它们定义了三个Java SE的子集。在一定程度上缓解了这个问题，但是它们只有在严格限制的场景下才能发挥作用，profile过于死板，无法涵盖现在和未来所有使用JRE部分功能的需求。
JAR/Classpath地狱
JAR地狱和Classpath地狱是一种诙谐的说法，指的是Java类加载机制的缺陷所引发的问题。尤其是在大型的应用中，它们可能会以各种方式产生令人痛苦的问题。有一些问题是因为其他的问题而引发的，而有一些则是独立的。
无法表述依赖
JAR文件无法以一种JVM能够理解的方式来表述它依赖于哪些其他的JAR。因此，就需要用户手动识别并满足这些依赖，这要求用户阅读文档、找到正确的项目、下载JAR文件并将其添加到项目中。
而且，有一些依赖是可选的，只有用户在使用特定功能的特性时，某个JAR才会依赖另外一个JAR。这会使得这个过程更加复杂。
Java运行时在实际使用某项依赖之前，并不能探测到这个依赖是无法满足的。如果出现这种情况，将会出现NoClassDefFoundError异常，进而导致正在运行的应用崩溃。
像Maven这样的构建工具能够帮助解决这个问题。
传递性依赖
一个应用程序要运行起来可能只需依赖几个库就足够了，但是这些库又会需要一些其他的库。问题组合起来会变得更加复杂，在所消耗的体力以及出错的可能性上，它会呈指数级地增长。
同样，构建工具能够在这个问题上提供一些帮助。
遮蔽
有时候，在classpath的不同JAR包中可能会包含全限定名完全相同的类，比如我们使用同一个库的两个不同版本。因为类会从classpath中的第一个JAR包中加载，所以这个版本的变种将会“遮蔽”所有其他的版本，使它们变得不可用。
如果这些不同的变种在语义上有所差别，那将会导致各种级别的问题，从难以发现的不正常行为到非常严重的错误都是有可能的。更糟糕的是，问题的表现形式是不确定的。这取决于JAR文件在classpath中的顺序。在不同的环境下，可能也会有所区别，例如开发人员的IDE与代码最终运行的生产机器之间就可能有所差别。
版本冲突
如果项目中有两个所需的库依赖不同版本的第三个库，那么将会产生这个问题。
如果这个库的两个版本都添加到classpath中的话，那么最终的行为是不可预知的。首先，因为前面所述的遮蔽问题，两个版本的类中，只会有一个能够加载进来。更糟糕的是，如果某个类位于一个JAR包中，但是它所访问的其他类却不在这个包中，这个类也能够加载。所导致的结果就是，对这个库的代码调用将会混合在两个版本之中。
在最好的情况下，如果试图访问所加载的类中不存在的代码，将会导致明显的NoClassDefFoundError错误。但是在最坏的情况下，版本之间的差别仅仅是在语义上，实际的行为会有细微的差别，这会引入很难发现的bug。
识别这种情况所导致的难以预料的行为是很困难的，也无法直接解决。
复杂的类加载机制
默认情况下，所有的类由同一个ClassLoader负责加载，在有些场景下，可能有必要引入额外的加载器，例如允许用户加载新的类，对应用程序进行扩展。
这很快就会导致复杂的类加载机制，从而产生难以预期和难以理解的行为。
在包之间，只有很弱的封装机制
如果类位于同一个包中，那Java的可见性修饰符提供了一种很棒的方式来实现这些类之间的封装。但是，要跨越包之间边界的话，那只能使用一种可见性：public。
因为类加载器会将所有加载进来的包放在一起，public的类对其他所有的类都是可见的，因此，如果我们想创建一项功能，这项功能对某个JAR是可用的，而对于这个JAR之外是不可用的，这是没有办法实现的。
手动的安全性
包之间弱封装性所带来的一个直接结果就是，安全相关的功能将会暴露在同一个环境中的所有代码面前。这意味着，恶意代码有可能绕过安全限制，访问关键的功能。
从Java 1.1开始，有一种hack的方式，能够防止这种状况：每当进入安全相关的代码路径时，将会调用SecurityManager，并判断是不是允许访问。更精确地讲，它应该在每个这样的路径上都进行调用。过去，在有些地方遗漏了对它们的调用，从而出现了一些漏洞，这给Java带来了困扰。
启动性能
最后，Java运行时加载并JIT编译全部所需的类需要较长的时间。其中一个原因在于类加载机制会对classpath下的所有JAR执行线性的扫描。类似的，在识别某个注解的使用情况时，需要探查classpath下所有的类。
目标
Jigsaw项目的目标就是解决上面所述的问题，它会引入一个语言级别的机制，用来模块化大型的系统。这种机制将会用在JDK本身中，开发人员也可以将其用于自己的项目之中。
需要注意的是，对于JDK和我们开发人员来说，并不是所有的目标都具有相同的重要性。有一些与JDK具有更强的相关性，并且大多数都对日常的编程不会带来巨大的影响（这与最近的语言修改形成了对比，如lambda表达式和默认方法）。不过，它们依然会改变大型项目的开发和部署。
可扩展性的平台
JDK在模块化之后，用户就能挑出他们需要的功能，并创建自己的JRE，在这个JRE中只包含他们需要的模块。这有助于在小型设备和容器领域中，保持Java作为关键参与者的地位。
在这个提议的规范中，允许将Java SE平台及其实现分解为一组组件，开发人员可以把这些组件组装起来，形成自定义的配置，里面只包含应用实际需要的功能。—— JSR 376
可靠的配置
通过这个规范，某个模块能够声明对其他模块的依赖。运行时环境能够在编译期（compile-time）、构建期（build-time）以及启动期（launch-time）分析这些依赖，如果缺少依赖或依赖冲突的话，很快就会发生失败。
强封装
Jigsaw项目的一个主要目标就是让模块只导出特定的包，其他的包是模块私有的。
模块中的私有类就像是类中的私有域。换句话说，模块的边界不仅确定了类和接口的可见性，还定义了它的可访问性。——Mark Reinhol
d所撰写的文章“Project Jigsaw：将宏伟蓝图转换为可聚焦的点”
提升安全性和可维护性
在模块中，内部API的强封装会极大地提升安全性，因为核心代码对于没有必要使用它们的其余代码来讲是隐藏起来的。维护也会变得更加容易，这是因为我们能够更容易地将模块的公开API变得更小。
随意使用Java SE平台实现的内部API不仅有安全风险，而且也会带来维护的负担。该提议规范能够提供强封装性，这样实现Java SE平台的组件就能阻止对其内部API的访问。 —— JSR 376
提升性能
因为能够更加清晰地界定所使用代码的边界，现有的优化技术能够更加高效地运用。
很多预先（ahead-of-time）优化和全程序（whole-program）优化的技术会更加高效，因为能够得知某个类只会引用几个特定组件中的类，它并不能引用运行时所加载的任意类。 —— JSR 376
核心概念
因为模块化是目标，所以Jigsaw项目引入了模块（module）的概念，描述如下：
命名、自描述的程序组件，会包含代码和数据。模块必须能够包含Java类和接口，组织为包的形式，同时也能以动态加载库的形式（dynamically-loadable library）包含原生代码。模块的数据必须能够包含静态资源文件和用户可编辑的配置文件。 —— Java平台模块系统：需求（草案2）
为了能够基于一定的上下文环境来了解模块，我们可以想一下知名的库，如Google Guava或Apache Commons中的库（比如Collections或IO），将其作为模块。根据作者希望划分的粒度，每个库都可能划分为多个模块。
对于应用来说也是如此。它可以作为一个单体（monolithic）的模块，也可以进行拆分。在确定如何将其划分为模块时，项目的规模和内聚性将是重要的因素。
按照规划，在组织代码时，模块将会成为开发人员工具箱中的常规工具。
开发人员目前已经能够考虑到一些标准的程序组件，如语言层面的类和接口。模块将会是另外一种程序组件，像类和接口一样，它们将会在程序开发的各个阶段发挥作用。 ——Mark Reinhold的文章“Project Jigsaw：将宏伟蓝图转换为可聚焦的点”
模块又可以进一步组合为开发阶段的各种配置，这些阶段也就是编译期、构建期、安装期以及运行期。对于我们这样的Java用户来说，可以这样做（在这种情况下，通常会将其称之为开发者模块），同时这种方式还可以用来剖析Java运行时本身（此时，它们通常称之为平台模块）。
实际上，这就是JDK目前进行模块化的规划。
(点击放大图像)

特性
那么，模块是如何运行的呢？查阅一下Jigsaw项目的需求以及 JSR 376将会帮助我们对其有所了解。
依赖管理
为了解决“JAR/Classpath地狱”的问题，Jigsaw项目的一个关键特性就是依赖管理。让我们看一下这些相关的组件。
声明与解析
模块将会声明它需要哪些其他的模块才能编译和运行。模块系统会使用该信息传递性地识别所有需要的模块，从而保证初始的那个模块能够编译和运行。
我们还可以不依赖具体的模块，而是依赖一组接口。模块系统将会试图据此识别模块，这些模块实现了所依赖的接口，能够满足依赖，系统会将其绑定到对应的接口中。
版本化
模块将会进行版本化。它们能够标记自己的版本（在很大程度上可以是任意格式，只要能够完全表示顺序就行），版本还能用于限制依赖。在任意阶段都能覆盖这两部分信息。模块系统会在各个阶段都强制要求配置能够满足所有的限制。
Jigsaw项目不一定会支持在一个配置中存在某个模块的多个版本。但是，稍等，那该如何解决JAR地狱的问题呢？ 好问题！
版本选择——针对同一个模块，在一组不同版本中挑选最合适的版本——并没有作为规范所要完成的任务。所以，在我撰写的上文中，模块系统会识别所需的模块进行编译，在运行时则可能会使用另外一个模块，这都基于一个假设，那就是环境中只存在模块的一个版本。如果存在多个版本的话，那么上游的步骤（如开发人员或者他所使用的构建工具）必须要做出选择，系统只会校验它能满足所有的约束。
封装
模块系统会在各个阶段强制要求强封装。这是围绕着一个导出机制实现的，在这种情况下，只有模块导出的包才能访问。封装与SecurityManager所执行的安全检查是相独立的。
这个提议的具体语法尚没有定义，但是JEP 200提供了一些关键语义的XML实例。作为样例，如下的代码声明了java.sql模块。
<module> <!-- 模块的名字 --> <name>java.sql</name> <!-- 每个模块都会依赖java.base --> <depend>java.base</depend> <!-- 这个模块依赖于java.logging和java.xml 模块，并重新导出这些模块所导出的API包 --> <depend re-exports="true">java.logging</depend> <depend re-exports="true">java.xml</depend> <!-- 这个模块导出java.sql、javax.sql以及 javax.transaction.xa包给其他任意的模块 --> <export><name>java.sql</name></export> <export><name>javax.sql</name></export> <export><name>javax.transaction.xa</name></export> </module>
从这个代码片段我们可以看出，java.sql依赖于java.base、java.logging以及java.xml。在稍后介绍不同的导出机制时，我们就能理解上文中其他的声明了。
导出
模块会声明特定的包进行导出，只有包含在这些包中的类型才能导出。这意味着其他模块只能看到和使用这些类型。更严格是，其他模块必须要显式声明依赖包含这些类型的模块，这些类型才能导出到对应的模块中。
非常有意思的是，不同的模块能够包含相同名称的包，这些模块甚至还能够将其导出。
在上面的样例中，java.sql导出了java.sql、javax.sql以及javax.transaction.xa这些包。
重新导出
我们还能够在某个模块中重新导出它所依赖的模块中的API（或者是其中的一部分）。这将会对重构提供支持，我们能够在不破坏依赖的情况下拆分或合并模块，因为最初的依赖可以继续存在。重构后的模块可以导出与之前相同的包，即便它们可能不会包含所有的代码。在极端的情况下，有一种所谓的聚合器模块（aggregator module），它可以根本不包含任何代码，只是作为一组模块的抽象。实际上，Java 8中所提供的compact profile就是这样做的。
从上面的例子中，我们可以看到java.sql重新导出了它依赖的API，即java.logging和java.xml。
限制导出
为了帮助开发者（尤其是模块化JDK的人员）让他们所导出API的有较小的接触面，有一种可选的限制导出（qualified export）机制，它允许某个模块将一些包声明为只针对一组特定的模块进行导出。所以使用“标准”机制时，导出功能的模块并不知道（也不关心）谁会访问这些包，但是通过限制导出机制，能够让一个模块限定可能产生的依赖。
配置、阶段以及保真性（Fidelity）
如前所述，JEP 200的目标之一就是模块能够在开发的各个阶段组合为各种配置。对于平台模块可以如此，这样就能够创建与完整JRE或JDK类似的镜像，Java 8所引入的compact profile以及包含特定模块集合（及其级联依赖）的任意自定义配置都使用了这种机制。类似的，开发人员也可以使用这种机制来组合他们应用程序的不同变种。
在编译期（compile-time），要编译的代码只能看到所配置的模块集合中导出的包。在构建期（build-time），借助一个新的工具（可能会被称为JLink），我们能够创建只包含特定模块及其依赖的二进制运行时镜像。在安装期（launch-time），镜像能够看起来就像是只包含了它所具有的模块的一个子集。
我们还能够替换实现了授权标准（endorsed standard）和 独立技术（standalone technology）的模块，在任意的阶段都能将其替换为较新的版本。这将会替代已废弃的授权标准重载机制（endorsed standards override mechanism）以及扩展机制（参见下文。）
模块系统的各个方面（如依赖管理、封装等等），在所有阶段的运行方式是完全相同的，除非因为特定的原因，在某些阶段无法实现。
模块相关的所有信息（如版本、依赖以及包导出）都会在代码文件中进行描述，这样会独立于IDE和构建工具。
性能
全程序优化的技术
在模块系统中，借助强封装技术，能够很容易自动计算出一段特定的代码都用在了哪些地方。这会使得程序分析和优化技术更加可行：
快速查找JDK和应用程序的类；及早进行字节码的检验；积极级联（aggressive inlining）像lambda表达式这样的内容以及其他的编译器优化；构建特定于JVM的内存镜像，它加载时能够比类文件更加高效；预先将方法体编译为原生代码；移除没有用到的域、方法和类。——Jigsaw项目: 目标 & 需求（草案3）
有一些被称为全程序优化（whole-program optimization）的技术，在Java 9中至少会实现两种这样的技术。还有包含一个工具，使用这个工具能够分析给定的一组模块，并使用上述的优化技术，创建更加高性能的二进制镜像。
注解
目前，要自动发现带有注解
提升安全性和可维护性
在模块中，内部API的强封装会极大地提升安全性，因为核心代码对于没有必要使用它们的其余代码来讲是隐藏起来的。维护也会变得更加容易，这是因为我们能够更容易地将模块的公开API变得更小。
随意使用Java SE平台实现的内部API不仅有安全风险，而且也会带来维护的负担。该提议规范能够提供强封装性，这样实现Java SE平台的组件就能阻止对其内部API的访问。 —— JSR 376
提升性能
因为能够更加清晰地界定所使用代码的边界，现有的优化技术能够更加高效地运用。
很多预先（ahead-of-time）优化和全程序（whole-program）优化的技术会更加高效，因为能够得知某个类只会引用几个特定组件中的类，它并不能引用运行时所加载的任意类。 —— JSR 376
核心概念
因为模块化是目标，所以Jigsaw项目引入了模块（module）的概念，描述如下：
命名、自描述的程序组件，会包含代码和数据。模块必须能够包含Java类和接口，组织为包的形式，同时也能以动态加载库的形式（dynamically-loadable library）包含原生代码。模块的数据必须能够包含静态资源文件和用户可编辑的配置文件。 —— Java平台模块系统：需求（草案2）
为了能够基于一定的上下文环境来了解模块，我们可以想一下知名的库，如Google Guava或Apache Commons中的库（比如Collections或IO），将其作为模块。根据作者希望划分的粒度，每个库都可能划分为多个模块。
对于应用来说也是如此。它可以作为一个单体（monolithic）的模块，也可以进行拆分。在确定如何将其划分为模块时，项目的规模和内聚性将是重要的因素。
按照规划，在组织代码时，模块将会成为开发人员工具箱中的常规工具。
开发人员目前已经能够考虑到一些标准的程序组件，如语言层面的类和接口。模块将会是另外一种程序组件，像类和接口一样，它们将会在程序开发的各个阶段发挥作用。 ——Mark Reinhold的文章“Project Jigsaw：将宏伟蓝图转换为可聚焦的点”
模块又可以进一步组合为开发阶段的各种配置，这些阶段也就是编译期、构建期、安装期以及运行期。对于我们这样的Java用户来说，可以这样做（在这种情况下，通常会将其称之为开发者模块），同时这种方式还可以用来剖析Java运行时本身（此时，它们通常称之为平台模块）。
实际上，这就是JDK目前进行模块化的规划。
(点击放大图像)

特性
那么，模块是如何运行的呢？查阅一下Jigsaw项目的需求以及 JSR 376将会帮助我们对其有所了解。
依赖管理
为了解决“JAR/Classpath地狱”的问题，Jigsaw项目的一个关键特性就是依赖管理。让我们看一下这些相关的组件。
声明与解析
模块将会声明它需要哪些其他的模块才能编译和运行。模块系统会使用该信息传递性地识别所有需要的模块，从而保证初始的那个模块能够编译和运行。
我们还可以不依赖具体的模块，而是依赖一组接口。模块系统将会试图据此识别模块，这些模块实现了所依赖的接口，能够满足依赖，系统会将其绑定到对应的接口中。
版本化
模块将会进行版本化。它们能够标记自己的版本（在很大程度上可以是任意格式，只要能够完全表示顺序就行），版本还能用于限制依赖。在任意阶段都能覆盖这两部分信息。模块系统会在各个阶段都强制要求配置能够满足所有的限制。
Jigsaw项目不一定会支持在一个配置中存在某个模块的多个版本。但是，稍等，那该如何解决JAR地狱的问题呢？ 好问题！
版本选择——针对同一个模块，在一组不同版本中挑选最合适的版本——并没有作为规范所要完成的任务。所以，在我撰写的上文中，模块系统会识别所需的模块进行编译，在运行时则可能会使用另外一个模块，这都基于一个假设，那就是环境中只存在模块的一个版本。如果存在多个版本的话，那么上游的步骤（如开发人员或者他所使用的构建工具）必须要做出选择，系统只会校验它能满足所有的约束。
封装
模块系统会在各个阶段强制要求强封装。这是围绕着一个导出机制实现的，在这种情况下，只有模块导出的包才能访问。封装与SecurityManager所执行的安全检查是相独立的。
这个提议的具体语法尚没有定义，但是JEP 200提供了一些关键语义的XML实例。作为样例，如下的代码声明了java.sql模块。
<module> <!-- 模块的名字 --> <name>java.sql</name> <!-- 每个模块都会依赖java.base --> <depend>java.base</depend> <!-- 这个模块依赖于java.logging和java.xml 模块，并重新导出这些模块所导出的API包 --> <depend re-exports="true">java.logging</depend> <depend re-exports="true">java.xml</depend> <!-- 这个模块导出java.sql、javax.sql以及 javax.transaction.xa包给其他任意的模块 --> <export><name>java.sql</name></export> <export><name>javax.sql</name></export> <export><name>javax.transaction.xa</name></export> </module>
从这个代码片段我们可以看出，java.sql依赖于java.base、java.logging以及java.xml。在稍后介绍不同的导出机制时，我们就能理解上文中其他的声明了。
导出
模块会声明特定的包进行导出，只有包含在这些包中的类型才能导出。这意味着其他模块只能看到和使用这些类型。更严格是，其他模块必须要显式声明依赖包含这些类型的模块，这些类型才能导出到对应的模块中。
非常有意思的是，不同的模块能够包含相同名称的包，这些模块甚至还能够将其导出。
在上面的样例中，java.sql导出了java.sql、javax.sql以及javax.transaction.xa这些包。
重新导出
我们还能够在某个模块中重新导出它所依赖的模块中的API（或者是其中的一部分）。这将会对重构提供支持，我们能够在不破坏依赖的情况下拆分或合并模块，因为最初的依赖可以继续存在。重构后的模块可以导出与之前相同的包，即便它们可能不会包含所有的代码。在极端的情况下，有一种所谓的聚合器模块（aggregator module），它可以根本不包含任何代码，只是作为一组模块的抽象。实际上，Java 8中所提供的compact profile就是这样做的。
从上面的例子中，我们可以看到java.sql重新导出了它依赖的API，即java.logging和java.xml。
限制导出
为了帮助开发者（尤其是模块化JDK的人员）让他们所导出API的有较小的接触面，有一种可选的限制导出（qualified export）机制，它允许某个模块将一些包声明为只针对一组特定的模块进行导出。所以使用“标准”机制时，导出功能的模块并不知道（也不关心）谁会访问这些包，但是通过限制导出机制，能够让一个模块限定可能产生的依赖。
配置、阶段以及保真性（Fidelity）
如前所述，JEP 200的目标之一就是模块能够在开发的各个阶段组合为各种配置。对于平台模块可以如此，这样就能够创建与完整JRE或JDK类似的镜像，Java 8所引入的compact profile以及包含特定模块集合（及其级联依赖）的任意自定义配置都使用了这种机制。类似的，开发人员也可以使用这种机制来组合他们应用程序的不同变种。
在编译期（compile-time），要编译的代码只能看到所配置的模块集合中导出的包。在构建期（build-time），借助一个新的工具（可能会被称为JLink），我们能够创建只包含特定模块及其依赖的二进制运行时镜像。在安装期（launch-time），镜像能够看起来就像是只包含了它所具有的模块的一个子集。
我们还能够替换实现了授权标准（endorsed standard）和 独立技术（standalone technology）的模块，在任意的阶段都能将其替换为较新的版本。这将会替代已废弃的授权标准重载机制（endorsed standards override mechanism）以及扩展机制（参见下文。）
模块系统的各个方面（如依赖管理、封装等等），在所有阶段的运行方式是完全相同的，除非因为特定的原因，在某些阶段无法实现。
模块相关的所有信息（如版本、依赖以及包导出）都会在代码文件中进行描述，这样会独立于IDE和构建工具。
性能
全程序优化的技术
在模块系统中，借助强封装技术，能够很容易自动计算出一段特定的代码都用在了哪些地方。这会使得程序分析和优化技术更加可行：
快速查找JDK和应用程序的类；及早进行字节码的检验；积极级联（aggressive inlining）像lambda表达式这样的内容以及其他的编译器优化；构建特定于JVM的内存镜像，它加载时能够比类文件更加高效；预先将方法体编译为原生代码；移除没有用到的域、方法和类。——Jigsaw项目: 目标 & 需求（草案3）
有一些被称为全程序优化（whole-program optimization）的技术，在Java 9中至少会实现两种这样的技术。还有包含一个工具，使用这个工具能够分析给定的一组模块，并使用上述的优化技术，创建更加高性能的二进制镜像。
注解
目前，要自动发现带有注解
的类（如Spring注解标注的配置类），需要扫描特定包下的所有类。这通常会在程序启动的时候完成，这在相当程度上会减慢启动的过程。
模块将会提供一个API，允许调用者识别所有带有给定注解的类。一种预期的方式是为这样的类创建索引，这个索引会在模块编译的时候创建。
与已有的概念和工具集成
诊断工具（如栈跟踪信息）将会进行更新，其中会包含模块的信息。而且，它们还会集成到反射API中，这样就能按照操作类的方式来使用它们，还会包含版本信息，这一信息可以进行反射，也可以在运行时重载。
模块的设计能够让我们在使用构建工具时“尽可能地减少麻烦（with a minimum of fuss）”。编译之后的模块能够用在classpath中，也能作为一个模块来使用，这样的话，库的开发人员就没有必要为classpath应用和基于模块的应用分别创建多个构件了。
与其他模块系统的相互操作也进行了规划，这其中最著名的也就是OSGi。
尽管模块能够对其他的模块隐藏包，但是我们依然能够对模块包含的类和接口执行白盒测试。
特定OS的包
模块系统在设计时，始终考虑到了包管理器文件格式，“如RPM、Debian以及Solaris IPS”。开发人员不仅能够使用已有的工具将一组模块集合创建为特定OS的包，这些模块还能调用按照相同机制安装的其他模块。
开发人员还能够将组成应用的一组模块打包为特定OS的包，“终端用户能够按照目标系统的通用做法，安装和调用所打成的包”。基于上述的介绍，我们可以得知只有目标系统中不存在的模块才必须要打包进来。
动态配置
正在运行中的应用能够创建、运行并发布独立的模块配置。在这些配置中，可以包含开发者和平台模块。对于容器类架构，这会非常有用，如IDE、应用服务器或其他Java EE平台。
不兼容性
按照Java的惯例，这些变更在实现时，会强烈关注到向后的兼容性，所有标准和非废弃的API及机制都能够继续使用。但是项目可能会依赖其他缺乏文档的构造，这样的话，在往Java 9迁移的时候，就需要一些额外的工作了。
内部API不可用了
借助于强封装，每个模块能够明确声明哪些类型会作为其API的一部分。JDK将会使用这个特性来封装所有的内部API，因此它们会变得不可用了。
在Java 9所带来的不兼容性中，这可能是涵盖范围最大的一部分。但是这也是最明显的，因为它会导致编译错误。
那么，什么是内部API呢？毫无疑问，位于sun.*包中的所有内容。如果位于com.sun.*包中，或者使用了@jdk.Exported注解，在Oracle JDK中它依然是可用的，如果没有注解的话，那么它就是不可用的了。
能产生特殊问题的一个样例就是sun.misc.Unsafe类。它用在了很多项目中，用来实现关键任务或性能要求较高的代码，它将来可能不可用引发了很多的相关讨论。不过，在一次相关的交流中曾经提出，通过一个废弃的命令行标记，它依然是可用的。考虑到无法将其所有的功能都放到公开API中，这可能是一种必要的权衡。
另外一个样例是com.sun.javafx.*包中的所有内容。这些类对于构建JavaFX控件是至关重要的，并且它们还有一定数量的bug要修改。这些类中的大多数功能都会作为发布的目标。
合并JDK和JRE
在具有可扩展的Java运行时之后，它允许我们很灵活地创建运行时镜像，JDK和JRE就丧失了其独有的特性，它们只是模块组合中的两种形式而已。
这意味着，这两个构件将会具有相同的结构，包括目录结构也相同，任何依赖它（如在原来的JDK目录中会有名为jre的子目录）的代码就不能正常运行了。
内部JAR不可用了
像lib/rt.jar和lib/tools.jar这样的内部JAR将不可用了。它们的内容将会存储到特定实现的文件中，这些文件的格式还未明确说明，有可能会发生变化。
任何假设这些文件存在的代码将无法正确运行。这可能对IDE或其他严重依赖这些文件的工具带来一些切换的麻烦。
模块将会提供一个API，允许调用者识别所有带有给定注解的类。一种预期的方式是为这样的类创建索引，这个索引会在模块编译的时候创建。
与已有的概念和工具集成
诊断工具（如栈跟踪信息）将会进行更新，其中会包含模块的信息。而且，它们还会集成到反射API中，这样就能按照操作类的方式来使用它们，还会包含版本信息，这一信息可以进行反射，也可以在运行时重载。
模块的设计能够让我们在使用构建工具时“尽可能地减少麻烦（with a minimum of fuss）”。编译之后的模块能够用在classpath中，也能作为一个模块来使用，这样的话，库的开发人员就没有必要为classpath应用和基于模块的应用分别创建多个构件了。
与其他模块系统的相互操作也进行了规划，这其中最著名的也就是OSGi。
尽管模块能够对其他的模块隐藏包，但是我们依然能够对模块包含的类和接口执行白盒测试。
特定OS的包
模块系统在设计时，始终考虑到了包管理器文件格式，“如RPM、Debian以及Solaris IPS”。开发人员不仅能够使用已有的工具将一组模块集合创建为特定OS的包，这些模块还能调用按照相同机制安装的其他模块。
开发人员还能够将组成应用的一组模块打包为特定OS的包，“终端用户能够按照目标系统的通用做法，安装和调用所打成的包”。基于上述的介绍，我们可以得知只有目标系统中不存在的模块才必须要打包进来。
动态配置
正在运行中的应用能够创建、运行并发布独立的模块配置。在这些配置中，可以包含开发者和平台模块。对于容器类架构，这会非常有用，如IDE、应用服务器或其他Java EE平台。
不兼容性
按照Java的惯例，这些变更在实现时，会强烈关注到向后的兼容性，所有标准和非废弃的API及机制都能够继续使用。但是项目可能会依赖其他缺乏文档的构造，这样的话，在往Java 9迁移的时候，就需要一些额外的工作了。
内部API不可用了
借助于强封装，每个模块能够明确声明哪些类型会作为其API的一部分。JDK将会使用这个特性来封装所有的内部API，因此它们会变得不可用了。
在Java 9所带来的不兼容性中，这可能是涵盖范围最大的一部分。但是这也是最明显的，因为它会导致编译错误。
那么，什么是内部API呢？毫无疑问，位于sun.*包中的所有内容。如果位于com.sun.*包中，或者使用了@jdk.Exported注解，在Oracle JDK中它依然是可用的，如果没有注解的话，那么它就是不可用的了。
能产生特殊问题的一个样例就是sun.misc.Unsafe类。它用在了很多项目中，用来实现关键任务或性能要求较高的代码，它将来可能不可用引发了很多的相关讨论。不过，在一次相关的交流中曾经提出，通过一个废弃的命令行标记，它依然是可用的。考虑到无法将其所有的功能都放到公开API中，这可能是一种必要的权衡。
另外一个样例是com.sun.javafx.*包中的所有内容。这些类对于构建JavaFX控件是至关重要的，并且它们还有一定数量的bug要修改。这些类中的大多数功能都会作为发布的目标。
合并JDK和JRE
在具有可扩展的Java运行时之后，它允许我们很灵活地创建运行时镜像，JDK和JRE就丧失了其独有的特性，它们只是模块组合中的两种形式而已。
这意味着，这两个构件将会具有相同的结构，包括目录结构也相同，任何依赖它（如在原来的JDK目录中会有名为jre的子目录）的代码就不能正常运行了。
内部JAR不可用了
像lib/rt.jar和lib/tools.jar这样的内部JAR将不可用了。它们的内容将会存储到特定实现的文件中，这些文件的格式还未明确说明，有可能会发生变化。
任何假设这些文件存在的代码将无法正确运行。这可能对IDE或其他严重依赖这些文件的工具带来一些切换的麻烦。
ECMAScript 6是國際JavaScript新版的標準，該標準的出現將對JavaScript帶來不同的定位，此次更新提供結構化與模組化的寫法，強化了語言本身的架構；而更高語言撰寫約束，則是避免個模組之間產生衝突，雖然發展越來越接近一般的高階編程語言，但這也讓在Web Client端能夠使用的應用越來越強大與複雜。
剛才抓到一個 IP
城市： Taipei
進入位置： services.bystartw.ga
嘗試進入 services.bystartw.ga/favicon.ico 失敗
IP: 122.***.33.80
UTC 06:53:43
城市： Taipei
進入位置： services.bystartw.ga
嘗試進入 services.bystartw.ga/favicon.ico 失敗
IP: 122.***.33.80
UTC 06:53:43
hls.js is compatible with browsers supporting MSE with 'video/MP4' inputs. As of today, it is supported on:
Chrome for Android 34+
Chrome for Desktop 34+
Firefox for Android 41+
Firefox for Desktop 42+
IE11+ for Windows 8.1+
Edge for Windows 10+
Opera for Desktop
Vivaldi for Desktop
Safari for Mac 8+ (beta)
Chrome for Android 34+
Chrome for Desktop 34+
Firefox for Android 41+
Firefox for Desktop 42+
IE11+ for Windows 8.1+
Edge for Windows 10+
Opera for Desktop
Vivaldi for Desktop
Safari for Mac 8+ (beta)
