The code generator will now generate a call to the new
`Internal#createQueue()` factory method instead of directly calling the
`QueueImpl` constructor.
In the generated `CatalogImpl` subclasses the static fields representing
the schemas of the catalog typically don't need a fully qualified class
reference in the initializer expression, since the Java type is imported
already.
Additionally the Javadoc comment of the field representing the default
schema (if any) will now also include the schema's name (before it was
missing).
Fixes the Javadoc comment of the default catalog and schema singletons
generated into the `CatalogImpl` and `SchemaImpl` subclasses. For the
default catalog and schema the name was always empty.
In the generated `SchemaImpl` subclasses the static fields representing
the tables of the schema typically don't need a fully qualified class
reference in the initializer expression, since the Java type is imported
already.
The genereated `SchemaImpl` and `CatalogImpl` subclasses will only
declare methods like `getSchemas0()` and `getTables0()` when necessary.
I.e. when the number of returned definitions exceeds 500.
The names of the XML elements in `jooq-meta-3.13.0.xsd` corresponding to
sequence flags have been changed to conform with the SQL standard.
Additionally the type of the numeric sequence flags have been changed
from `Long` to `BigInteger` and consequently also in other APIs from
`Long` to `Number`.
Adds an overload factory method `Internal#createSequence()` which
accepts the sequence flags as individual parameters. The Java and Scala
code generators now generate code using this factory method.
So far only the `H2Database` knows how to supply the sequence flags to
the code generator. Other dialects supporting sequences will follow in
follow-up commits.
Also note that support for the `ORDER` flag will be added separately
(see jOOQ/jOOQ#9346).
Instead of generating code which directly uses the `SequenceImpl`
constructor, the generator now emits code using a static factory method
in the `Internal` factory class.
Also removes duplicate H2 dependency from `jOOQ/pom.xml`.
The jOOQ 3.12 Open Source Edition will continue to support Java 8. The only things we gain from the JDK 11 dependency is:
- Updated logic for reflection when mapping into proxied default methods (that stuff has changed completely in JDK 9). This is a regression, which we can live with. The workaround is to write a custom
- Explicit dependency on the JDK 9 API, for which we provide a Java 8 compatible alternative via reactive streams anyway.
- JDBC 4.3 compatibility (mostly sharding). We currently don't use that yet.
We're not even using internally, outside of a few integration tests. So, we'll postpone the JDK 11 *requirement* (while supporting it nonetheless) to a later release, e.g. 3.13. We'll observe market share shifts. Currently Java 11's market share is a bit of a disappointment, so making it a requirement might be premature.
