CoreNLP extractors only work for Stardog V7?

Much to my dismay, version 1.0 of the coreNLP jar file causes Stardog 6.1 on Windows to crash during startup. Version 1.2 of the jar is designated as an update for Stardog 7, so I was hoping version 1.0 would work, but no love.

Am I unable to play with NLP until Stardog 7 Windows native comes out?

Related: When is Stardog 7 Windows native coming out? :slight_smile: :slight_smile:


Hi Tim,

Version 1.0 ought to work with Stardog 6. Do you have a stardog.log or a heap dump or some artifact of the crash that we can look into?

For starters, here is the startup command and the resulting message.

C:\Stardog>stardog-admin.bat server start --disable-security --web-console

An unexpected error occurred.
java.lang.NoSuchFieldError: LUCENE_5_1_0

No updates to stardog.log during the startup process (before it crashes).


What I think happened is that we go right from v1.0 for Stardog 5 to v1.2 for Stardog 7. However, the only difference between v1.2 and the theoretical v1.1 is the stardogVersion property in the base build.gradle file.

So if you take the repository, change that to match your 6.x version, and compile the jar, it might just work!

The build process seemed to go okay right up until the end when it was trying to pull files from See log, attached. Previous successful steps not shown in this log file.

I don't think this was a security issue on my end because the preceding steps downloaded many source files and compiled them successfully.

Can someone at Stardog provide me with the correct version of a coreNLP jar for 6.1.0? I'm out of time to try fixing this issue on my own.

corenlp-BuildFailed.log (34.0 KB)



I've uploaded it to dropbox for you. You can access it at

Thanks for creating the jar file. I removed the original file and replaced it with the one you created. Unfortunately, same result:

C:\Stardog>stardog-admin.bat server start --disable-security --web-console

An unexpected error occurred.
java.lang.NoSuchFieldError: LUCENE_5_1_0

It looks like CoreNLP depends on an older version of Lucene than Stardog 6.1.0. Is there any chance that it's pulling in the older Lucene dependencies when it's building the fatjar and that's causing the problems? I'm not sure why it wouldn't also cause a problem for Stardog 7.x but maybe it's just the order that it's loading.


I was able to find a rogue version "1.1" of the jar that happens to work with version 6.1.0, so if you give this one a try it should go better for you. Sorry about all the problems!

Hi Stephen,

Thanks for your efforts here. Going rogue did not help either. I confirmed start of Stardog 6.1 without the .jar file - no issues.

Stardog server 6.1.0 started on Wed Jan 15 14:18:57 EST 2020.

Downloaded this latest .jar to the /server/ext folder and:

C:\Stardog>stardog-admin.bat server start
An unexpected error occurred.
java.lang.NoSuchFieldError: LUCENE_5_1_0

What else can I check?


It looks like the bites-corenlp does include the lucene dependencies and the jars from the ext directory get loaded first. If you want to try something hacky you can go into the $STARDOG_HOME/bin/ file and switch these two lines


so that the dbms line comes first and then cross your fingers. It will depend if corenlp is ok with a newer version of lucene. I think what really needs to happen is the package needs to be relocated in the fatJar but you've already said you've goine rogue so I figured you might be crazy enough to try it.

Just don't forget to switch it back or make a backup before you do a back up of that file first so you can switch it back if it doesn't work. You don't really want to be messing with those files.

Full disclosure: When I got that jar working with 6.1.0 it was in an external folder to which $STARDOG_EXT was pointing, instead of messing with server/ext and server/dbms

I tried swapping the order of those lines in - no effect.

My STARDOG_EXT points to:

When setting up to enable NLP testing, I had to create the \ext folder manually. There is nothing else in that folder other than the .jar we are testing.

under \dbms I see that the Lucene jars are for version 5.3.1. For example:

While the error states:
An unexpected error occurred.
java.lang.NoSuchFieldError: LUCENE_5_1_0

Why is Stardog 6.1 looking for Lucene 5.1.0 when it came with Lucene 5.1.3?

Do I need a set of Lucene 5.1.0 jars + other hackery?

I think it's ok as long as the Lucene index version is lower than the lib version and it's still supported but I don't know much about the Lucene API.

You might want to try moving the jar from $STARDOG_HOME/server/ext to the $STARDOG_EXT directory to match what @stephen did. I still think it has to do with the order and maybe switching the order in the file didn't have the effect I was looking for. I didn't trace it out in the script to make sure .I was shooting from the hip on that.

If I'm correct about what the problem is the correct way to resolve this would be to use the shadow gradle plugin


I moved the .jar file out of /server/ext to another folder for testing:


And set my STARDOG_EXT environment variable to: C:\Stardog\stardog-6.1.0\test

stardog-admin.bat server start

Success - Stardog starts!

Then I try
stardog doc put --rdf-extractors CoreNLPMentionRDFExtractor testDB foo_.docx

And I receive the error:

Unknown extractor name: CoreNLPMentionRDFExtractor


Maybe? But the more likely explanation is, for some reason, it’s not even loading the jar. I’d double check that STARDOG_EXT is actually set to the new location.

It appears so:

 Volume in drive C is Windows
 Volume Serial Number is 980A-2B1D

 Directory of C:\Stardog\stardog-6.1.0\test

01/16/2020  04:19 PM    <DIR>          .
01/16/2020  04:19 PM    <DIR>          ..
01/15/2020  02:10 PM     1,896,131,699 bites-corenlp-all-1.1.jar
               1 File(s)  1,896,131,699 bytes
               2 Dir(s)  45,377,953,792 bytes free

Looking at the stardog-admin.bat file it doesn't look like it's using STARDOG_EXT. @stephen are you running on Windows or Linux?

It shouldn't be too difficult to add it though. There are two places at the end of the script with %CLASSPATH% . Try changing it to %CLASSPATH%;%STARDOG_EXT%*

(Note the use of a semicolon in the between CLASSPATH and STARDOG_EXT)