Skip to content
New issue

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

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

Already on GitHub? # 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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant