I don’t believe they are removing ScriptEngine support, only the JavaScript engine being there by default. I wouldn’t have recommended using it anyway since it doesn’t compile the scripts.
Ralph > On Jul 2, 2018, at 8:25 AM, Matt Sicker <boa...@gmail.com> wrote: > > On Mon, 2 Jul 2018 at 04:29, Rory O'Donnell <rory.odonn...@oracle.com> > wrote: > >> * 335: *Deprecate the Nashorn JavaScript Engine* >> > > Hooray, more built in features going away! So first we have the issue of > XML APIs being removed from the base (which, as far as I can tell, means > you either have to add special command line flags to re-enable or you need > to include the XML API libraries on the classpath/modulepath manually > anyways), and now we have no standard javax.script engine to use, either, > unless I missed something and now you can use Java itself as a scripting > engine. I'm starting to think that with Log4j 3, we'll need to move some > features that depend on non-base APIs into separate modules where possible, > or we're going to need to get creative with our build system to avoid third > party dependencies in log4j-core (jar shading is always an option). The > script family of plugins may be one such plugin. We already had several > pain points around things like JNDI with Android in the past, and I think > this will only get worse with future Java releases and further > modularization. > > >> JDK-8202088 <https://bugs.openjdk.java.net/browse/JDK-8202088> : >> Japanese New Era Implementation >> > > We had locale-related date test failures in the past when JDK 9 was in > development. Is this anything to worry about? > > > -- > Matt Sicker <boa...@gmail.com>
