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

Generated encoders / decoders generate warnings when compiled under JDK21 #494

Open
writeoncereadmany opened this issue Sep 27, 2023 · 0 comments

Comments

@writeoncereadmany
Copy link

Generated classes using artio-codecs (including latest snapshot build) generate warnings when compiled under JDK21. We have our build configured to fail on warnings, so this is a blocker to us upgrading to JDK21.

Example:

/HeaderEncoder.java:38: warning: [this-escape] possible 'this' escape before subclass is fully initialized
beginStringAsCopy(DEFAULT_BEGIN_STRING, 0, DEFAULT_BEGIN_STRING.length);

(not all with the same method or on the same generated class)

This is a new linter warning introduced in JDK21: http://marxsoftware.blogspot.com/2023/03/jdk-21-b15-new-xlint-warnings.html

A few possible approaches:

  1. Just suppress the warnings with @SuppressWarnings("this-escape"). I've tested this locally and it works if we apply it to decoder/encoder classes, but it's not very principled.
  2. Make generated endoder/decoder classes final. I'm not sure why anyone would want to extend them, but this would be a breaking change. It also highlights some other issues which aren't worth diving into if that's not a path worth pursuing.
  3. Make just the methods called from constructors final. This is a touch more involved as it requires identifying what methods can be called from constructors, and is still a breaking change albeit a much more minor one
  4. Make any methods called from constructors delegate to a private method, with the constructor calling the private method. That will still allow users to override the method, but not in a way which interferes with construction.

I'm happy to prepare a PR for any of these, my personal preference is 2) as it's the simplest and making it clear that the codecs aren't designed for extension seems like a plus, but that's not really my call to make.

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

1 participant