Então, na manhã de ontem, eu não tinha ideia do que OSGi era. OSGi era apenas uma palavra da moda que eu sempre via surgindo indefinidamente, então finalmente reservei um tempo para retocá-la.
Na verdade, parece uma coisa muito legal, então eu gostaria de começar declarando (para registro) que eu não sou anti-OSGi em nenhum aspecto, nem é uma questão "contra OSGi".
No final do dia, parece que a OSGi abordou - essencialmente - a JSR 277 na Modularidade Java, que reconheceu que há falhas na JARespecificação do arquivo que podem levar à resolução de namespace e problemas de carregamento de classe em certos casos esquivos. OSGi também faz muitas outras coisas muito legais, mas pelo que posso verificar, esse é o seu maior atrativo (ou um deles).
Para mim - como um desenvolvedor Java EE relativamente novo (há alguns anos), é absolutamente estonteante que estejamos no ano de 2011 e atualmente vivemos na era do Java 7, e que esses problemas de carregamento de classe ainda estejam presentes; particularmente em ambientes corporativos onde um servidor de aplicativo pode ter centenas de JARs nele, com muitos deles dependendo de diferentes versões um do outro e todos em execução (mais ou menos) simultaneamente.
Minha pergunta:
Por mais interessado que eu esteja em OSGi, e por mais que queira começar a aprender sobre ele para ver onde / se ele poderia ser útil para meus projetos, simplesmente não tenho tempo para sentar e aprender algo tão grande, pelo menos agora.
Então, o que os desenvolvedores não OSGi devem fazer quando esses problemas surgirem? Quais soluções Java (Oracle / Sun / JCP) existem atualmente, se houver? Por que o Jigsaw foi cortado do J7? Qual é a certeza da comunidade de que o Jigsaw será implementado no próximo ano no J8? É possível obter o Jigsaw para o seu projeto mesmo que ele ainda não faça parte da plataforma Java?
Acho que o que estou perguntando aqui é uma combinação de pânico, intriga e palma da mão. Agora que finalmente entendi o que é OSGi, simplesmente não "entendo" como algo como o Jigsaw levou mais de 20 anos para se concretizar e como isso poderia ter sido eliminado de um lançamento. Parece fundamental.
E, como desenvolvedor, também estou curioso para saber quais são minhas soluções, sem OSGi.
Além disso, Observação : sei que esta não é uma pergunta do tipo " programação pura ", mas antes que alguns de vocês fiquem com o nariz torto, gostaria de declarar (novamente, para registro) que deliberadamente coloquei esta questão TÃO. Isso porque não tenho nada além do máximo respeito pelos meus colegas SOers e estou procurando uma resposta de nível arquitetônico de alguns dos "Deuses da TI" que vejo espreitando por aqui todos os dias.
Mas, para aqueles de vocês que absolutamente insistem que uma pergunta SO seja apoiada por algum segmento de código:
int x = 9;(Obrigado a todos que puderem opinar sobre essas coisas OSGi / Jigsaw / classloader / namespace / JAR!)
fonte
Respostas:
Primeiro entenda que o principal caso de uso do Jigsaw é modularizar o próprio JRE. Como objetivo secundário, ele oferecerá um sistema de módulo que pode ser usado por outras bibliotecas e aplicativos Java.
Minha posição é que algo como o Jigsaw provavelmente é necessário apenas para o JRE, mas criará muito mais problemas do que afirma resolver se for usado por outras bibliotecas ou aplicativos Java.
O JRE é um caso muito difícil e especial. Tem mais de 12 anos e é uma bagunça assustadora, crivada de ciclos de dependência e dependências sem sentido. Ao mesmo tempo, é usado por aproximadamente 9 milhões de desenvolvedores e provavelmente bilhões de sistemas em execução. Portanto, você absolutamente não pode refatorar o JRE se essa refatoração criar alterações significativas.
OSGi é um sistema de módulo que ajuda você (ou mesmo o força a) criar software modular. Você não pode simplesmente espalhar modularidade sobre uma base de código não modular existente. Transformar uma base de código não modular em modular inevitavelmente requer alguma refatoração: mover as classes para o pacote correto, substituir a instanciação direta pelo uso de serviços desacoplados e assim por diante.
Isso torna difícil aplicar OSGi diretamente à base de código do JRE, mas ainda temos um requisito para dividir o JRE em partes separadas ou "módulos" para que as versões reduzidas do JRE possam ser entregues.
Portanto, considero o Jigsaw como uma espécie de " medida extrema " para manter o código JRE vivo enquanto o divide. Ele faz não código ajuda a se tornar mais modular, e estou convencido de que ele vai realmente aumentar a manutenção necessária para evoluir qualquer biblioteca ou aplicativo que usa-lo.
Finalmente: OSGi existe enquanto o Jigsaw ainda não existe e pode nunca existir. A comunidade OSGi tem 12 anos de experiência no desenvolvimento de aplicativos modulares. Se você está seriamente interessado em desenvolver aplicativos modulares, OSGi é o único jogo da cidade.
fonte
É simples, se você deseja fazer desenvolvimento real baseado em componentes em Java hoje, OSGi é o único jogo na cidade.
Na minha opinião, o Jigsaw é uma combinação de um compromisso do que é viável no JDK e um relacionamento ruim anterior entre a SUN e os caras do OSGi. Talvez venha com Java 8, mas temos que esperar para ver.
OSGi não é uma panacéia se você está trabalhando em um ambiente corporativo típico e precisa se familiarizar com como funciona o carregamento de classes, pois várias bibliotecas conhecidas (olhando para você, Hibernate) fizeram suposições sobre a visibilidade da classe que não são mais válidas dentro do OSGi.
Gosto do OSGi, mas não tentaria adaptá-lo a um sistema existente. Eu também pesaria os prós e os contras em termos de desenvolvimento greenfield - eu recomendaria olhar para os produtos Apache ou Eclipse que simplificam a vida do OSGi e não fazer tudo sozinho.
Se você não está usando OSGi, então você está sem sorte se você criou um sistema que tem dependências em diferentes versões da mesma biblioteca - tudo que você pode fazer é tentar evitar o problema, embora precise de várias versões de um biblioteca parece um 'cheiro' de arquitetura para mim.
fonte
Adoro o uso da expressão "casos extremos" para descrever a situação atual.
De qualquer forma, há muitos anos me interesso por ferramentas e técnicas que apóiem a criação e, melhor ainda, imponham código que seja mais limpo, mais desacoplado, mais coerente e mais sustentável do que o que provavelmente teria sido o resultado sem elas. O Test Driven Design e o Junit foram uma combinação dessas.
Depois de passar alguns meses movendo uma parte substancial de nossa base de código para o OSGi, eu diria que o OSGi é uma ferramenta ainda melhor nesse aspecto. E isso é realmente um motivo suficiente para mudar para OSGi. No longo prazo, você economizará muito dinheiro.
E, como bônus, você terá a chance de fazer muitas coisas legais. Imagine, durante uma demonstração, atualizar perfeitamente o módulo de autenticação, sem perda de tráfego, para suportar OAuth ... de repente, é uma alegria criar coisas!
fonte