Trim runtime deps: make Nashorn optional, bulk up JS filter tests#1775
Merged
Conversation
Slim htsjdk's published runtime classpath by making the JavaScript
engine an opt-in dependency, and clean up around the change. Net effect
for consumers of the v5.0.0 artifact: 6 fewer jars on the runtime
classpath (nashorn-core + 5 ASM transitives, ~2.5 MB) and one less
"misleading direct dependency" in the published POM.
** BREAKING CHANGE **
Consumers using htsjdk.samtools.filter.JavascriptSamRecordFilter or
htsjdk.variant.variantcontext.filter.JavascriptVariantFilter must now
add a JSR-223 "js" engine to their own runtime classpath. The
recommended choice is OpenJDK Nashorn:
Gradle: runtimeOnly 'org.openjdk.nashorn:nashorn-core:15.7'
Maven: <dependency>
<groupId>org.openjdk.nashorn</groupId>
<artifactId>nashorn-core</artifactId>
<version>15.7</version>
<scope>runtime</scope>
</dependency>
If no engine is on the classpath at runtime, AbstractJavascriptFilter's
constructor now throws a RuntimeScriptException whose message names the
calling filter class and prints both Gradle and Maven coordinates, so
the failure is fully self-describing.
** Changes **
build.gradle:
- Nashorn moved from `implementation` to `compileOnly` (and bumped
15.4 -> 15.7). It also appears as `testImplementation` so the
project's own test suite still has an engine available.
- Removed the direct `commons-logging:1.3.0` declaration. htsjdk does
not use commons-logging itself; it was only declared to bump the
version that commons-jexl 2.1.1 transitively pulls (1.1.1, from 2007).
Replaced with a Gradle dependency constraint, so the published POM
advertises the version pin in <dependencyManagement> rather than as
a real direct dep. Same runtime behavior, more honest metadata.
src/main/java/htsjdk/samtools/filter/AbstractJavascriptFilter.java:
- Replaced the prior "Do you use the SUN/Oracle Java Runtime?" error
with a multi-line, fully self-describing message via a new
package-private noJsEngineMessage(String) helper.
src/main/java/htsjdk/samtools/filter/JavascriptSamRecordFilter.java
src/main/java/htsjdk/variant/variantcontext/filter/JavascriptVariantFilter.java:
- Class Javadoc rewritten with a clear summary, a small inline usage
example, and a "Runtime requirement" callout pointing at the
nashorn-core artifact coordinates.
Test changes (separate prep work, kept here so the entire JS-filter
surface lands in one PR):
- Deleted 4 checked-in JavaScript test fixtures
(samFilter01.js, samFilter02.js, variantFilter01.js, variantFilter02.js).
- Rewrote both JavascriptSamRecordFilterTest and JavascriptVariantFilterTest
as many small, focused tests using inline String scripts and
programmatically-built SAMFileHeader / VCFHeader / SAMRecord /
VariantContext fixtures. New coverage: all three constructors,
return-type semantics (null/undefined/boolean/integer/double/string),
bindings reachability for both `record`/`variant` and `header`,
subclass record-key override (SAM), error paths (malformed JS,
exception-throwing scripts), filterOut(first, second) AND-semantics
(SAM), multi-record reuse, and one assertion that the no-engine
error message stays actionable. 46 new test cases in total.
** Verification **
- ./gradlew test: 21,963 / 21,963 pass.
- ./gradlew dependencies --configuration runtimeClasspath: confirms
nashorn-core and the 5 ASM artifacts are gone; commons-logging now
shows under jexl as 1.1.1 -> 1.3.0 (transitive) plus a (c) constraint
marker rather than as a top-level dep.
The breaking change will be called out in the dedicated v5.0.0
CHANGELOG / breaking-changes PR alongside the other v5.0.0 changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Slim htsjdk's published runtime classpath by making the JavaScript engine an opt-in dependency, with a meaningful test bulk-up around the change.
Net effect for v5.0.0 consumers: 6 fewer jars on the runtime classpath (
nashorn-core+ 5× ASM transitives, ~2.5 MB) and one less misleading "direct dependency" in the published POM.Consumers using
JavascriptSamRecordFilterorJavascriptVariantFiltermust now add a JSR-223"js"engine to their own runtime classpath. The recommended choice is OpenJDK Nashorn:If no engine is on the classpath, the filter constructors now throw
RuntimeScriptExceptionwith a multi-line, fully self-describing message that names the calling filter class and prints both Gradle and Maven coordinates — the failure is supposed to be impossible to misread.This will also be documented in the dedicated v5.0.0 CHANGELOG / breaking-changes PR.
What's in the PR
build.gradleimplementationtocompileOnly. Also added astestImplementationso the project's own JS-filter tests still run.commons-logging:1.3.0declaration. htsjdk does not use commons-logging itself; it was declared only to bump the version thatcommons-jexl:2.1.1transitively pulls (1.1.1, from 2007). Replaced with a Gradle dependency constraint, so the published POM advertises the version pin in<dependencyManagement>rather than as a real<dependency>. Same runtime behavior, more honest metadata.AbstractJavascriptFilter"Do you use the SUN/Oracle Java Runtime?"error with a multi-line, fully self-describing message via a new package-privatenoJsEngineMessage(String)helper.JavascriptSamRecordFilter/JavascriptVariantFilternashorn-coreartifact.Test bulk-up (prep work for the engine swap, but it's good in its own right)
samFilter01.js,samFilter02.js,variantFilter01.js,variantFilter02.js).JavascriptSamRecordFilterTestandJavascriptVariantFilterTestas many small, focused tests using inline String scripts and programmatically-builtSAMFileHeader/VCFHeader/SAMRecord/VariantContextfixtures. 46 new test cases vs the previous 4 effective cases. Coverage now includes:record/variant/header) and subclass record-key override (SAM)filterOut(first, second)AND-semantics (SAM only)Test plan
./gradlew compileJava compileTestJava— passes./gradlew test— 21,963 / 21,963 pass./gradlew spotlessCheck— clean./gradlew dependencies --configuration runtimeClasspath— confirmsnashorn-coreand the 5 ASM artifacts are gone;commons-loggingnow shows under jexl as1.1.1 -> 1.3.0(transitive) plus a(c)constraint marker rather than as a top-level dep.test,formatCheck,spotBugsjobs greenFinal runtime tree consumers will see (post-merge)
8 declared deps + 1 constraint, vs 14 before this PR (across this branch + #1774).