En raison d'un problème avec nom de package à p > aux code> sous Windows, je déplace une classe d'assistance dans la hiérarchie de l'emballage de ma bibliothèque de 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
3 Réponses :
Mettez simplement, aucune raison pour laquelle ce ne serait pas. Le lien arrive autour des signatures; Étant donné que l'objet en question est défini sur l'unité de compilation, les clients ne peuvent (ou plutôt pas) l'utiliser et la compatibilité binaire n'est donc pas un problème.
Vous ne spécifiez pas si Si c'était déjà package privé: p>
Je soupçonne que le gestionnaire de migration signale une incompatibilité uniquement car elle doit rester conservatrice: les packages sont ouverts à Scala (comme en Java), ce qui signifie que le code client pourrait très bien définir un package de classe Cependant, soyons pragmatiques: comme pour le client Java STRT>, c'est un peu différent car même si S'il n'était pas package privé avant le déménagement: p>
Bien, chance. Le code client pourrait très bien déjà accéder à assistant code> était déjà package privé avant le déménagement. Je vais donc traiter les deux cas:
scinainainerpter code> .
Donc, en déplaçant assistant code>, vous allez effectivement casser cette classe. P>
de.siss.scalainterprètre.aux code> est votre paquet em> (et devrait donc être leurs sous-packages), et personne ne devrait définir leurs propres cours là.
Avec cette condition préalable supplémentaire, le déplacement assistant code> est en effet un changement compatible binaire vers le code assistant code> est package privé, sa visibilité est toujours public code> en ce qui concerne La JVM est concernée, et donc le compilateur Java permettra de laisser accéder au code client assistant code> (ainsi que le code Java client pourrait très bien déjà accéder à assistant code>, malgré l'être déclaré package privé) . P> li>
assistant code>, et le déménagement va certainement casser cela. En tant que note latérale, vous pouvez utiliser un petit tour pour faire le changement de source compatible avec la source, mais Hélas package de.sciss
package object scalainterpreter {
object aux {
val Helper = _root_.de.sciss.scalainterpreter.Helper
}
}
Merci. Désolé si cela n'était pas clair-oui, assistant est emballé privé avant, rien n'a changé concernant sa visibilité.
Ensuite, vous êtes sur le côté sûr, à condition que vous n'aviez aucune annotation inline, comme indiqué par User1296806. L'annotation inline est généralement injustifiée de toute façon, car la gigue peut la plupart du temps en ligne vos points chauds (en particulier sur un serveur VM).
@ user1296806 Compte tenu de la taille pure de la bibliothèque, quelques centaines de survenus des annotations inline (j'ai trouvé moins de 100 dans la bibliothèque elle-même) est très faible. J'aurais attendu plus. Ce n'est pas comme l'inlinage est jamais utile.
Il est facile de voir comment l'inlinge peut casser le code client, car le code inlinébe saigne essentiellement dans l'interface client. Cet exemple demande vraiment une erreur de liaison; Nous pouvons expérimenter et faire des choses comme Javap | HELPER GREP, mais à un certain niveau, vous devez laisser Scalac faire son travail.
$ scala -cp "classes;target" client.Test Does this help? apm@halyard ~/tmp/taking-it-private $ vi lib.scala apm@halyard ~/tmp/taking-it-private $ rm -rf classes/* apm@halyard ~/tmp/taking-it-private $ smalac -d classes -optimise lib.scala apm@halyard ~/tmp/taking-it-private $ smala -cp "classes;target" client.Test java.lang.ClassNotFoundException: lib.util.Helper$
Bon point, je n'avais pas pensé à l'inliction; semble assez complexe. Heureusement, dans mon cas, il n'y a pas d'annotations inline et je n'ai pas compilé avec -Optimize .
Cette réponse est une réponse à "Je soupçonne que si le code du client n'appelle pas d'objet, ...", à savoir, vous ne pouvez pas raisonner de la source de la source à un compat binaire. Ceci est un exemple où les machines sont visibles et un exemple suffit. Vous pouvez trouver d'autres personnes, avec votre autre question sur Final Val Consts ou implicites. Sinon, votre question est tautologique: soit oui bien sûr vous allez bien, soit bien sûr que non.