Skip to content

Add a Java binding emitter - #10

Open
itvi-1234 wants to merge 4 commits into
runtimeconditions:mainfrom
itvi-1234:add-java-binding-emitter
Open

itvi-1234 wants to merge 4 commits into
runtimeconditions:mainfrom
itvi-1234:add-java-binding-emitter

Conversation

@itvi-1234

Copy link
Copy Markdown
Member

No description provided.

@danieloh30 danieloh30 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed from correctness, security, and TAG DevEX perspectives. The inline comments cover four correctness/input-handling issues and two developer-experience suggestions.

Validation: source inspection plus a targeted Java 21 planner reproduction for scalar references. The full Gradle suite was not run, and CI status was not independently confirmed.

Comment thread tooling/extension-bindings/README.md
Comment thread .github/workflows/binding-publish-maven.yml Outdated
@itvi-1234
itvi-1234 force-pushed the add-java-binding-emitter branch from e30cf0b to fd3907e Compare October 22, 2026 05:43
@itvi-1234

Copy link
Copy Markdown
Member Author

Thanks @danieloh30 for the suggestions :)

A native emitter, written in Java, turns a normalized binding model into a
typed Maven project: one source file per type under the package's source
tree, pom.xml, and the structural binding manifest. It follows the Python
emitter's command contract: emit, verify, and api.

- Declarations are static methods of Bindings taking a per-kind marker
  interface. Object shapes are records implementing it, so a field of
  another kind, or one from a mismatched provider, does not compile.
- Arrays and maps are wrapper records, unions are sealed interfaces with
  nested variant records, and string domains are enums.
- Input is loaded under the Python emitter's restrictions and validated
  against the shared binding-model schema. Diagnostics use the RCJ prefix.
- verify parses the generated source with the JDK syntax tree API and
  compares its API and manifest with the model plan.
- The binding-manifest schema gains the java language, the toolchain lock
  gains languages.java, and CI gains a verify-java-emitter job and a
  placeholder workflow for Maven publication.

Signed-off-by: itvi-1234 <rjsumit71@gmail.com>
The emitter version now comes from the build, the pom.xml is filled from
templates, and package targets are validated against
package-target.schema.yaml instead of patterns in code. Dependencies take an
optional versionRange, and CONTRACT.md is removed.

Signed-off-by: itvi-1234 <rjsumit71@gmail.com>
Keep the resolved type of scalar, any, and chained definitions instead of
discarding it, so a property that references one no longer gets a null type.
Resolve an imported declaration's package from its owner's own dependency
entry, so root -> middle -> leaf imports the marker from leaf. Compare
pom.xml during verification, read inputs through a bounded stream so an
oversized file is rejected before it is held in memory, and let a package
with no sources verify.

Add a Java quickstart, and make the Maven publication workflow state that it
is a placeholder, reject dry_run false, and record in its summary that
nothing was verified or published.

Signed-off-by: itvi-1234 <rjsumit71@gmail.com>
Replace for (; ; ) and its inner break with a while loop whose condition names
what is left to plan, and explain why it ends: each pass removes the
definitions it plans from pendingDefinitions, so the set only shrinks.

Signed-off-by: itvi-1234 <rjsumit71@gmail.com>
@itvi-1234
itvi-1234 force-pushed the add-java-binding-emitter branch from fd3907e to df8fbed Compare October 23, 2026 06:50
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