The new name is consistent with existing names JavaCodeGenerator and CliJavaCodeGeneratorOptions.
Backward compatibility is ensured by turning JavaCodegenOptions into a (deprecated) type alias.
Also: deprecate `CliJavaCodeGeneratorOptions.toJavaCodegenOptions()`
codegen-java:
- use `pattern.pattern()` instead of `pattern` in hashCode method
(consistent with equals method)
codegen-kotlin:
- use `regex.pattern` instead of `regex` in hashCode method
(consistent with equals method)
- if a data class has a Regex property, generate not only
an equals method but also a hashCode method
* Encapsulate message transport by removing `ExternalReaderProcess.getTransport` and adding `getModuleResolver` and `getResourceResolver` methods
* Reuse `Random` instances within `ExternalReaderProcessImpl` and module/resource resolvers
* Externalize all `ExternalReaderProcessException` messages
* Add some missing doc comments to `ModuleKeyFactories` and `ResourceReaders` methods for external readers
* Move org.pkl.core.util.Readers to org.pkl.core.Readers
This adds a new feature, which allows Pkl to read resources and modules from external processes.
Follows the design laid out in SPICE-0009.
Also, this moves most of the messaging API into pkl-core
Motivation:
In Spring Boot 3.0, the annotation type `org.springframework.boot.context.properties.ConstructorBinding`
was deprecated in favor of `org.springframework.boot.context.properties.bind.ConstructorBinding`.
In 3.2, the old annotation type was removed.
As of 3.0, a `@ConstructorBinding` annotation is no longer required/recommended for configuration classes with a single public constructor.
Changes:
Remove generation of `@ConstructorBinding` annotations in codegen-java and codegen-kotlin.
Result:
- Generated code is compatible with Spring Boot 3.x.
(Verified with locally updated pkl-spring.)
- Generated code is no longer compatible with Spring Boot 2.x.
To use Pkl 0.27 and later with Spring Boot 2.x, use Pkl 0.26's code generator.
- Fixes#139.
Motivation:
Currently, the condition for making a generated Java class instantiable is "class is neither abstract nor stateless".
(An instantiable class receives a public constructor and equals/hashCode/toString/with methods.)
This is inconsistent with Pkl and codegen-kotlin, both of which support instantiation of stateless classes.
Changes:
Widen condition for making a class instantiable to "class is neither abstract nor a stateless final module class".
This is consistent with codegen-kotlin, which generates object declarations (only) for stateless final module classes.
Result:
Stateless classes are instantiable in Pkl, codegen-java, and codegen-kotlin.
Motivation:
- Currently, the condition for generating equals/hashCode/toString methods is "generated class declares properties".
As a result, classes that don't declare properties inherit these methods from their generated superclasses.
However, generated `equals` and `toString` methods aren't designed to be inherited
and will either fail or produce wrong results when called for a subclass.
- Currently, the condition for generating `with` methods is "class is not abstract".
However, it isn't useful to generate `with` methods for non-instantiable non-abstract classes.
- Currently, the condition for making classes serializable is "class is not a module class".
However, it isn't useful to make non-instantiable non-module classes serializable,
and it is useful to make instantiable module classes serializable.
Changes:
- Change condition for generating equals/hashCode/toString/with/Serializable to "class is instantiable".
This is a breaking change.
(A generated class is instantiable, i.e., declares a public constructor,
if it is neither abstract nor stateless. This behavior remains unchanged for now.)
- Overhaul JavaCodeGeneratorTest
- introduce classes JavaSourceCode and JavaSourceCodeAssert
- change assertions to use JavaSourceCodeAssert via `assertThat(javaCode)`
- use parameterized test instead of loop
- use explicit trimIndent() and trimMargin() for multiline string literals
- IntelliJ editor desperately wants to insert trimIndent()
- can potentially be exploited by kotlinc and ktfmt
Result:
- Fixes all motivating issues.
- Fixes#706.
Adds a `rename` field to the Java/Kotlin code generators that allows renaming packages and classes during codegen.
* Add `--rename` flag to CLIs
* Add `rename` property to Gradle API
- Update google-java-format to a version compatible with JDK 21 and run "gw spotlessApply".
- Fix wrong test assumption
JavaCodeGenerator writes a properties file using java.util.Properties,
which doesn't guarantee order of entries.
- Fix most deprecation warnings
- Add CI job for JDK 21
