Skip to content

Backport H2 to java8 #4250

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 22 commits into
base: master
Choose a base branch
from
Draft

Conversation

toolforger
Copy link

@toolforger toolforger commented Jul 30, 2025

At-your-discretion PR

I just finished backporting H2 to Java 8.
This PR contains the results, both to let you officially know, and for you to decide what to do with it:

Deal with it at your discretion; options that I see are:

  • Use it as the basis for an official Java 8 backport inside the H2 project.
    This might be of interest if there is interest from other users than the one that sponsored my work.
  • Make this the basis for an official Java 8 backport as long as I agree to maintain it.
    I'll be continuing work as long as somebody sponsors this.
    Sponsorship would be cheap, backporting last year's updates was less than a day's work.
  • Just reference my my backport, with a reference to the GitHub repository, in the H2 documentation.
    You'd probably want to clearly say that the backport is independent of the H2 project and any questions should be directed at me, not at the H2 team.
  • Just ignore it.
    I am totally fine with that!

Improvement suggestions gladly accepted!
Including any that make it better conform to H2 conventions. H2 contributors should feel right at home whenever they have reason to work on the code.

Also, downgrade Lucene back to 8.5.2, which was built for Java 8 bytecode.
Java 8 type inference is weaker than in newer Javas.
Map.of() -> Collections.emptyMap()
List.of(x) -> Collections.singletonList(x)
List.of(...) -> Arrays.asList(...)
We exploit that .ofNullable()...filter(Objects.nonNull)
is equivalent to .of()...filter(Objects.nonNull)
TCP_QUICKACK is supported only in Java 10 or later.
These were added to JdbcStatement in Java 9.
I.e. they cannot be used by a Java 8 application,
so removal is the correct choice.
There was a SecurityManager in some situations,
and Unsafe is not allowed there unless you fight for it.

Given that the tests actually run faster without these,
using Unsafe just is not worth it.
VarHandle is far too generic and feature-rich to backport.
Updatable-view classes ByteArrayAs(Int|Float)Array were enough for H2.
# Conflicts:
#	h2/src/test/org/h2/test/scripts/functions/numeric/random-uuid.sql
StackWalker is not yet available in Java 8,
so we stick with the previous implementation.

This reverts commit f0fdc19.
@grandinj
Copy link
Contributor

I would be ok with just keeping this on a separate branch, and then you can merge/etc new stuff to that branch.

@toolforger toolforger marked this pull request as draft July 30, 2025 12:41
@toolforger
Copy link
Author

"Draft" seems better than "PR" until the H2 team has made a decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants