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

Subclasses of TypeName return TypeName from copy #1967

Open
Vampire opened this issue Aug 23, 2024 · 4 comments
Open

Subclasses of TypeName return TypeName from copy #1967

Vampire opened this issue Aug 23, 2024 · 4 comments

Comments

@Vampire
Copy link

Vampire commented Aug 23, 2024

If you for example call copy on a ClassName, you get TypeName returned.
The copy with tags parameter is overridden in the subclasses and returns the respective subclass.
But the copy without tags parameter always returns TypeName.

It would be nice if TypeName could get a type parameter that the subclass sets to itself and then both copy functions return the actual subclass.

@Egorand
Copy link
Collaborator

Egorand commented Aug 26, 2024

Seems like that would break binary compatibility, so we'd have to postpone the fix until 2.0.

@Vampire
Copy link
Author

Vampire commented Aug 26, 2024

Are you sure it breaks binary backwards compatibility?
I remember a similar case where in the JVM stdlib ByteBuffer.flip was changed to be overwritten and return ByteBuffer in Java 9 when before it was inherited from the superclass and thus returned Buffer.
If you now compile ByteBuffer.allocate(2).flip(); with Java 8 it runs on Java 8 and Java 11.
If you instead compile with Java 11 (with source and target set to 8), it runs on Java 11 but throws java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; on Java 8.

Derived from that, I'd say it is a backwards compatible change but not a forward compatible one.
So as long you do not support compiling against 1.19.0 while running against 1.18.1, I'd say it should be fine.

This should of course be tested, and I'm not in a rush as I have a work-around.
Just wanted to mention that I think this might not be breaking.
Not more than adding a new method for example.

@ZacSweers
Copy link
Collaborator

It should be binary-compatible to specify a type, it would be an issue the other way around

@Egorand
Copy link
Collaborator

Egorand commented Aug 27, 2024

Makes sense, thanks! Guess yeah, we should be fine since we'll be changing the return type to subtype.

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

No branches or pull requests

3 participants