2020 年第一个候选 Java 增强提案,删除 Nashorn JavaScript 引擎

2020年02月28日

Oracle 软件研发总监 Jim Laskey 提出了一项候选 Java 增强提案(JEP),要删除长期以来一直使用的 Nashorn JavaScript 引擎、相关 API 和jjs工具。这是 2020 年第一个进入候选名单的 JEP,并且比较成熟,有望在 JDK 15 中实施。

编号 JEP 372,该提案表示:Nashorn JavaScript 引擎最初通过 JEP 174 集成到 JDK 8 中,用以替代 Rhino 脚本引擎。当时它是 ECMAScript-262 5.1 标准的完整实现。但随着 ECMAScript 语言构造以及 API 的快速适应和修改,我们发现 Nashorn 难以维护。

根据该提议,两个 JDK 模块将被永久删除:

  • jdk.scripting.nashorn:包含 jdk.nashorn.api.scripting 与 jdk.nashorn.api.tree 包

  • jdk.scripting.nashorn.shell:包含 jjs 工具

但这一弃用将不会以任何方式影响 javax.script API。

Nashorn JavaScript 引擎发布时,其性能与之前的 Rhino 实现相比,提升达到 2 到 10 倍,这也是它能替代前者的原因之一,并且其采用也很广泛。但是在 2018 年 9 月发布的 JDK 11 中已经将其弃用(JEP 335),JEP 372 认为这么长的时间过去了,使用它的开发人员已经有足够的时间进行了迁移。

不过开发者对此有不同看法,有人认为 Java 一直以高度向后兼容闻名,不应该删除,有人吐槽公司还在使用 Rhino,也有人建议直接切换到 GraalVM,因为它是 JavaScript 与 Node 的更完整的实现,并且速度更快。

展开阅读全文
2 收藏
分享
加载中
精彩评论
这类库就应该作为第三方提供, 内置太多就臃肿了, 现在做减法也不晚, 之前也减掉过没几个人用的Derby和JavaFX, 甚至JavaEE都降成第三方的了.
2020-02-28 10:39
15
举报
每次java/jdk有动静,就有人刷 我司1.6/1.8什么的就来了,何必呢? 仿佛当年自己坚守xp系统 还劝别人不要上win7的人,各种黑新系统,没人敢站出来说新特性优势,因为一旦有人出来,就有一批喷子开始喷,微软给你多少钱 之类的……无语
2020-02-28 10:38
9
举报
JPA怎么能删除呢,一堆ORM的库使用。
2020-02-29 09:11
3
举报
那是你没用到!
2020-03-01 11:00
2
举报
你想多了,mybatis大面积使用就国内。国外还是hibernate的实现多。况且JPA仅仅是一种规范,定义了一些接口。
2020-02-29 10:30
2
举报
最新评论 (42)
支持删除
2020-03-21 09:21
0
回复
举报
抽出来做个扩展包或者插件..不影响现有客户. 更新慢一点就可以了.
2020-03-03 10:42
0
回复
举报
支持删除,球用没有。
2020-03-01 09:26
0
回复
举报
那是你没用到!
2020-03-01 11:00
2
回复
举报
不应该内置了,用的公司、人数又不多。交给第三方。
2020-03-01 07:14
0
回复
举报
阔以
2020-02-29 19:20
0
回复
举报
印象nashorn不是已经删了吗?
不过,虽然不愿意承认,graalvm确实牛逼
我猜测以后jvm的优势会脱离出Java,Python,JS,等会抢Java饭碗,又要学习了
2020-02-29 15:10
0
回复
举报
加进JDK里的特性都不可能轻易删除的, 否则会破坏用户对Java的兼容性印象.
nashorn在JDK11中只是标记为"过时", 但还是能用, 再过2年才敢真正删除.
2020-03-01 08:38
1
回复
举报
Rhino 执行js然后在java中返回的是什么类型?
2020-02-29 13:25
0
回复
举报
Object
2020-03-01 12:12
0
回复
举报
里面的Js方法返回字符串给java,java怎么识别?js没类型的?
2020-03-01 23:28
0
回复
举报
在java里都是Object,你自己是知道js返回的是啥类型的,然后在java里强转
2020-03-03 09:54
0
回复
举报
js 引擎确实应该清除, 使用场景 极少 ,以plugs提供就可以了
2020-02-29 11:35
0
回复
举报
这个js引擎连ES6都不支持,要他何用?JPA,CXF什么的都可以删除了,没人用了
2020-02-29 00:00
0
回复
举报
JPA怎么能删除呢,一堆ORM的库使用。
2020-02-29 09:11
3
回复
举报
orm现在用的不多了吧,都是mybatis
2020-02-29 10:21
0
回复
举报
你想多了,mybatis大面积使用就国内。国外还是hibernate的实现多。况且JPA仅仅是一种规范,定义了一些接口。
2020-02-29 10:30
2
回复
举报
我去,先了解清楚orm再发言吧,mybatis就是orm的一种框架吧
2020-02-29 19:07
0
回复
举报
orm是对象关系自动映射,而jpa是java提供的一种规范,而mybatis不依赖jpa,mybatis也不是真正的orm,你自己不懂说我不懂?
2020-03-01 15:29
0
回复
举报
没人说它们存在依赖,jpa,mybatis本来就是orm的不同思路,一个全自动,一半自动而已。orm本来就是一个Object映射Relation定义而已,“orm现在用的不多了吧”这句话不可笑吗?
2020-03-01 21:03
0
回复
举报
回复 @淡淡的分 : 大哥你不看上下文的吗?我说的是基于jpa的orm,天
2020-03-01 22:51
0
回复
举报
mybatis是orm的一种框架,你怕是对orm有什么误解吧。抽象,继承,关系引用,集合,级联,没有这些对象关系也敢称orm。
2020-03-07 10:08
0
回复
举报
国外很多jpa(hibernate)的,看每年国外统计java框架使用率就知道了
2020-03-02 13:21
0
回复
举报
看来外国人和我们国内的思维还是不一样,其实hibernate的出现是帮助开发人员节省SQL的学习成本,采用一种自动生成SQL或者HQL的方言来做到CURD,问题是hibernate太臃肿了,而且本来是降低难度的HQL反而增加了学习难度,舍得其反
2020-03-02 20:26
0
回复
举报
// implementation 'org.graalvm.js:js:20.0.0'
// implementation 'org.graalvm.js:js-scriptengine:20.0.0'

List<String> list = new ArrayList<>(3);
list.add("111");
list.add("222");
list.add("333");

ScriptEngine engine = new ScriptEngineManager().getEngineByName("Graal.js");
Bindings bindings = engine.getBindings(ScriptContext.ENGINE_SCOPE);
bindings.put("polyglot.js.allowAllAccess",true);
bindings.put("list", list);
long start = System.currentTimeMillis();
Object result = engine.eval("list.stream().map(i => java.lang.Integer.parseInt(i) + 5).collect(java.util.stream.Collectors.toList())");
long coust = System.currentTimeMillis() - start;
System.out.println(String.format("Const time %d ms", coust));
List<Integer> nums = (List<Integer>) result;
System.out.println(nums.get(2));
2020-02-28 17:08
1
回复
举报
更多评论
42 评论
2 收藏
分享
返回顶部
顶部