Make generated Interop classes public

[smarr]

The classes generated by the other DSL processors are public.
This change makes the Interop DSL consistent with that and avoids requiring strange workarounds or putting undesirable restrictions on how to divide code into packages.

[jtulach]

I do rely on the classes being non-public in my HTML/Java codebase. All the implementation classes are non-public and I certainly don't want the annotation processor to generate anything public in my case.

Some kind of hint or configuration is needed to support both scenarios, in my opinion.

[smarr]

The current behavior is inconsistent compared to the other annotation processors, so Truffle itself already sets another expectation. (Note also that I only made the classes public that need to be accessible, there are true implementation classes that are not made public.)

[eregon]

@jtulach This is unreasonable. It's generated code, there is no point to see that in documentation or ever be checked-in in a repository. It should be made convenient, like the DSL generated nodes.
JavaObject can remain package-private of course.

[eregon]

One compromise could be to generate a package-private class if the source class is package-private.
But it would neither be very intuitive, nor particularly simple for the user.
I value (as probably most users) those much more than trying to hide classes.
Simplicity is also important in the implementation (so introducing e.g. a new annotation to specify visibility would not be worth it IMO).

[woess]

One compromise could be to generate a package-private class if the source class is package-private.

Sounds reasonable to me.
If the source class is public, the generated class should definitely be public.

[smarr]

@jtulach why do you generate JavaDoc for generated code? There aren't any comments anyway?

[jtulach]

Good start: pkg prvt leads to pkg prvt gen classes.otherwise gen publici
More cntrl needed: add an attribute
Motto: make common easy + complex possible

[graalvmbot]

Warning: some required labels were not added by the current assignee @grimmerm. In a normal review process, the assignee is responsible for adding labels to the pull request.

Contentious labels: accept

[smarr]

I think this one was resolved.