Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore later classes in Multi-Release jars (snakeyaml-2.2) #882

Open
taylortails opened this issue Feb 1, 2024 · 2 comments
Open

Ignore later classes in Multi-Release jars (snakeyaml-2.2) #882

taylortails opened this issue Feb 1, 2024 · 2 comments

Comments

@taylortails
Copy link

When transpiling org.yaml::snakeyaml::2.2, I found that teavm-maven-plugin::compile::0.9.2 errored because jigsaw (JDK9) logging classes weren't available in teavm-classlib, however....

snakeyaml-2.2 is a Multi-Release jar meaning that both a jdk8 and jdk9 implementations were available in the jar. I therefore worked around the issue by using maven shade to strip out the jdk9 implementation that wasn't currently supported by teavm-classlib.

I propose that teavm compiler should ignore all classes in 'META-INF/versions/**' (where multi version jar stores alternative versions)

@konsoletyper
Copy link
Owner

Oh, it's something exotic, didn't even know about this feature. I think it's a rare case, so I don't think I have enough motivation to implement it. I think this workaround on your side is better in this situation. Another question is: which version do you expect TeaVM to pick?

I think the cleaner way to solve your problem is just to support these logging classes. I think there are many users who benefit from supporting more Java class library methods.

@taylortails
Copy link
Author

which version do you expect TeaVM to pick?

All class implementations under 'META-INF/versions/**' override the implementation in the normal place. I'd suggest you ignore all classes under 'META-INF/versions/**' because they will use newer apis which may not yet have been ported.

I think the cleaner way to solve your problem is just to support these logging classes. I think there are many users who benefit from supporting more Java class library methods.

I have no numbers to be able to confirm or deny this, I assume you are correct.

Thank you for your response, with this suggestion now aired. I suggest it's closed.

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

No branches or pull requests

2 participants