Menu
Because of an issue with package name aux under Windows, I am moving a helper class within the package hierarchy of my library from
de.sciss.scalainterpreter.aux
to
de.sciss.scalainterpreter
The class is private to the library, i.e. private[scalainterpreter] object Helper.
Now using the Typesafe Migration-Manager, obviously it reports that the change is not compatible:
Found 2 binary incompatibiities
===============================
* class de.sciss.scalainterpreter.aux.Helper does not have a correspondent
in new version
* object de.sciss.scalainterpreter.aux.Helper does not have a correspondent
in new version
But I suspect that if client code does not call into either object, the interfaces are still compatible, and thus I can use a minor version increase to indicate the change, and allow those two versions to be used interchangeably.
Correct?
788
One of the most frequent refactorings in large codebases is Move File/Class. With lots of package-private access it will become immediately annoying to do so. Why not to make them public then? At the end both public and package-private expose API of your class.
The package modifier is more accessible than the private modifier. The private modifier is more restricted than a package modifier. Package modifier provides the lowest level of Encapsulation in java. A private modifier provides a higher level of Encapsulation in Java. , generate link and share the link here.
Yes, we can declare a class as private but these classes can be only inner or nested classes. We can’t a top-level class as private because it would be completely useless as nothing would have access to it.
We can’t a top-level class as private because it would be completely useless as nothing would have access to it. can abstract class have final methods in java?
You are not specifying if Helper was already package private before the move. So I'll treat both cases:
If it was already package private:
I suspect that the migration manager reports an incompatibility only because it must stay conservative: packages are open in scala (like in java), which means that client code might very well define a class package scalainterpreter.
So by moving Helper, you would indeed break that class.
However let's be pragmatic: de.sciss.scalainterpreter.aux is your package (and so should be their sub-packages), and nobody should define their own classes there.
With this additional prerequiste, moving Helper is indeed a binary compatible change toward client scala code.
As for client java code, it's a bit different because even if Helper is package private, its visibility is still public as far as the JVM is concerned, and thus the java compiler will happily let client code access Helper (thus client java code might very well already access Helper, despite it being declared package private).
If it was not package private before the move:
Well, tough luck. Client code could very well already access Helper, and the move will certainly break that. As a side note, you can employ a little trick to make the change source-compatible, but alas not binary-compatible. Just add the following file:
package de.sciss
package object scalainterpreter {
object aux {
val Helper = _root_.de.sciss.scalainterpreter.Helper
}
}
With the above, you can still access Helper as de.sciss.scalainterpreter.aux.Helper, and it still compiles under windows (unlike defining a package aux, which does not compile because of the reserved meaning as a file name).
But again, this is not binary compatible, only source compatible.
78
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
