Problems with Java 11

[kwalcock]

See also #941.

One unit test fails when the test suite is run with Java 11. This is apparently a problem in SUTime. It gets a different answer in Java 8 than in Java 11, not finding "annual" in the later. This seems to be dependent also on the version of SUTime.

"annual"	v3.9.2	v4.2.0
Java 8	✓	✓
Java 11	🗙	✓

So, I am OK with sticking with the Java version check in build.sbt for now. If we want to enable Java 11, then we should probably try to update to a newer version of StanfordNLP if that is possible.

[MihaiSurdeanu]

Let's discuss this at the WM meeting tomorrow.

[kwalcock]

@EgoLaparra, fyi. I hope that the table above is accurate. If you have other data points I'm glad to add them.

[kwalcock]

The SUTime issue is also being discussed at stanfordnlp/CoreNLP#1137.

[kwalcock]

Testing of Stanford NLP 4.2.0 gave these results on our related projects:

Processors

[info] Tests: succeeded 52, failed 6, canceled 0, ignored 0, pending 0
[info] *** 6 TESTS FAILED ***
[error] Failed tests:
[error] 	org.clulab.processors.TestCoreNLPProcessor
[error] 	org.clulab.processors.TestFastNLPProcessor

Namely,

[info] TestCoreNLPProcessor:
[info] CoreNLPProcessor
[info] - should POS tag correctly *** FAILED ***
[info]   "[IN]" was not equal to "[TO]" (TestCoreNLPProcessor.scala:127)
[info] - should run the constituent parser correctly *** FAILED ***
[info]   false was not true (TestCoreNLPProcessor.scala:168)
[info] - should run the constituent parser correctly on texts with parentheses *** FAILED ***
[info]   false was not true (TestCoreNLPProcessor.scala:270)

[info] TestFastNLPProcessor:
[info] FastNLPProcessor
[info] - should generate correct dependencies in test sentence 1 *** FAILED ***
[info]   false was not true (TestFastNLPProcessor.scala:22)
[info] FastNLPProcessor
[info] - should generate correct dependencies in test sentence 2 *** FAILED ***
[info]   false was not true (TestFastNLPProcessor.scala:38)
[info] FastNLPProcessor
[info] - should run the dependency parser correctly on texts with parentheses *** FAILED ***
[info]   false was not true (TestFastNLPProcessor.scala:92)

Reach

No test failures

Eidos

There are library dependency problems which cause lucene to go berserk. I will have to investigate.

[MihaiSurdeanu]

This is hopefully not too bad... Can you please start a branch in processors for this?

…

On Thu, Feb 18, 2021 at 15:27 Keith Alcock ***@***.***> wrote: Testing of Stanford NLP 4.2.0 gave these results on our related projects: Processors [info] Tests: succeeded 52, failed 6, canceled 0, ignored 0, pending 0 [info] *** 6 TESTS FAILED *** [error] Failed tests: [error] org.clulab.processors.TestCoreNLPProcessor [error] org.clulab.processors.TestFastNLPProcessor Namely, [info] TestCoreNLPProcessor: [info] CoreNLPProcessor [info] - should POS tag correctly *** FAILED *** [info] "[IN]" was not equal to "[TO]" (TestCoreNLPProcessor.scala:127) [info] - should run the constituent parser correctly *** FAILED *** [info] false was not true (TestCoreNLPProcessor.scala:168) [info] - should run the constituent parser correctly on texts with parentheses *** FAILED *** [info] false was not true (TestCoreNLPProcessor.scala:270) [info] TestFastNLPProcessor: [info] FastNLPProcessor [info] - should generate correct dependencies in test sentence 1 *** FAILED *** [info] false was not true (TestFastNLPProcessor.scala:22) [info] FastNLPProcessor [info] - should generate correct dependencies in test sentence 2 *** FAILED *** [info] false was not true (TestFastNLPProcessor.scala:38) [info] FastNLPProcessor [info] - should run the dependency parser correctly on texts with parentheses *** FAILED *** [info] false was not true (TestFastNLPProcessor.scala:92) Reach Forthcoming Eidos Forthcoming — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#960 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI75TRHHL5LEQKWNZDACUDS7WH6RANCNFSM4XS3U3UQ> .

[kwalcock]

https://github.com/clulab/processors/tree/updateStanford

[MihaiSurdeanu]

I checked the unit tests, and there are changes in the dependency representations, as follows:

• “nmod” and “nmod_” become “obl” and “obl_”
• “dobj” becomes “obj”
• Appositives seem broken… (affects reach)

Let's plan Monday. I think it would be fairly easy to make the eidos and reach grammars (mostly) compatible with these changes. Meanwhile, @kwalcock, can you please run eidos tests with this processors branch?