Java 8 Compatibility / Separate Java 8 Branch?

[AlexeyKuznetsov-DD]

Hi!

First of all, thank you for this amazing library — we really love it. We’re currently migrating from Spock to JUnit, and your project is almost a 1:1 replacement for Spock data tables. It fits our needs perfectly.

However, our project must remain compatible with Java 8.

Out of curiosity, I tried checking out your project and asked an AI tool to refactor it to be Java 8–compatible. Surprisingly, it took about 15 minutes to migrate, and all tests passed successfully.

This made me wonder:

Would you consider maintaining a separate Java 8–compatible branch?
We’d be happy to share the changes or help maintain it if that would be useful.
Please take a look at the diff I created with Codex, all tests are passing locally.

java8.diff.zip

Looking forward to your thoughts — and thanks again for the great work!

[nchaugen]

Thanks for the kind words — glad to hear TableTest fits well as a Spock data table replacement!

I appreciate the effort with the Codex migration, and I can see why it looks straightforward at first glance. However, Java 8 compatibility isn't something I'd want to maintain, for a few reasons:

A central feature of TableTest is the table defined as a text block inside the @TableTest annotation. Text blocks require Java 13+. Without them, the table would need to be expressed as concatenated strings or escaped newlines, which would defeat the purpose — the readability of the table is the feature. The IDE plugins and other tooling around TableTest also depend on text blocks being present.

Beyond that, the library makes deliberate use of modern Java features, making a Java 8 version costly to maintain in parallel.

That said, here are two options worth exploring for your situation:

1. JUnit's built-in @ParameterizedTest — with @CsvSource or @MethodSource, you can get tabular test data on Java 8. It's not as clean as TableTest's format, but it works well and is widely supported.
2. Use a different Java version for tests — if your production code targets Java 8, your tests don't have to. You can compile and run tests with Java 21 while keeping your production source/target at Java 8. This way you could use TableTest as-is. Your build tool (Maven/Gradle) can be configured to use different source/target levels for src/main vs src/test.

Hope one of those paths works for you!

[AlexeyKuznetsov-DD]

Thanks for quick answer.

1. As for java 8 and multiline, I found a nice workaround, just add | at the end of line, so it will looks like:

    @TableTest(
            "Scenario                        | Year               | Is Leap Year?|" +
            "Not divisible by 4              | {1, 2001, 30001}   | No           |" +
            "Divisible by 4                  | {4, 2004, 30008}   | Yes          |" +
            "Divisible by 100 but not by 400 | {100, 2100, 30300} | No           |" +
            "Divisible by 400                | {400, 2000, 30000} | Yes          |" +
            "Year 0                          | 0                  | Yes          |" +
            "Negative input                  | -1                 | No           |"
        )

Pretty much as modern Java :)

2. Yep. Maintain Java 8 version is not an easy task... But my hope was that AI can easily do that.
3. We can not use other Java for tests, our use case is very specific, we literally have to run tests under specific JVM, and code compiled always for Java 8 (with some exclusions).
4. How about fork that I would maintain? Any objections?

[nchaugen]

Thanks for the context on your scenario — that's a very specific constraint.

On the | workaround: I couldn't get it to work as-is — without line breaks the rows collapse into one. Replacing the trailing | with \n works though:

  @TableTest(
      "Scenario           | Year               | Is Leap Year?\n" +
      "Not divisible by 4 | {1, 2001, 30001}   | No           \n" +
      "Divisible by 400   | {400, 2000, 30000} | Yes          \n"
  )

Good to know the IntelliJ plugin renders this correctly, even if auto-format doesn't apply.

I should say — the string-concatenated format actually reads better than I expected! That said, @CsvSource does cover the basic tabular case if you're on standard JUnit. The main things it can't replicate are value sets like {1, 2001, 30001} and nested collections — worth knowing if those matter to you.

Out of curiosity: without the inline formatting and auto-format tooling, what are the TableTest features you find most valuable?

On the fork: I'd prefer to hold off on a separate published artefact for now — TableTest is still establishing itself and multiple Maven coordinates could be confusing. I've started looking into how to best support older Java versions and would rather that land as an official release if it happens.

[AlexeyKuznetsov-DD]

Thank you!
We are in early stage of migration from Spock too.

On the | workaround: I couldn't get it to work as-is

Hmm, did you checked my diff? I did not coded any logic my self, just ask Codex to migrate to Java 8 and implement support for both trailing | and \n. And all unit and event compatibility tests passed.

Out of curiosity: without the inline formatting and auto-format tooling, what are the TableTest features you find most valuable?

I like the possibility to provide sets, lists and maps in clear human-readable way
And also the possibility to provide Custom type converter method

On the fork: I'd prefer to hold off on a separate published artefact for now

Sure. We will test this approach by adding those classes as internal module, no published artifacts.

I've started looking into how to best support older Java versions

That would be the best solution for us.

[AlexeyKuznetsov-DD]

Just my 2 cents on older Java support: I see that you used fancy Java 21 features, but in general code is not that complex and if you check my diff Java 8 version is not super different from Java 21 and I bet it could be even better as I did not put any efforts in making it elegant, just used Codex and not even ask for cross review from Claude for example.

But my prototype is working and looks not that ugly without Java 21 multiline feature.

There a lot of old java projects that can benefit from this great library.