Un-vendor org.boris.expr; the jar was already a declared dependency

demos/antiSQLInjection/ carried 365 .java files of a third-party expression
evaluator under org/boris/expr/ -- 57% of every source file in this repo. They
duplicated lib/expr4j.jar, which pom.xml already declares: the jar holds the
same 365 top-level classes and nothing else, so the library shipped twice and
javac quietly compiled the sources while the jar sat unused. Only GEval.java
ever imported it.

Verified rather than assumed, after a codex review pointed out that matching
class NAMES proves nothing about implementation:

  - javap -public -s -constants over all 365 top-level classes: identical.
    The jar's 367 classfiles are Java 5 bytecode (major 49); compiling the
    sources gives 370 at major 52. The 3 extra are $1 synthetics
    (ExprParser$1, ExprTypeUtil$1, SimpleEvaluationContext$1). Nothing the
    source provides is missing from the jar.
  - The existing tests were not testing the jar at all: the vendored sources
    compiled into target/classes and masked it. Re-checked with a clean build
    and -verbose:class, which now shows org.boris.expr loading from
    file:.../lib/expr4j.jar.
  - Full suite still 144 tests with the same 3 known analyzespTest failures.

Two consequences, both documented in the README:

  - The antiSQLInjection demo now requires -Dexec.classpathScope=compile.
    system-scope dependencies are absent from Maven's runtime classpath, so
    under runtime it fails with NoClassDefFoundError on
    org/boris/expr/IEvaluationContext. It only worked there before because the
    classes happened to be in target/classes. dlineageBasic already had this
    same constraint (issue #40); antiSQLInjection now joins it.
  - mvn package no longer bundles org/boris/expr/** into the project jar.
    Nothing consumes that jar as a library, so this is inert today.

Also corrected the dependency's coordinates. It was declared as
tk.pratanumandal:expr4j, which is a completely different library, and would
have pointed SBOM and vulnerability tooling at the wrong project. The jar has a
bare MANIFEST.MF with no version metadata, so it is now identified by content:
sha256 6267d9cb7cabcb24cf02d5bff1d11fdfea8c60c9ba1840dcb45359fb0165ca1b,
recorded in pom.xml alongside a placeholder version.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012qPRpoD8exYRrUmbfXXWXj

Author: 2 people

README.md

@@ -71,7 +71,8 @@ arguments and it prints its own usage line.
 > `<scope>system</scope>`, since they have no public Maven coordinate. Maven's
 > `runtime` classpath scope excludes `system`-scoped dependencies by design, so
 > any demo that touches one of them (e.g. `dlineageBasic`, which uses
-> `org.simpleframework.xml`) fails with `NoClassDefFoundError` under `runtime`
+> `org.simpleframework.xml`, or `antiSQLInjection`, which uses
+> `org.boris.expr`) fails with `NoClassDefFoundError` under `runtime`
 > even though the jar is right there in `lib/`. `compile` scope includes them
 > and works for every demo.
 
@@ -231,6 +232,32 @@ the other directories already use (`joinConvertTest` covers
 `demos.joinConvert`, `antiSQLInjectionTest` covers `demos.antiSQLInjection`,
 and so on). All 20 test files now live under one root.
 
+### The vendored expression library
+
+`src/main/java/gudusoft/gsqlparser/demos/antiSQLInjection/` used to carry 365
+`.java` files of a third-party expression evaluator under `org/boris/expr/`.
+That was **57% of every source file in this repository**, and it duplicated
+`lib/expr4j.jar`, which was already a declared dependency: the jar holds the
+same 365 top-level classes and nothing else, so the library shipped twice and
+javac quietly compiled the sources while the jar sat unused.
+
+The sources are gone; the jar now supplies `org.boris.expr`. Only one file ever
+imported it (`GEval.java`), the `antiSQLInjection` tests cover the path, and
+they pass against the jar. Two consequences worth knowing:
+
+- **The `antiSQLInjection` demo now needs `-Dexec.classpathScope=compile`**, for
+  the `system`-scope reason described above. It used to work under `runtime`
+  only because the classes happened to be compiled into `target/classes`.
+- **`mvn package` no longer puts `org/boris/expr/**` inside the project jar.**
+  Nothing here consumes that jar as a library, so this only matters if you start
+  doing so.
+
+The dependency's coordinates were also wrong: it was declared as
+`tk.pratanumandal:expr4j`, a different library entirely, which would have
+pointed SBOM and vulnerability tooling at the wrong project. It now names what
+is actually on disk, with a checksum recorded in `pom.xml` since the jar carries
+no version metadata of its own.
+
 ## What is excluded from the build
 
 Some demos read metadata straight out of a running database over JDBC, using

pom.xml

@@ -116,13 +116,31 @@
         <systemPath>${project.basedir}/lib/junrar-0.7.jar</systemPath>     
     </dependency>
 
-    <!-- https://mvnrepository.com/artifact/tk.pratanumandal/expr4j -->
+    <!-- The expression evaluator behind demos/antiSQLInjection (GEval).
+         lib/expr4j.jar contains ONLY org/boris/expr/**, that is "Boris Expr",
+         not tk.pratanumandal:expr4j, which this was previously declared as. That
+         coordinate named a completely different library and would have misled
+         SBOM and vulnerability tooling into scanning the wrong project, so it is
+         corrected here to describe the file that is actually on disk.
+
+         The jar carries no version metadata at all (bare MANIFEST.MF, no
+         pom.properties), so the version below is a placeholder, not a real
+         upstream release number. Identify it by content instead:
+             sha256 6267d9cb7cabcb24cf02d5bff1d11fdfea8c60c9ba1840dcb45359fb0165ca1b
+             367 classfiles, Java 5 bytecode (major version 49)
+
+         Until 2026/7/27 this repository also carried all 365 of these classes as
+         vendored .java under demos/antiSQLInjection/org/boris/expr/, so the
+         library was shipped twice and the jar was dead weight. The sources were
+         removed; this jar is now what actually supplies org.boris.expr. Because
+         system scope is absent from Maven's runtime classpath, the
+         antiSQLInjection demo requires -Dexec.classpathScope=compile. -->
     <dependency>
-        <groupId>tk.pratanumandal</groupId>
-        <artifactId>expr4j</artifactId>
-        <version>0.0.3</version>
-                <scope>system</scope>
-        <systemPath>${project.basedir}/lib/expr4j.jar</systemPath>  
+        <groupId>org.boris</groupId>
+        <artifactId>expr</artifactId>
+        <version>0.0.0-vendored</version>
+        <scope>system</scope>
+        <systemPath>${project.basedir}/lib/expr4j.jar</systemPath>
     </dependency>
 <!-- https://mvnrepository.com/artifact/org.jdom/jdom -->
         <dependency>