JAVA 8

[bhecht2]

Seems like not working with JAVA 8. Is this true?

[apurde]

I'm using it in a Java 8 environment without problems. What kind of issue do you have?

Andreas

[bhecht2]

Using JAVA_VERSION="1.8.0_45" (with JAVA 1.7, all works as expected)

Exception in thread "main" java.lang.RuntimeException: Invalid bundled javascript file
at de.undercouch.citeproc.CSL.(CSL.java:168)
at de.undercouch.citeproc.CSL.(CSL.java:130)
at de.undercouch.citeproc.CSL.(CSL.java:94)
at de.undercouch.citeproc.CSL.(CSL.java:63)
at de.undercouch.citeproc.CSL.makeAdhocBibliography(CSL.java:615)
at citeproc.test.CitationStyleService.main(CitationStyleService.java:21)
Caused by: de.undercouch.citeproc.script.ScriptRunnerException: Could not evaluate code
at de.undercouch.citeproc.script.JREScriptRunner.eval(JREScriptRunner.java:60)
at de.undercouch.citeproc.script.AbstractScriptRunner.loadScript(AbstractScriptRunner.java:32)
at de.undercouch.citeproc.CSL.(CSL.java:162)
... 5 more
Caused by: javax.script.ScriptException: :59:4 Expected an operand but found default
default xml namespace = "http://purl.org/net/xbiblio/csl"; with({});
^ in at line number 59 at column number 4
at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:455)
at jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:522)
at jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:509)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:397)
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:147)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249)
at de.undercouch.citeproc.script.JREScriptRunner.eval(JREScriptRunner.java:58)
... 7 more
Caused by: jdk.nashorn.internal.runtime.ParserException: :59:4 Expected an operand but found default
default xml namespace = "http://purl.org/net/xbiblio/csl"; with({});
^
at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:292)
at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:277)
at jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:3175)
at jdk.nashorn.internal.parser.Parser.expression(Parser.java:3275)
at jdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1152)
at jdk.nashorn.internal.parser.Parser.statement(Parser.java:969)
at jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:775)
at jdk.nashorn.internal.parser.Parser.functionBody(Parser.java:2894)
at jdk.nashorn.internal.parser.Parser.functionExpression(Parser.java:2661)
at jdk.nashorn.internal.parser.Parser.memberExpression(Parser.java:2508)
at jdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:2374)
at jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:3140)
at jdk.nashorn.internal.parser.Parser.expression(Parser.java:3318)
at jdk.nashorn.internal.parser.Parser.expression(Parser.java:3275)
at jdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1152)
at jdk.nashorn.internal.parser.Parser.statement(Parser.java:969)
at jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:775)
at jdk.nashorn.internal.parser.Parser.program(Parser.java:711)
at jdk.nashorn.internal.parser.Parser.parse(Parser.java:284)
at jdk.nashorn.internal.parser.Parser.parse(Parser.java:250)
at jdk.nashorn.internal.runtime.Context.compile(Context.java:1207)
at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:1179)
at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:594)
at jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:520)
... 12 more

[apurde]

You are right. I'm using citeproc java together with Rhino in Java 1.8. However in case you don't bundle Rhino citeproc-java uses the bundled JS engine which is Nashorn in Java 1.8 - I think this is the reason for your problem and yes it should remain open.

[michel-kraemer]

Yes, at the moment you need Rhino to run citeproc-java under Java 8. This should be a workaround though and not a permanent solution.

I guess in future versions I will only support Java 8 and remove support for Java 6/7 and Rhino. This will make maintaining the library much easier. Please let me know if you have any objections.

[bhecht2]

Using rhino solved my problem. No objection to your solution. Many thanks for the help!

[uschindler]

+1 to move to Java 8 only solution. Are there any pull requests to make it work with Nashorn?

[michel-kraemer]

Thanks to all for the feedback. I just uploaded a new snapshot:
https://oss.sonatype.org/content/repositories/snapshots/de/undercouch/citeproc-java/1.0.0-SNAPSHOT/

It requires Java 8 and works with Nashorn. If you want to test it I would be happy to get your feedback. I hope I can release version 1.0.0 soon.

Michel

[uschindler]

Thanks Michel, I will try this out this week.

One small thing, the OSGI Manifest still contains Rhino: https://github.com/michel-kraemer/citeproc-java/blob/master/citeproc-java/build.gradle#L154

[michel-kraemer]

Thanks, @uschindler! I didn't notice that.

[walterMPDL]

We can't get the new version running. We get a bug running some test cases. It seems an incompatibility between nashorn and rhino. I added the stack trace at the end. Maybe someone recognizes the problem at a glance, and can give us a little hint. It would be great, if the next implementation iteration would get a new version (e.g. 1.0.1) too, as we are already using citeproc-java in our production environment. Here is the stack trace:

