On 29. 7. 2026 10:58, Daniel Sahlberg wrote:
Den ons 29 juli 2026 kl 04:32 skrev Jun Omae <[email protected]>:
On 2026/07/28 23:58, Daniel Sahlberg wrote:
> Den mån 27 juli 2026 kl 00:09 skrev Jun Omae <[email protected]
<mailto:[email protected]>>:
>
> > Is there a problem if we include the test classes?
>
> No direct issues have been found so far. However, static
initializers within test classes are executed simply by loading
the class.
>
> [[[
> $ grep -r 'static *{' subversion/bindings/javahl
>
subversion/bindings/javahl/tests/org/apache/subversion/javahl/UtilTests.java:
static {
>
subversion/bindings/javahl/tests/org/apache/subversion/javahl/UtilTests.java:
static {
> ]]]
>
>
> Thank you!
>
> I think I got it working on 1.14.x, successfully created a JAR
file without the tests.
>
> It still seems to fail on trunk. Can you do the same steps above
on trunk?
>
> Cheers,
> Daniel
>
Hm, I get the same failures on trunk.
It seems that the changes of the behavior is introduced in r1933892.
At least, ./configure should stop and/or warn it if the junit is
NOT optional when javahl enabled.
[[[
$ /bin/sh autogen.sh
$ ./configure --prefix=/dev/shm/svn/trunk --without-apxs
--without-swig --without-swig-{perl,python,ruby} --enable-javahl
--with-jdk=/usr/lib/jvm/java-11-openjdk-amd64 --without-junit
PYTHON=/usr/bin/python3
$ make -j$(nproc) all
$ make javahl
$ find subversion/bindings/javahl -name '*.class' | wc -l
277
$ find subversion/bindings/javahl -name '*Test*.class' | wc -l
0 #==> tests/**/*.java are compiled yet.
$ make install
$ make install-javahl # Why this task builds tests/**/*.java?
...
/dev/shm/subversion-trunk/subversion/bindings/javahl/tests/org/tigris/subversion/javahl/BasicTests.java:1708:
error: cannot find symbol
assertEquals("wrong revision from commit",
^
symbol: method assertEquals(String,long,int)
location: class BasicTests
/dev/shm/subversion-trunk/subversion/bindings/javahl/tests/org/tigris/subversion/javahl/BasicTests.java:1756:
error: cannot find symbol
assertEquals("wrong revision from update",
^
symbol: method assertEquals(String,long,int)
location: class BasicTests
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
100 errors
]]]
Thanks for confirming! It seems like 1.15.x is also affected by this
(I'll bring it up on the release thread).
To add three more data points to the discussion, I checked Fedora 43,
44 and FreeBSD 14. The tests are present in Fedora's svn-javahl.jar
but not in FreeBSD's svn-javahl.jar. Obviously different distributors
use different options when building. That is unfortunate since we are
distributing different ABIs.
I think it would be cleaner to have the tests in svn-javahl-tests.jar
if built. Maybe we want to install this alongside svn-javahl.jar. That
way Fedora and Ubuntu can keep distributing the tests and FreeBSD not,
while everyone's svn-javahl.jar is the same.
Does that make sense?
The following makes sense:
1. There is no regression in autotools. It is what it is. Note that
putting test classes in a separate jar has wider consequences than just
the ABI. For example, JavaHL tests would fail in autotools builds. We'd
have to change the way the classpath is constructed in `make
check-*-javahl`.
2. No change is needed in 1.15.x. Autotools are consistent with earlier
releases and CMake doesn't build JavaHL. IFF we want to change this in
CMake for 1.15, then we have further questions to consider:
2.1. CMake and Autotools/vcxproj should produce identical results
given identical options. In this case specifically I mean that the
CMake build should create the same lib/dll names and the same JavaHL
jar (singular) as the vcxproj generator.
3. Regardless of the answer to 2: If we decide to not include test
classes in svn-javhl.jar, then we have to consider how to mitigate the
ABI change.
Personally I'd prefer changing the build requirements to changing the
ABI in svn-javahl.jar. That means that --enable-javahl implies that
JUnit is mandatory.
-- Brane
