repl java9
正如OpenJDK JEP 222中所建议的那样&＃xff0c;JShell提供了REPL&＃xff08;读取-评估-打印循环&＃xff09;来评估Java语言的声明&＃xff0c;语句和表达式&＃xff0c;以及允许其他应用程序利用其功能的API。 这个想法并不完全是新的。 BeanShell已经存在了15年以上&＃xff0c;几乎与Java一样长&＃xff0c;更不用说Scala和Groovy上的许多脚本语言也已经具有类似的shell。
BeanShell&＃xff08;顺便说一句&＃xff0c;也与Groovy一样&＃xff09;试图通过JSR 274中的Java Community Process进行标准化&＃xff0c;尽管这是&＃xff08;或也许是因为&＃xff09;两家主要公司&＃xff0c;但JSR并未产生任何显着的输出。 Sun和Google已加入专家组。 根据JCP.next倡议&＃xff0c;此JSR被宣布为“Hibernate”。
令人毛骨悚然的方法
通过JEP添加这样的Java新功能&＃xff0c;而不是唤醒“Hibernate” JSR&＃xff08;任何人都可以&＃xff0c;包括现在拥有前EG成员Sun的Oracle在内&＃xff09;可以引起JCP EC成员的关注。 一个担忧是&＃xff0c;在JCP刚刚将其ME和SE / EE部件合并为一个整体之后&＃xff0c;开发越来越多的平台功能而不是JSR&＃xff0c;而是在OpenJDK下开发JEP会在ME / SE&＃xff08;JDK&＃xff09;和EE之间造成另一个分歧然后&＃xff0c;剩下的大多数JSR都将驻留。
设备I / O &＃xff08;源自Java ME下Oracle专有的前身&＃xff09;已作为OpenJDK项目开发。 没有JEP&＃xff0c;似乎Oracle至少也可以在没有事先建议的情况下批准此类项目。 围绕JSR 310的闹剧既没有产生对几乎所有JSR都必须执行的实际Spec文档&＃xff0c;也没有&＃xff08;根据联合规范负责人Stephen Colebourne的建议&＃xff09;带有类似于其他SE平台JSR&＃xff08;例如Collections&＃xff09;的真实API&＃xff0c;这是另一个例子。 JEP启动时&＃xff0c;应该撤回JSR或将其声明为Hibernate状态。 EC只是为了给某些JDK部分加盖橡皮戳&＃xff0c;而没有JSR在OpenJDK之外的实际结果。
还请参见&＃xff1a; Java 9中的5个功能将改变您开发软件的方式&＃xff08;另外2个不会&＃xff09;
每个类都有一些Javadoc&＃xff0c;因此这实际上并不重要。 鉴于Oracle的大力参与&＃xff0c;我们很可能在OpenJDK下看到更多的JEP。 而且&＃xff0c;在Java生态系统的这些部分背后进行透明的开源工作仍比封闭环境更好&＃xff0c;因此&＃xff0c;即使它可能剥夺了某些JCP&＃xff08;和EC&＃xff09;的专利权并削弱了它们的实力&＃xff0c;总比没有开放开发好。
JShell的潜在用途
在Java中拥有这样的Shell当然不是一个坏主意。 无论其在Java SE下的开发如何&＃xff0c;Java EE的未来版本都可能会发现标准外壳比Java SE更具吸引力。 Java ME的价值还有待观察&＃xff0c;尤其是在甚至可能进行像Device I / O这样的缩减规模的情况下。 但是至少&＃xff0c;运行Java SE Embedded的物联网设备至少应该明显受益。
至少在Windows和.NET上&＃xff0c; Windows PowerShell已成为系统管理或DevOps团队的强烈偏好。 它由Play框架用于管理任务&＃xff0c;而Groovy由Spring框架或在JBoss Admin Shell的幕后用于类似目的。 同时&＃xff0c;WebLogic脚本工具&＃xff08;WLST&＃xff09;来自JVM上的Python shell Jython。 Java EE参考实现GlassFish具有一个名为asadmin的管理外壳。 能够在将来的版本中使用统一的Java shell无疑会使许多基于Java的项目以及使用它们的产品&＃xff0c;开发人员和操作人员的工作变得更加轻松。
其他有趣的使用领域是特定于域的扩展。 Groovy&＃xff0c;Scala或其他启用Shell的语言&＃xff08;在JVM上以及在JVM之外&＃xff09;在业务或科学计算中非常受欢迎。 根据对JShell的早期印象 &＃xff0c;像assigned to temporary variable $3 of type int消息可能会引起误解&＃xff08;图1&＃xff09;。
特别是金融领域在阅读“ $”时会想到美元&＃xff0c;因此仍有改进的空间。 但是&＃xff0c;几乎自然的语言查询&＃xff08;例如Google&＃xff09;会回答诸如“ 2 &＃43; 2是多少”之类的问题&＃xff0c;或者像Q&＃xff06;A之类的当时漂亮的NoSQL DB&＃xff0c;提供此类功能的时间比Java语言甚至开始具有巨大潜力早十年。 当得到智能家居解决方案的支持时&＃xff0c;用户可能会问自己客厅的温度&＃xff0c;而不是简单地问“ 2 &＃43; 2”问题。 或使用诸如354&＃xff0c;最近完成的Money API之类的JSR&＃xff0c;诸如“ CHF中的2 $”之类的问题也很有意义。 在那里&＃xff0c;引用$金额的临时变量会有些混乱&＃xff0c;但是也许JShell背后的JDK团队找到了其他表达方式。
Frink是Java支持的REPL和表达语言的另一个很好的例子&＃xff0c;它以《辛普森一家》电视连续剧中怪异的科学家角色命名。 它回答了各种问题&＃xff0c;从日期/时间或时区转换&＃xff08;当然也可以将java.time aka JSR 310也用于此&＃xff09;或货币转换开始&＃xff0c;例如&＃xff1a;
"600 baht -> USD"
Frink提供了更多的数学和物理公式&＃xff0c;包括单位换算。 基于即将发布的Java度量标准 JSR 363&＃xff0c;这将以类似的方式实现。 联合创始人Guillaume Laforge与Groovy一起使用JSR 275记录了用于测量单位的DSL / REPL 。 他们的解决方案被用于疟疾治疗的现实医学研究中。 当然&＃xff0c;用Java编写的人也可能只是在Java 9下通过JShell公开了实际的Frink语言和系统&＃xff01;
翻译自: https://jaxenter.com/jshell-the-java-9-repl-what-does-it-do-120299.html
repl java9
京公网安备 11010802041100号