[main] ERROR de.mpg.mpdl.inge.cslmanager.CitationStyleLanguageManagerDefaultImpl - Error getting output
java.lang.IllegalArgumentException: Could not parse arguments
at de.undercouch.citeproc.CSL.(CSL.java:255)
at de.undercouch.citeproc.CSL.(CSL.java:221)
at de.undercouch.citeproc.CSL.(CSL.java:185)
at de.mpg.mpdl.inge.cslmanager.CitationStyleLanguageManagerDefaultImpl.getOutput(CitationStyleLanguageManagerDefaultImpl.java:94)
at de.mpg.mpdl.inge.cslmanager.TestCitationStyleLanguageManager.testDefaultImplementation(TestCitationStyleLanguageManager.java:111)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at com.sun.proxy.$Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: de.undercouch.citeproc.script.ScriptRunnerException: Could not call method
at de.undercouch.citeproc.script.JREScriptRunner.callMethod(JREScriptRunner.java:79)
at de.undercouch.citeproc.CSL.(CSL.java:251)
... 36 more
Caused by: javax.script.ScriptException: TypeError: Cannot get property "getAttribute" of null in at line number 1748
at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:470)
at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:392)
at jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190)
at de.undercouch.citeproc.script.JREScriptRunner.callMethod(JREScriptRunner.java:74)
... 37 more
Caused by: :1748 TypeError: Cannot get property "getAttribute" of null
at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)
at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:213)
at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:185)
at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:172)
at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.linkNull(NashornBottomLinker.java:183)
at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:66)
at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124)
at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:154)
at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:253)
at jdk.nashorn.internal.scripts.Script$Recompilation$40$61488A$^eval_.setupXml(:1748)
at jdk.nashorn.internal.scripts.Script$Recompilation$78$238132AA$^eval_.localeConfigure(:6158)
at jdk.nashorn.internal.scripts.Script$Recompilation$13$86950AAAA$^eval_.Engine(:2529)
at jdk.nashorn.internal.scripts.Script$Recompilation$11$1706AAAAAAA$^eval_.makeCsl(:63)
at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:651)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199)
at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:386)
... 39 more

[michel-kraemer]

@walterMPDL I've reopened this issue. Thanks for reporting.

Could you please give me a bit more information.

• What Java version do you use?
• What version of the citeproc-java do you use? The latest snapshot?
• Do you still have Rhino in your classpath even with the latest snapshot?

It seems an incompatibility between nashorn and rhino.

Why do you think this? I don't see Rhino in the stacktrace.

It would be great, if the next implementation iteration would get a new version (e.g. 1.0.1) too

Sure thing! I'm currently updating the documentation and then I'll release version 1.0.0. Currently, we only have snapshots and they can change at any time, but I will use semantic versioning for the releases.

Cheers,
Michel

[walterMPDL]

• We are working on the latest Java 8 (112).
• Citeproc version is 1.0.0 - but I tried the previous version with rhino (build 2015/01/24) which is working and the one with nashorn (build 2016/01/16) which is not working with our test item.
• Rhino should not be in the classpath anymore, but I will check that once more and comment here, if this is wrong

It seems an incompatibility between nashorn and rhino.

Why do you think this? I don't see Rhino in the stacktrace.

I meant not directly, as rhino is no more in our classpath. To me it seems more like nashorn is not capable of something designed for rhino in that point. But I might be wrong in that point.
And the news about the release is really great for us! Thank you for that.

Best Regards,
Matthias

[michel-kraemer]

I checked your stack trace again:

Caused by: javax.script.ScriptException: TypeError: Cannot get property "getAttribute" of null in at line number 1748

The error happens in line 1748 in citeproc.js. As far as I can see citeproc.js tries to parse XML but the input is null (or undefined). It seems like your style XML or your locale XML is null when you call the constructor of the CSL class - or the files that you try to load do not exist. Can you check this please?

In order to be able to do further debugging I think I'd need some kind of running code. It would be perfect if you could prepare a minimal running example that demonstrates the issue, so that I can reproduce it.

Cheers,
Michel

[walterMPDL]

I will check that, but it seems a little strange, as the test is running with the older version. It may take a one or two days to prepare the example, as we got a problem with our live system. Sorry for that in advance.

Best Regards,
Matthias

[michel-kraemer]

No worries. It's me who must apologise for the delay :-)

Michel

[walterMPDL]

Sorry for the late response, but as I said, we had some issues with our production system...

I uploaded an excerpt from our environment.
https://github.com/MPDL/PubMan/tree/master/common_services/tools/csl_testing
It includes a lot of overhead right now, but your can run the Maven build and it will throw the exceptions mention above, when trying to run the test. If you debug the test you will see, that in Line 80 from CitationStyleLanguageManagerDefaultImpl all Parameteres are available, when instantiating a new CSL. I hope this helps to show our problem a little more in detail. If this example is too large, just let me know. As I mentioned we got a lot of things to do right now and I just wanted to give you feedback as you have been waiting for a time right now.

Best Regards,
Matthias

[michel-kraemer]

No worries. Anything is better than nothing. I'll try to reproduce the issue and get back to you.

[michel-kraemer]

@walterMPDL Your unit test loads a style file citationStyleChicago.xml. This file contains a default locale called en-EN. There is no such locale. You should change it to en-US or en-GB or the like.

I changed citeproc-java so it throws an Exception instead of failing with this cryptic error.

I hope this helps! Let me know if you need anything else.

[michel-kraemer]

I just published version 1.0.0 by the way. Please use this version from now on and report any problems with Java 8 here.

Cheers,
Michel

[walterMPDL]

@michel-kraemer Thanks a lot for your help! Such a stupid mistake... So sorry for wasting your time

[michel-kraemer]

It wasn't a waste of time at all. It actually revealed the issue that DefaultLocaleProvider silently failed if the locale did not exist. This is fixed now, so thanks!