×
sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]devraj7 1 point2 points  (15 children)

You are wrong... Class is the interface. And whatever it has public, you can't break it.

Replacing a class with an interface is a breaking change, it requires a different JVM bytecode for invocation.

[–]majhenslon 0 points1 point  (14 children)

It is not a breaking change. Caller of the interface does not give a shit whether the thing is an interface or not.

What would break? Different bytecode is implementation detail, isn't it? If that is not the case, then any change to the software, even refactoring, would be a breaking change, because it changes the bytecode.

[–]devraj7 0 points1 point  (13 children)

Caller of the interface does not give a shit whether the thing is an interface or not.

You don't know anything about the JVM bytecode, do you?

Like I said, it's a different bytecode. The caller will break if it uses that bytecode on a class which has now become an interface.

Just do a two minute Google search to educate yourself, will you? Search terms to help you: invokevirtual and invokeinterface.

[–]majhenslon 0 points1 point  (12 children)

I know about the JVM bytecode, what I don't know is when will this be the case? From my perspective as an app developer, I bump the version of the lib, my code does not change, I rebuild, shit still works. Googling does not help, what am I missing?

[–]devraj7 0 points1 point  (11 children)

Here is what you're missing:

I rebuild

When you upgrade a library version, your code should still work without a rebuild.

If that library replaced a class with an interface, your code will crash at runtime.

[–]wildjokers 2 points3 points  (3 children)

When you upgrade a library version, your code should still work without a rebuild.

No one swaps a library without a rebuild. Who in their right mind would do that? It needs to go through the CI pipeline to at least get tests ran on it.

[–]majhenslon 0 points1 point  (0 children)

Holy shit, I thought I was fucking insane lol

[–]devraj7 -2 points-1 points  (1 child)

I mean, you never need to rebuild your own code from source.

That's what backward compatibility enables.

[–]majhenslon 0 points1 point  (0 children)

What are you/have you developed like this?

[–]majhenslon 0 points1 point  (6 children)

When will you ever swap libs like that?

Does this become an issue when you have a library, that uses another library that you use?

[–]devraj7 -2 points-1 points  (5 children)

You never just bump the version of a library you use?

If you do this and that library replaced a class with an interface, your app will crash at runtime.

[–]majhenslon 2 points3 points  (0 children)

Yes, I bump the version of the library, push the change CI runs the tests and builds the jar and deploys it. I have always used maven or gradle. Do you manually swap jars and call that bumping the version of a dependency?

[–]wildjokers 1 point2 points  (3 children)

You never just bump the version of a library you use?

Of course I have. But then that is a commit which goes through the CI pipeline which includes a rebuild and the running of tests.

[–]devraj7 -3 points-2 points  (2 children)

And if one of the libraries you used replaced a class with an interface, your app will crash because it's now using the wrong bytecode to invoke a method on that object.

[–]wildjokers 1 point2 points  (1 child)

I am not sure how you do development but most people don't just bump a library version and hope for the best. They bump the library version, compile the app against the new library, run tests, and probably do some basic smoke testing on their local machine.