Skip to content

[Tech Debt] Avoid using reflection to load implementation classes of resources during the compilation phase#879

Open
da-daken wants to merge 5 commits into
apache:mainfrom
da-daken:compile_resource_python
Open

[Tech Debt] Avoid using reflection to load implementation classes of resources during the compilation phase#879
da-daken wants to merge 5 commits into
apache:mainfrom
da-daken:compile_resource_python

Conversation

@da-daken

@da-daken da-daken commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Linked issue: #864

Purpose of change

Avoid using reflection to load implementation classes of resources during the compilation phase

Tests

ut test

API

no API

Documentation

  • doc-needed
  • doc-not-needed
  • doc-included

@github-actions github-actions Bot added doc-not-needed Your PR changes do not impact docs fixVersion/0.4.0 priority/major Default priority of the PR or issue. and removed doc-not-needed Your PR changes do not impact docs labels Jul 7, 2026
}

private boolean isPythonResource(ResourceDescriptor descriptor) {
String pythonClazz = descriptor.getArgument("pythonClazz");

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Non-blocking:

The old check identified Python resources by whether clazz was a PythonResourceWrapper, while this now uses the presence of pythonClazz. Since PythonResourceProvider.provide() does not require pythonClazz when module is non-empty, do we want to document the assumption that descriptors reaching this classification path will always carry pythonClazz when they should be treated as Python?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Thanks for your review! I think we should align on a single rule here. Since cross-language Python resources are required to declare pythonClazz, we probably should not leave other entry points open. Today, descriptors that take those alternate paths (e.g. non-empty module without pythonClazz) are classified as Java-side resources at plan-compilation time and fail at runtime. Tightening or closing those paths feels like a separate follow-up issue rather than something we need to solve in this PR—what do you think?

@weiqingy weiqingy Jul 8, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Agreed. Making pythonClazz the single rule and closing the alternate paths is cleaner than documenting the assumption, and it belongs in its own change. Nit: those descriptors classify as Java at compile time and only fail at runtime, so sharpening that into a clearer compile-time error would be a good tracker. Otherwise LGTM.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Given that normal Java AgentPlan paths don’t appear to produce module != empty && pythonClazz missing (module always be ""), I don’t think we need to preserve that old descriptor shape here. It seems limited to manually constructed 3-arg descriptors, so documenting/tightening that contract separately should be enough.

@da-daken

Copy link
Copy Markdown
Contributor Author

@wenjin272 @weiqingy Thanks for your review! I’ve updated the submission. PTAL~

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

doc-not-needed Your PR changes do not impact docs fixVersion/0.4.0 priority/major Default priority of the PR or issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants