A etapa de build do link (fase de build "Link Binary With Libraries" do Xcode) precisa de flags específicas do J2ObjC, que variam dependendo de como o app usa classes Java traduzidas. As sinalizações principais são definidas pelo script de linha de comando j2objcc, mas precisam ser especificadas ao criar com o Xcode.
Bibliotecas de SDK
Essa biblioteca é obrigatória pela implementação JRE do J2ObjC. A não inclusão dessa
biblioteca vai resultar em erros de símbolo indefinido, com nomes que começam com _iconv.
| Biblioteca | Sinalização de link | Descrição |
|---|---|---|
| iconv | -l iconv | Usado por jre_core para codificação e decodificação de caracteres. |
Essas bibliotecas são usadas pela implementação JRE do J2ObjC e podem precisar ser vinculadas ao seu app.
| Biblioteca | Sinalização de link | Descrição |
|---|---|---|
| zip | -l z | Usado por java.util.zip. Você precisará incluir isso se estiver vinculando jre_zip. |
| Segurança | -framework Segurança | Obrigatório para vincular jre_security. |
Caminho de pesquisa da biblioteca
A distribuição do J2ObjC inclui várias bibliotecas estáticas. Para usá-las, seu projeto precisa informar ao vinculador onde encontrá-las.
Geralmente, o caminho de pesquisa da biblioteca precisa incluir _$(j2objcdistribution)/lib, em que a variável _$(j2objcdistribution) é o caminho para sua cópia local de J2ObjC. Por exemplo, se você descompactou um arquivo de lançamento J2ObjC para "/usr/local/", esse caminho vai ser "/usr/local/j2objc".
Importante: não use _$(j2objcdistribution) no projeto. Sempre especifique o caminho real em que você instalou o J2ObjC.
Se você criar o J2ObjC a partir de uma cópia do código-fonte, _$(j2objcdistribution) será o diretório
"j2objc/dist/" da sua cópia. Esse diretório não existirá até que você crie o J2ObjC com make dist.
Xcode: caminhos de pesquisa da biblioteca
Atualize os caminhos de pesquisa da biblioteca do destino do app adicionando _$(j2objcdistribution)/lib (novamente, use o caminho real).
Bibliotecas JRE
Essas bibliotecas implementam classes definidas pela emulação JRE do J2ObjC.
Observação:a biblioteca libjre_core.a contém classes da maioria das outras bibliotecas
de subconjuntos. A maneira recomendada de reduzir o tamanho do app é começar a vincular o app
ao -l jre_core e adicionar as bibliotecas de subconjuntos que resolvem os símbolos ausentes.
Por exemplo, as classes java.io mais usadas estão em libjre_core.a.
Portanto, só inclua a biblioteca libjre_io.a se houver erros de símbolo não resolvidos
com nomes que começam com JavaIo.
| Biblioteca | Sinalização de link | Descrição |
|---|---|---|
| libjre_core.a | -l jre_core | O conjunto mínimo de classes necessárias para a emulação JRE do J2ObjC, referenciada por todos os arquivos de origem gerados. Se as fontes Java traduzidas referenciarem o suporte ao JRE para elementos como rede, XML, SQL etc., outras bibliotecas (abaixo) também precisarão ser vinculadas. |
| libjre_beans.a | -l jre_beans |
Todas as classes
do pacote java.beans. Nem todas as classes Java Beans estão incluídas, já que muitas são usadas apenas por apps Swing e AWT.
|
| libjre_channels.a | -l jre_channels |
Várias classes
dos pacotes java.nio.channels e java.nio.channels.spi.
|
| libjre_concurrent.a | -l jre_concurrent |
Várias classes
dos pacotes java.util.concurrent, java.util.concurrent.atomic
e java.util.concurrent.locks.
|
| libjre_icu.a | -l jre_icu |
Várias classes
de android.icu para oferecer compatibilidade com fusos horários (principalmente para ativar
java.time).
|
| libjre_io.a | -l jre_io |
Várias classes (menos usadas)
do pacote java.io.
|
| libjre_net.a | -l jre_net |
Várias classes
no pacote java.net. No entanto, a classe java.net.URLClassLoader
está em jre_security, enquanto as classes javax.net e
javax.net.ssl estão em jre_ssl.
|
| libjre_security.a | -l jre_security |
A maioria das classes
no pacote java.security (algumas estão em jre_core),
e as classes nos pacotes java.security.*,
javax.crypto.* e javax.security.*.
Se você vincular isso, também vai precisar vincular a estrutura de segurança do iOS.
Consulte Bibliotecas do SDK.
|
| libjre_sql.a | -l jre_sql |
Todas as classes
no pacote java.sql.
|
| libjre_ssl.a | -l jre_ssl |
Todas as classes
nos pacotes javax.net e javax.net.ssl.
|
| libjre_time.a | -l jre_time |
Todas as classes
no pacote java.time.
|
| libjre_util.a | -l jre_util |
Várias classes
dos pacotes java.util e
java.util.logging. No entanto, a maioria das classes java.util
está em jre_core. Portanto, só inclua essa biblioteca se houver
erros de símbolo JavaUtil* não resolvidos
(os símbolos JavaUtilConcurrent* estão na
biblioteca jre_concurrent).
|
| libjre_xml.a | -l jre_xml |
Todas as classes
dos pacotes relacionados a XML, incluindo javax.xml.*,
org.w3c.dom.* e org.xml.sax.*.
|
| libjre_zip.a | -l jre_zip |
Todas as classes
dos pacotes java.util.zip e java.util.jar.
Se você vincular isso, também vai precisar vincular a biblioteca ZIP do SDK. Consulte
Bibliotecas do SDK.
|
libjre_emul.a (-l jre_emul).
A biblioteca jre_emul contém todas as classes incluídas na emulação JRE de J2ObjC. Se um app estiver
vinculado a jre_emul, nenhuma das outras bibliotecas jre_* precisará ser incluída, ou o vinculador
informará erros de símbolos duplicados. Isso ocorre porque jre_emul inclui todas as classes definidas nessas
outras bibliotecas.
Outras bibliotecas J2ObjC
Estas bibliotecas Java e classes de utilitários do Android estão incluídas na distribuição J2ObjC como bibliotecas estáticas:
| Biblioteca | Sinalização de link | Descrição |
|---|---|---|
| libguava.a | -l goiaba | Guava: Bibliotecas principais do Google para Java (link em inglês) |
| libjavax_inject.a | -l javax_inject | A biblioteca de anotações de injeção de dependência JSR-330. |
| libjson.a | -l json | A biblioteca de intercâmbio de dados JSON Esta é a versão Android do JSON, que é um pouco diferente de outras implementações. |
| libjsr305.a | -l jsr305 | As anotações JSR-305 para a biblioteca de detecção de defeitos de software. |
| libjunit.a | -l junit -ObjC | O framework de testes JUnit (em inglês). |
| libmockito.a | -l mockito -ObjC | O framework de simulação Mockito (em inglês) para testes de unidade em Java. |
| libprotobuf_runtime.a | -l protobuf_runtime | Um ambiente de execução do Google Protocol Buffer, otimizado para apps J2ObjC. Apps que usam protobufs J2ObjC precisam compilar os arquivos proto com j2objc_protoc. |
| libandroid_util.a | -l android_util | A biblioteca `android_util` contém um pequeno subconjunto das classes de utilitários da API do Android. O objetivo não é fornecer emulação para um ambiente Android, mas apenas uma maneira de compartilhar classes úteis, como "android.util.Log". |
A sinalização do link -ObjC
A sinalização -ObjC é usada com frequência ao vincular apps iOS, mas ela só é necessária quando as classes e categorias Objective-C precisam ser carregadas dinamicamente a partir de bibliotecas estáticas. Essa sinalização faz com que todas
as classes em todas as bibliotecas estáticas vinculadas sejam incluídas no app, sejam elas usadas
ou não. Portanto, é recomendável que os apps que usam J2ObjC só sejam vinculados à flag -ObjC quando
as classes não forem carregadas durante a execução. Um sintoma ocorre quando JavaLangClassNotFoundException é gerado.
Os frameworks de teste do JUnit e do Mockito dependem muito da reflexão. Portanto, os apps de teste que os usam precisam ser vinculados a -ObjC.
Uma alternativa à vinculação em uma biblioteca estática para que algumas classes possam ser carregadas dinamicamente é referenciar essas classes estaticamente. Em Java, isso pode ser feito em um bloco de inicializador estático. Veja um exemplo da classe IosSecurityProvider do 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
};