pacotes divididos em java simples

Question

OSGi tem um problema com pacotes divididos, mesmo pacote ou seja, mas hospedado em vários pacotes.

Existem casos de ponta que os pacotes de divisão pode representar problemas em java simples (sem OSGi)?

Apenas curioso.

Answer 1

Para pacotes OSGi em diferentes pacotes são diferentes, independentemente do seu nome, porque cada pacote usa seu próprio carregador de classe. Não é um problema, mas um recurso, para assegurar o encapsulamento de pacotes.

Assim, em Java plain isso normalmente não é um problema, até que você começar a usar alguma estrutura que utiliza carregadores de classe. Isso é tipicamente o caso quando os componentes são carregados.

Answer 2

Onde pacotes divididos vêm de

pacotes divididos (em OSGi) ocorrer quando o Require-Bundle cabeçalho do manifesto é utilizado (como é, creio eu, em manifesta do Eclipse). Require-Bundle nomes que outros pacotes que são usados ??para procurar aulas (se o pacote não é Imported). A pesquisa acontece antes dos pacotes próprio classpath é pesquisado. Isto permite que as classes por um único pacote para ser carregado a partir do exportações de múltiplo feixes (provavelmente frascos distintos).

A especificação OSGi (4.1) seção 3.13 descreve Require-Bundle e tem uma longa lista de conseqüências (inesperados) de usar este cabeçalho (deve este cabeçalho ser obsoleto?), Uma parte do qual é dedicada a pacotes de divisão . Algumas dessas consequências são bizarros (e específico OSGi-vez), mas a maioria são evitados se você entender uma coisa:

• Se um class (em um pacote) é fornecido por mais de um pacote, então você está em apuros.

Se as peças do pacote são disjuntos, então tudo deve estar bem, exceto que você não pode ter as classes visível em todos os lugares e os membros de visibilidade do pacote pode parecer ser privado se visto de uma parte "errado" de um pacote de divisão.

[É claro que é muito simples várias versões de pacotes podem ser instalados, mas do ponto de vista da aplicação a qualquer momento todas as classes de um pacote deve ser adquirido a partir de um único módulo.]

O que acontece em 'Java padrão'

Em Java padrão, sem fantasia classe-carregadeiras, você tem um caminho de classe, ea ordem de procura de frascos (e diretórios) para classes de carga é fixa e bem definidas: o que você tem é o que você recebe. (Mas então, desistimos modularidade administrável.)

Claro, você pode ter pacotes-lo divisão é bastante comum na verdade-e é uma indicação de má modularidade. Os sintomas podem ser erros de compilação / build-time obscuros, mas no caso de múltiplas implementações de classe (um over-monta o restante em uma única classe-path) na maioria das vezes produz o comportamento de tempo de execução obscura, devido à sutilmente diferentes semântica .

Se você é sorte você acaba olhando para o errado código sem perceber e se perguntando "Mas como isso pode ser, possivelmente, fazendo que ? "
Se você é azar você está olhando para o código certo e pedindo exatamente a mesma coisa, porque algo estava produzindo respostas inesperadas.

Isto não é totalmente ao contrário do velho ditado de banco de dados: "se você gravar o mesmo pedaço de informação em dois lugares, muito em breve não será mais o mesmo". Nosso problema é que 'muito em breve' não é normalmente em breve.

Answer 3

pacotes Dividindo todo frascos provavelmente não é uma grande idéia. Eu sugiro fazer todos os pacotes dentro de frascos fechados ("Sealed: true" colocar na seção principal do manifesto). pacotes fechados não pode ser dividido entre frascos.

No caso de OSGi, classes com o mesmo nome do pacote, mas uma classe diferente loader são tratados como se eles estão em diferentes pacotes.

Answer 4

Você obterá um erro de execução desagradável se você tem classes no mesmo pacote e alguns estão em um JAR assinado enquanto outros não são.

Answer 5

Você está perguntando porque o pacote em questão é seu, não código de terceiros?

Um exemplo fácil seria uma aplicação web com camadas de serviços e persistência como pacotes OSGi separadas. As interfaces de persistência teria que ser compartilhada por ambos os pacotes.

Se eu tiver interpretado a pergunta corretamente, a solução seria criar um JAR selada contendo as interfaces comuns e torná-lo parte de ambos os pacotes?

Eu não quero tentar seqüestrar o segmento. Eu estou pedindo esclarecimentos e alguns melhor visão de quem poderia ter feito mais com OSGi até o momento do que eu.