With JSpecify now a dependency of pkl-config-java, this moves the
non-null annotation to jspecify's.
This makes it simpler for users to do nullness checks, as tooling
already understands JSpecify nullness annotations.
Motivation:
Config.as() causes nullness warnings when its result is intentionally assigned
to a non-null variable
Changes:
* Introduce Config.asNullable(Class<T>), asNullable(JavaType<T>), and
asNullable(Type) to explicitly opt into nullable values
* Keep the signatures of Config.as(Class<T>) and Config.as(JavaType<T>)
unchanged from 0.31 by adding @NullUnmarked
* This gives users time to migrate from as() to asNullable() where appropriate
* Avoids introducing new spurious warnings
* Change `<T> T Config.as(Type)` to `<T extends @nullable Object> T Config.as(Type)`
* This overload is typically used by reflective code such as
pkl-config-kotlin's Config.to() rather than directly by user code
* Clarify that JavaType<T> represents a non-null top-level type whose type arguments may be nullable
* Restricting <T> to non-null keeps method signatures understandable for humans and tools
* Enables full symmetry between Class<T> and JavaType<T> overloads in Config and JavaType
* Enables future non-null runtime checks in both Config.as() overloads
* Simplify construction of `JavaType`s with nullable type arguments
* Add ofNullable() variants for most factory methods, e.g., JavaType.listOfNullable()
* Overhaul Javadoc of Config and JavaType
Result:
* Clear separation between accessing nullable and non-null values
* Config.as() is used for the common non-null case
* Config.as() can perform non-null runtime checks in a future release (breaking change)
* More ergonomic construction of types with nullable type arguments
* More detailed and consistent documentation
Motivation:
- `Config` mixes configuration representation with decoding logic
- `Config.fromPklBinary()` does not scale as decoding gains options
(e.g., binary versions or formats)
- The decoding API is inconsistent with `ConfigEvaluator`
Changes:
- Introduce `ConfigDecoder` (with builder) and move
`Config.fromPklBinary()` logic into it
- Deprecate `Config.fromPklBinary()` methods for removal
- Add `ConfigDecoder.forKotlin()` extension function
- Update and improve tests
Result:
- Decoding is separated from `Config` and exposed via a dedicated API
- Decoding can evolve independently (e.g., adding options such as binary
versions or supporting new formats)
- Evaluation and decoding APIs follow a consistent design
This doesn't really make sense as part of the `Config` API.
We can maybe make class `ConfigUtils` public, but, I don't know how useful it
is anyways; it's more of an implementation detail.
Implements a binary renderer for Pkl values, which is a lossless capturing of Pkl data.
This follows the pkl binary format that is already used with `pkl server` calls, and is
made available as a Java API and also an in-language API.
Also, introduces a binary parser into the corresponding `PObject` types in Java.
* Polish rewrite docs
* Add documentation comments, add missing evaluator options
* Add ability to set HTTP builder in ConfigEvaluatorBuilder
* Add ability to set rewrites in executor API
JaCoCo automatically excludes methods and classes annotated with @Generated from the coverage reports. This is very important to us as generated code should not normally be included in the coverage report. We want to measure the coverage of the code that we actually wrote and maintain, not the code that was automatically generated by tools.
By introducing a property generatedAnnotation (default value false) one could enable writing @Generated on Java types to be generated.
Co-authored-by: Nullpointer <mike.schulze@tealium.com>
This introduces a new `Bytes` standard library class, for working with
binary data.
* Add Bytes class to the standard library
* Change CLI to eval `output.bytes`
* Change code generators to map Bytes to respective underlying type
* Add subscript and concat operator support
* Add binary encoding for Bytes
* Add PCF and Plist rendering for Bytes
Co-authored-by: Kushal Pisavadia <kushi.p@gmail.com>
This changes the file paths to use characters that are safe for Windows.
Channges the output of the following:
* Package cache directory
* Generated pkl-doc files
* Kotlin generated code
Unsafe characters are encoded as (<hex>).
For example, the colon character `:` is encoded as `(3a)`.
Additionally, this changes the cache directory prefix (package-1 to
package-2).
Follows the design of https://github.com/apple/pkl-evolution/pull/3
Fix all IntelliJ warnings in Java production code except for
bogus spelling warnings and warnings about unused public methods.
Also fix some warnings emitted by Code->Inspect Code.
Changes made:
- use text block instead of string concatenation
- extract method to avoid code duplication
- use switch expression
- fix Javadoc syntax and spelling
- fix spelling in comment
- increase class visibility to match visibility of use site
- delete overriding method with same implementation
- use String.isEmpty() and StringBuilder.isEmpty()
- add @Serial annotation
- make field final
- remove unused field
- remove unused private method
- remove exceptions that aren't thrown from throws clause
- insert non-null assertion
- annotate overriding method with @Nonnull
- suppress warning
- delete unused class (WriteAuxiliarySlotNode)
- add final modifier
- remove unused error message
- repeat @Nullable modifier in overriding method
- remove never thrown exception from throws clause
- remove redundant suppression
- Refactor code to use the following basic Java 17 features:
- pattern matching for instanceof
- @Serial annotation
- switch expressions
- enhanced switch statements
- StringBuilder.isEmpty()
- Replace two switch statements with simpler if statements.
- Rename a few local variables.
Daniel Chao