feat(java, info): Add more java info tests

[Thespica]

Reason for this PR

Add more java info tests to cover our code. #741

What changes are included in this PR?

Add tests for java info.

Are these changes tested?

yes.

Are there any user-facing changes?

No.

[Thespica]

This PR is ready to review now : )

[Copilot]

Pull Request Overview

This PR adds comprehensive test coverage for the Java GraphAr info module to better test the codebase. The changes introduce over 1,600 lines of new test code covering the core GraphAr data structures and file system operations.

• Adds unit tests for core classes including VersionInfo, Property, PropertyGroup, and AdjacentList
• Introduces utility classes for test data creation, verification, and file system management
• Enhances existing GraphSaverTest with better structure and additional test scenarios

Reviewed Changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
VersionInfoTest.java	Comprehensive tests for VersionInfo including type checking, user-defined types, and edge cases
TestVerificationUtils.java	Utility class providing reusable verification methods for GraphInfo components
TestDataFactory.java	Factory class for creating consistent test data objects across test suites
PropertyTest.java	Tests for Property class covering all data types, flag combinations, and edge cases
PropertyGroupTest.java	Tests for PropertyGroup including iteration, immutability, and property management
MultiFormatGraphInfoTest.java	Tests for complex GraphInfo scenarios with multiple formats and edge cases
GraphSaverTest.java	Enhanced test structure using base class and utility methods for file operations
BaseFileSystemTest.java	Base class providing common file system operations for tests requiring file I/O
AdjacentListTest.java	Tests for AdjacentList covering all adjacency types and file formats

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[SemyonSinchenko]

I still have a more generic question. Do we still want to rely on FFI? Or maybe I did it wrong and these tests are for the new pure java?

[yangxk1]

I still have a more generic question. Do we still want to rely on FFI? Or maybe I did it wrong and these tests are for the new pure java?

These tests are for java-info(pure java).
I don't think we need to maintain java-FFI anymore, it will stay at v0.12.0

[SemyonSinchenko]

I still have a more generic question. Do we still want to rely on FFI? Or maybe I did it wrong and these tests are for the new pure java?

These tests are for java-info(pure java). I don't think we need to maintain java-FFI anymore, it will stay at v0.12.0

Thanks for the explanation. Is it a good time to merge it, if we want to modify the core part to avoid using of any concrete implementation of FileSystem? At the moment, java-info rely on Hadoop, for example. If we want to force developers to provide an implementation for paths resolving and reading/writing, the code of LocalYamlGraphLoader and LocalYamlGraphSaver will be changed.

[yangxk1]

I plan to refactor java-info YamlLoader as soon as possible.

For loader: Instead of abstracting away the GraphInfoLoader interface, we can put the interface abstraction into the lower level YamlLoader

public class GraphInfoLoader {
    public static GraphInfo load(String graphYamlPath, YamlReader yamlReader) throws IOException {
        final Path path = FileSystems.getDefault().getPath(graphYamlPath);
        // load graph itself
        String yaml = yamlReader.readYaml(graphYamlPath);
        Yaml GraphYamlLoader = new Yaml(new Constructor(GraphYaml.class, new LoaderOptions()));
        GraphYaml graphYaml = GraphYamlLoader.load(yaml);
        ...
     }
}

interface YamlLoader is used to handle io, e.g.

public class LocalFileSystemYamlLoader implements YamlReader{
    String readYaml(String path) throws IOException{
         return java.nio.file.Files.readString(Path.of(path));
    }
}

For Saver:
Do we still need to provide this interface? we can only provide String dump()

[SemyonSinchenko]

For Saver:
Do we still need to provide this interface? we can only provide String dump()

We need to resolve all the relative paths. For example, from Graph.save we should save also all the vertex.yaml and edge.yaml. The same about reader. That is why I see the best way is to make abstract classes with required methods like readString(String path) and resolvePath(String relativePath)... With these abstract methods we will be able to hide all other logic of resolving all the sub-yamls.

[SemyonSinchenko]

Or even DataInputStream read(String path)

[yangxk1]

I agree, I can try to do it

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.77%. Comparing base (1b9c1cc) to head (b075363).

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #739      +/-   ##
============================================
+ Coverage     75.66%   77.77%   +2.11%     
+ Complexity      454      234     -220     
============================================
  Files            82       25      -57     
  Lines          8543      918    -7625     
  Branches        961       49     -912     
============================================
- Hits           6464      714    -5750     
+ Misses         1881      167    -1714     
+ Partials        198       37     -161     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Thespica]

Need to fix those skiped tests before merge

[yangxk1]

This name may be unclear about its role