L'étape de compilation des liens (phase de compilation "Link Binary With libraries" de Xcode) nécessite des indicateurs spécifiques à J2ObjC, qui varient en fonction de la manière dont votre application utilise les classes Java traduites. Les indicateurs de base sont définis par le script de ligne de commande j2objcc, mais doivent être spécifiés lors de la compilation avec Xcode.
Bibliothèques SDK
Cette bibliothèque est requise par l'implémentation JRE de J2ObjC. Si vous n'incluez pas cette bibliothèque, des erreurs de symbole non définis se produiront avec des noms commençant par _iconv
.
Bibliothèque | Indicateur de lien | Description |
---|---|---|
iconv | -l iconv | Utilisé par jre_core pour l'encodage et le décodage des caractères. |
Ces bibliothèques sont utilisées par l'implémentation JRE de J2ObjC et devront peut-être être associées à votre application.
Bibliothèque | Indicateur de lien | Description |
---|---|---|
zip | -l z | Utilisé par java.util.zip. Vous devez l'inclure si vous associez jre_zip. |
Sécurité | Sécurité du framework | Obligatoire si vous associez jre_security. |
Chemin de recherche de bibliothèque
La distribution de J2ObjC comprend plusieurs bibliothèques statiques. Pour les utiliser, votre projet doit indiquer à l'éditeur de liens où les trouver.
En règle générale, le chemin de recherche de la bibliothèque doit inclure _$(j2objcdistribution)/lib, où la variable _$(j2objcdistribution) est le chemin d'accès à votre copie locale de J2ObjC. Par exemple, si vous avez décompressé un fichier d'archive de version J2ObjC dans "/usr/local/", ce chemin d'accès serait "/usr/local/j2objc".
Important: N'utilisez pas _$(j2objcdistribution) dans votre projet. Spécifiez toujours le chemin d'accès réel où vous avez installé J2ObjC.
Si vous compilez J2ObjC à partir d'une copie de son code source, _$(j2objcdistribution) est le répertoire "j2objc/dist/" de votre copie. Ce répertoire n'existera pas tant que vous n'aurez pas créé J2ObjC avec make dist
.
Xcode: chemins de recherche de bibliothèque
Mettez à jour les chemins de recherche de la bibliothèque de la cible de l'application en ajoutant _$(j2objcdistribution)/lib (là encore, utilisez le chemin d'accès réel).
Bibliothèques JRE
Ces bibliothèques implémentent des classes définies par l'émulation JRE de J2ObjC.
Remarque:La bibliothèque libjre_core.a
contient des classes de la plupart des autres bibliothèques de sous-ensembles. La méthode recommandée pour réduire la taille de l'application consiste à commencer à l'associer à -l jre_core
, puis à ajouter les bibliothèques de sous-ensembles qui résolvent les symboles manquants.
Par exemple, les classes java.io
les plus couramment utilisées se trouvent dans libjre_core.a
. N'incluez donc la bibliothèque libjre_io.a
qu'en cas d'erreurs de symboles non résolues dont le nom commence par JavaIo
.
Bibliothèque | Indicateur de lien | Description |
---|---|---|
libjre_core.a | -l jre_core | Ensemble minimal de classes requis pour l'émulation JRE de J2ObjC, référencée par tous les fichiers sources générés. Si vos sources Java traduites font référence à la prise en charge de JRE pour des éléments tels que la mise en réseau, XML, SQL, etc., vous devrez également associer les bibliothèques supplémentaires (ci-dessous). |
libjre_beans.a | -l jre_beans |
Toutes les classes du package java.beans . Certaines classes Java Beans ne sont pas incluses, car beaucoup ne sont utilisées que par les applications de swing et d'AWT.
|
libjre_channels.a | -l jre_channels |
Plusieurs classes issues des packages java.nio.channels et java.nio.channels.spi .
|
libjre_concurrent.a | -l jre_concurrent |
Plusieurs classes issues des packages java.util.concurrent , java.util.concurrent.atomic et java.util.concurrent.locks .
|
libjre_icu.a | -l jre_icu |
Plusieurs classes allant de android.icu à la prise en charge des fuseaux horaires (principalement pour activer java.time ).
|
libjre_io.a | -l jre_io |
Plusieurs classes (moins utilisées) du package java.io .
|
libjre_net.a | -l jre_net |
Plusieurs classes dans le package java.net . Cependant, la classe java.net.URLClassLoader se trouve dans jre_security , tandis que les classes javax.net et javax.net.ssl se trouvent dans jre_ssl .
|
libjre_security.a | -l jre_security |
La plupart des classes du package java.security (quelques-unes se trouvent dans jre_core ), ainsi que les classes des packages java.security.* , javax.crypto.* et javax.security.* .
Si vous effectuez l'association, vous devrez également associer le framework de sécurité iOS.
(voir Bibliothèques SDK).
|
libjre_sql.a | -l jre_sql |
Toutes les classes dans le package java.sql .
|
libjre_ssl.a | -l jre_ssl |
Toutes les classes dans les packages javax.net et javax.net.ssl .
|
libjre_time.a | -l jre_time |
Toutes les classes dans le package java.time .
|
libjre_util.a | -l jre_util |
Plusieurs classes du package java.util , ainsi que le package java.util.logging . Cependant, la plupart des classes java.util se trouvent dans jre_core . Vous ne devez donc inclure cette bibliothèque qu'en cas d'erreurs de symbole JavaUtil* non résolues (les symboles JavaUtilConcurrent* se trouvent dans la bibliothèque jre_concurrent ).
|
libjre_xml.a | -l jre_xml |
Toutes les classes des packages XML, y compris javax.xml.* , org.w3c.dom.* et org.xml.sax.* .
|
libjre_zip.a | -l jre_zip |
Toutes les classes des packages java.util.zip et java.util.jar .
Si vous effectuez l'association, vous devrez également associer la bibliothèque ZIP du SDK. (voir Bibliothèques SDK)
|
libjre_emul.a (-l jre_emul)
La bibliothèque jre_emul
contient toutes les classes incluses dans l'émulation JRE de J2ObjC. Si une application est associée à jre_emul
, aucune des autres bibliothèques jre_* ne doit être incluse, sinon l'éditeur de liens signalera des erreurs de symboles en double. En effet, jre_emul
inclut toutes les classes définies dans ces autres bibliothèques.
Autres bibliothèques J2ObjC
Les bibliothèques Java et les classes utilitaires Android suivantes sont incluses dans la distribution J2ObjC en tant que bibliothèques statiques:
Bibliothèque | Indicateur de lien | Description |
---|---|---|
libguava.a | -l goyave | Guava: bibliothèques Google Core pour Java |
libjavax_inject.a | -l javax_inject | Bibliothèque d'annotations d'injection de dépendances JSR-330. |
libjson.a | -l JSON | Bibliothèque d'échange de données JSON Il s'agit de la version Android de JSON, qui diffère légèrement des autres implémentations. |
libjsr305.a | -l jsr305 | Annotations JSR-305 pour la bibliothèque de détection de défauts logiciels |
libjunit.a | -l junit -ObjC | Le framework de test JUnit |
libmockito.a | -l mockito -ObjC | Framework de simulation Mockito pour les tests unitaires en Java. |
libprotobuf_runtime.a | -l protobuf_runtime | Un environnement d'exécution Google Protocol Buffer, optimisé pour les applications J2ObjC. Les applications utilisant des tampons de protocole J2ObjC doivent compiler leurs fichiers proto avec j2objc_protoc. |
libandroid_util.a | -l android_util | La bibliothèque "android_util" contient un petit sous-ensemble des classes d'utilitaires de l'API Android. Il ne vise pas à fournir une émulation pour un environnement Android, mais simplement un moyen de partager des classes utiles telles que "android.util.Log". |
Indicateur de lien -ObjC
L'indicateur -ObjC est fréquemment utilisé lors de l'association d'applications iOS, mais il n'est requis que lorsque les classes et catégories Objectif C doivent être chargées dynamiquement à partir de bibliothèques statiques. Cette option entraîne l'inclusion de toutes les classes de toutes les bibliothèques statiques associées dans l'application, qu'elles soient réellement utilisées ou non. Il est donc recommandé que les applications qui utilisent J2ObjC ne soient associées à l'indicateur -ObjC que lorsque les classes ne se chargent pas au moment de l'exécution (l'un des symptômes est l'apparition de JavaLangClassNotFoundException
).
Les frameworks de test JUnit et Mockito reposent fortement sur la réflexion. Par conséquent, les applications de test qui les utilisent doivent être associées à -ObjC.
Une alternative à la liaison dans une bibliothèque statique complète afin que quelques classes puissent être chargées dynamiquement est plutôt de référencer ces classes de manière statique. En Java, vous pouvez effectuer cette opération dans un bloc d'initialisation statique. Voici un exemple tiré de la classe IosSecurityProvider de J2ObjC:
// Reference all dynamically loaded classes, so they are linked into apps.
@SuppressWarnings("unused")
private static final Class<?>[] unused = {
IosCertificateFactory.class,
IosMD5MessageDigest.class,
IosRSAKeyFactory.class,
IosRSAKeyPairGenerator.class,
IosRSASignature.class,
IosSecureRandomImpl.class,
IosSHAMessageDigest.class
};