Miocc - O container de injeção de dependência microscópico

[kicolobo]

miocc consiste em um container de injeção de dependência cujo principal objetivo consiste em possuir o menor footprint possível. Em sua primeira versão (0.1, ainda alpha), conseguimos atingir o mínimo tamanho de 21 Kb, o que talvez o coloque entre os menores do mundo.

A razão para tal consiste na necessidade de se resolver (ou pelo menos se tentar) um dos principais problemas da plataforma Java atualmente: a imensa quantidade de jars que precisamos distribuir junto com nossas aplicações quando utilizamos algum framework ou biblioteca externa á API padrão Java, o que impossibilita muitas vezes a execução das mesmas em ambientes com maiores limitações de recursos.

Óbviamente, por se tratar da primeira versão, ainda não encontra-se pronto para uso em ambientes de produção (apesar de já possuir praticamente todos os recursos para tal) , porém com a colaboração de outros desenvolvedores, poderá vir a se tornar uma alternativa bastante viável para projetos com maiores limitações de recursos.

Trata-se de um projeto de código fonte aberto, liberado sob a licença Apache 2.0

Para aqueles que se interessarem em experimentar o miocc, ou mesmo dar a sua contribuição, é possível baixá-lo, assim como o seu código fonte no site http://miocc.itextosoft.com.br

[urubatan]

o XML de configuração dele é praticamente uma cópia das primeiras versões do Spring Framework, e aparentemente o miocc tem menos recursos do que o container de IoC que as primeiras versões do spring tinham, então qual seria a vantagem em usar ele?

E pior que isto:
Mais XML de configuração?!?!?!?!?!?!?!?!?!?!?!

Bom, foi a opinião que tive em no máximo 2 minutos lendo a documentação

[peczenyj]

Haverá algum tipo de suporte a anotações no futuro ?

Ou quem sabe então YAML de configuração ?

[urubatan]

por que não criar algo baseado em padrões e não em mais configuração?
[editado]
Criar mais do mesmo não adianta muito, se não for para inovar, não acho que valha a pena criar YADIF (Yet Another Dependency Injection Framework)
[/editado]

Ao contrario do Guice que seguiu uma abordagem completamente diferente dos que existiam quando ele foi criado, não estou dizendo que ele é melhor ou pior do que qualquer um, só que ele conseguiu pensar de uma forma diferente, se é para fazer igual, vale mais a pena usar o que ja tem

[saoj]

Apesar do esquema de configuração via XML, eu gostei. O que mais tem por aí é gente usando o Spring para fazer um simples IoC da vida… É matar mosca com bazooka…

Ao contrario do Guice que seguiu uma abordagem completamente diferente dos que existiam quando ele foi criado,

Qual foi essa abordagem completamente diferente que o Guice seguiu ?

[kicolobo]

Ubiratan, a grande fonte de inspiração do miocc é o Spring. E a idéia é esta: tendo em vista que a maior parte das pessoas usa o Spring só pelo IoC, não compensa distribuir aquela montanha de arquivos JAR, que ocupam um espaço considerável (pelo menos 2 Mb, diga-se de passagem). Se houver uma alternativa menor (e mais simples), por que não adotá-la? O miocc na primeira versão tem apenas 21 kb.

[cite]
Por que não criar algo baseado em padrões e não masi em configuração?
[/cite]

Resposta: para dar maior liberdade a quem quiser usar o container. Quem deve criar seus padrões, é o desenvolvedor, e não o criador da ferramenta. Não concordo com o fato de você ter de mudar seus padrões, ou mesmo toda a sua aplicação só para se adaptar ao padrão de uma ferramenta.
Optei portanto pelo padrão Java mesmo: javabeans puro e simples.

[cite]
Haverá algum suporte a anotações no futuro?
[/cite]
Resposta: pode apostar. No entanto, não será nativo do container. A opção por um arquivo de configuração ao invés de anotações se deve ao fato de tratar-se de uma abordagem menos intrusiva do que a utilização de anotações.
Anotações são uma boa opção? Sim, mas você estaria disposto a referenciá-las em seu código fonte? Esta é a questão.

[cite]
aparentemente o miocc tem menos recursos do que o container de IoC que as primeiras versões do spring tinham, então qual seria a vantagem em usar ele?
[/cite]
A primeira vantagem consiste em sua simplicidade. o miocc é um container de IoC e apenas isto (ver link: http://www.itexto.net/soft/index.php?modulo=miocc.oque . Você não vai encontrar nele por exemplo recursos de AOP. Ele serve apenas para fazer a injeção de dependências. Isto é o que a maior parte das pessoas faz com o Spring e, no meu caso, é o que faço na maior parte das vezes, o que justifica a sua criação.

(O próximo passo consiste na criação das bibliotecas de integração do miocc com outros frameworks, como o Hibernate por exemplo. Feito isto, no meu caso, pelo menos, poderei substituir o Spring pelo miocc sem pensar duas vezes em alguns casos.)

A segunda vantagem, diz respeito à diminuição significativa do footprint da sua aplicação. O miocc difícilmente terá o seu jar com tamanho maior que 50 Kb (justamente pela limitação do seu escopo de utilização(a próxima versão terá no máximo uns 30 Kb)). Ele não requer dependências externas que não seja a própria API do Java a partir da versão 5.
Na realidade, o único recurso que o miocc ainda não tem (referente à IoC) que as primeiras versões do Spring tinham diz respeito ao gerenciamento de propriedades cujo valor consista em uma lista. Porém, esta limitação vai pro saco nesta semana, pois assim que tiver tempo, pretendo implementá-la.

[peerless]

Parabéns pela iniciativa. O mais interessante, realmente é como o saoj disse: Pra que matar uma formiga com uma bazooka?

E quanto aos testes?

abraços!

[kicolobo]

Opa peerless,
estou desenvolvendo os testes conforme vou desenvolvendo o container.
No código fonte já há alguns testes unitários para aqueles que quiserem dar uma aprimorada no bichinho

[David]

Ubiratan, a grande fonte de inspiração do miocc é o Spring. E a idéia é esta: tendo em vista que a maior parte das pessoas usa o Spring só pelo IoC, não compensa distribuir aquela montanha de arquivos JAR, que ocupam um espaço considerável (pelo menos 2 Mb, diga-se de passagem). Se houver uma alternativa menor (e mais simples), por que não adotá-la? O miocc na primeira versão tem apenas 21 kb.

O core do Spring é 180Kb na versão 2.0.8.

Qual foi essa abordagem completamente diferente que o Guice seguiu ?

O Guice foi o primeiro a usar annotations.

[saoj]

[quote=David]

Qual foi essa abordagem completamente diferente que o Guice seguiu ?

O Guice foi o primeiro a usar annotations.[/quote]

public class MyModule implements Module {
  public void configure(Binder binder) {
    binder.bind(Service.class)
      .to(ServiceImpl.class)
      .in(Scopes.SINGLETON);
  }
}

Fonte: http://docs.google.com/View?docid=dd2fhx4z_5df5hw8

[nadilsons]

Muito boa a iniciativa!

Realmente as dependências do spring às vezes são incômodas.

Meus parabéns… vou testar.

Até

[marciocamurati]

Cara, inicialmente a sua idéia é abstrair o IOC do Spring mantendo a implementação “similar” ? Pois vendo a documentação é isso que me parece, pode ser que seja uma opção interessante após testes e releases para pequenos projetos algo que tenhamos limitação de kb para a aplicação, mas remover o IOC que se utiliza com o Spring para utilizar algum outro não vejo muito sentido.

Uma aplicação com essas caracteristicas menor IOC vejo que teria uma outra abordagem se voltado para J2ME, onde ai sim temos limitações iminentes e preocupações com kbs para tudo, fica ai uma sugestão!

[]s

[urubatan]

[quote=saoj][quote=David]

Qual foi essa abordagem completamente diferente que o Guice seguiu ?

O Guice foi o primeiro a usar annotations.[/quote]

public class MyModule implements Module {
  public void configure(Binder binder) {
    binder.bind(Service.class)
      .to(ServiceImpl.class)
      .in(Scopes.SINGLETON);
  }
}

Fonte: http://docs.google.com/View?docid=dd2fhx4z_5df5hw8

[/quote]
Saoj, o guice consegue funcionar só com anotações, não é necessário este código, esta é uma das abordagens, mas a abordagem diferente que eu me referi, foi a mesma que tu utilizou no menta, utilizar Java para configurar, seja via código ou via anotações.

[urubatan]

[quote=kicolobo]Ubiratan, a grande fonte de inspiração do miocc é o Spring. E a idéia é esta: tendo em vista que a maior parte das pessoas usa o Spring só pelo IoC, não compensa distribuir aquela montanha de arquivos JAR, que ocupam um espaço considerável (pelo menos 2 Mb, diga-se de passagem). Se houver uma alternativa menor (e mais simples), por que não adotá-la? O miocc na primeira versão tem apenas 21 kb.
[/quote]
Bom, o teu footprint é realmente bem menor, para o spring funcionar precisa de pelo menos o commons-logging, spring-[core,beans,context], isto tudo somado da 500k

[cite]
Por que não criar algo baseado em padrões e não masi em configuração?
[/cite]

Resposta: para dar maior liberdade a quem quiser usar o container. Quem deve criar seus padrões, é o desenvolvedor, e não o criador da ferramenta. Não concordo com o fato de você ter de mudar seus padrões, ou mesmo toda a sua aplicação só para se adaptar ao padrão de uma ferramenta.
Optei portanto pelo padrão Java mesmo: javabeans puro e simples.

O que da nos nervos é que tudo em java é flexivel demais, mas nunca lembram de definir um padrão para quem não precisa desta flexibilidade.
Define um padrão, e permita alterar este padrão via configurações, tu vai ver que 90% (número chutado) dos usuários vão utilizar o padrão bem felizes e sem necessidade de alterar nada, os outros 10% terão as configurações para se divertir.

[cite]
Haverá algum suporte a anotações no futuro?
[/cite]
Resposta: pode apostar. No entanto, não será nativo do container. A opção por um arquivo de configuração ao invés de anotações se deve ao fato de tratar-se de uma abordagem menos intrusiva do que a utilização de anotações.
Anotações são uma boa opção? Sim, mas você estaria disposto a referenciá-las em seu código fonte? Esta é a questão.

Resolva isto com meta anotações como fez o spring.

[cite]
aparentemente o miocc tem menos recursos do que o container de IoC que as primeiras versões do spring tinham, então qual seria a vantagem em usar ele?
[/cite]
A primeira vantagem consiste em sua simplicidade. o miocc é um container de IoC e apenas isto (ver link: http://www.itexto.net/soft/index.php?modulo=miocc.oque . Você não vai encontrar nele por exemplo recursos de AOP. Ele serve apenas para fazer a injeção de dependências. Isto é o que a maior parte das pessoas faz com o Spring e, no meu caso, é o que faço na maior parte das vezes, o que justifica a sua criação.

(O próximo passo consiste na criação das bibliotecas de integração do miocc com outros frameworks, como o Hibernate por exemplo. Feito isto, no meu caso, pelo menos, poderei substituir o Spring pelo miocc sem pensar duas vezes em alguns casos.)

Resumindo, tu ta começando a reescrever o spring …
um container de IoC com bibliotecas de integração com outras ferramentas, daqui a dois anos você vai precisar de AOP e vai criar uma biblioteca de integração do miocc com algum framework AOP …

[quote=kicolobo]
A segunda vantagem, diz respeito à diminuição significativa do footprint da sua aplicação. O miocc difícilmente terá o seu jar com tamanho maior que 50 Kb (justamente pela limitação do seu escopo de utilização(a próxima versão terá no máximo uns 30 Kb)). Ele não requer dependências externas que não seja a própria API do Java a partir da versão 5.
Na realidade, o único recurso que o miocc ainda não tem (referente à IoC) que as primeiras versões do Spring tinham diz respeito ao gerenciamento de propriedades cujo valor consista em uma lista. Porém, esta limitação vai pro saco nesta semana, pois assim que tiver tempo, pretendo implementá-la.[/quote]
Bom, concordo que isto pode ser uma vantagem em alguns casos (o tamanho), e que dependências são um saco …
Desejo boa sorte ao projeto, mas de acordo com o que esta escrito no site, e com o que você escreveu aqui neste post, parece que você esta começando a reescrever o spring digavarinho.
e se não for isto, ainda cai no YADIF …

se o esquema fosse só o footprint, era só usar o picocontainer, que ja tem um monte de coisas implementadas, se não estou enganado tem mais tempo de estrada que o spring, é apenas um container IoC (e melhor nisto que o spring), e o jar dele tem apenas 111k …

Mas mesmo assim, boa sorte ao projeto, eu só estava tentando entender por que reinventar novamente a mesma coisa igualzinho o anterior

[David]

Saoj, o guice consegue funcionar só com anotações, não é necessário este código, esta é uma das abordagens, mas a abordagem diferente que eu me referi, foi a mesma que tu utilizou no menta, utilizar Java para configurar, seja via código ou via anotações.

Mas, se não me engano, o Picocontainer já tinha configuração desse tipo, não?

[kicolobo]

Urubatan,
a coisa é muito mais simples do que você está pensando: trata-se apenas de mais um container de IoC, com o diferencial de ser apenas um container de IoC e nada mais e que não precisa de dependência externa alguma.

A idéia não é de maneira alguma reescrever o Spring. É apenas substitui-lo em casos nos quais a solução pode ser bem mais simples. Só isto. A idéia é ter menos recursos que o Spring mesmo. É ter algo extremamente mais leve para resolver problemas que requerem soluções assim (aplicações Java ME por exemplo, ou mesmo aplicações desktop que estejam executando em ambientes mais restritos).

Poderia ter utilizado o Pico? Sim, poderia. Mas infelizmente o Pico hoje é mais do que um container de IoC. Ele lida inclusive com AOP. No caso, o miocc surgiu pra resolver um problema particular, ainda mais simples que aquele, e que não requeria AOP nem nada assim. Apenas uma solução ainda mais simples. Só.

O fato de a marcação lembrar o Spring deve-se simplesmente ao fato de eu ter considerado a marcação do mesmo a melhor opção. Não haveria porque reinventar a roda neste caso. A marcação utilizada pelo miocc, inclusive, pode ser modificada por qualquer um. Basta implementar outro parser, que leia de um arquivo xml, anotações ou qualquer outra fonte capaz de descrever as dependências.

Resumindo: o objetivo do projeto não é reescrever o Spring, mas sim buscar uma solução mais simples para casos mais simples. De nada adianta alguém virar e dizer “o Spring tem muito mais recursos, é algo maravilhoso” se você não os usa. Se não são usados, são gordura. Esta é a minha opinião. E foi esta que me motivou.

Com relação a reescrever o “Spring divagarinho”, bem… Não vai ocorrer, pois a idéia consiste em, assim que o projeto tiver 100% implementado (está uns 90%), difícilmente haverá necessidade de incluir novos recursos. Teremos simplesmente um container de IoC enxuto com o qual poderemos trabalhar caso precisemos de uma solução para problemas pequenos ou com limitações de ambiente.

Finalizando: é um container IoC que escrevi para resolver um caso particular. Ficou melhor que o esperado e resolvi disponibilizá-lo para quem tenha necessidades semelhantes.

[urubatan]

falei que parecia querer reescrever o spring, pois você comentou em criar modulos de integração com hibernate, …
e o spring é exatamente um container IoC com módulos de integração com um monte de coisas …
o IoC dele não tem AOP, é só IoC e você pode usar só isto, se quiser adiciona mais um jar e este sim tem suporte a AOP …

[edmilsomcarlos]

Na boa amigos, me registrei faz pouco tempo mas o que eu tenho a dizer é que ninguém neste fórum é encorajado a criar nada, a propor nada e nem a inventar nada. O mundo para os participantes daqui resume-se a coisas já criadas e que já atentem da forma com que são e ponto final. Tudo vocês acham que as pessoas fazem só para dizer “eu que fiz”, não é mesmo? Foi assim com o Mentha por diversas vezes e está sendo assim com o nosso amigo que criou o microscópio.

Tenho certeza de que muitos de vocês gritam: “Participação, participação!”, “Liberdade, Liberdade!”, “Gosto de java porque posso participar!”, mas a partir do momento em que uma pessoa tenta propor alguma coisa, por mais que já existam coisas similares por aí, a primeira coisa que todo mundo faz, por mais que não tenha tempo, é olhar com os piores olhos possíveis, amigos.

Se vai ser bom ou não, esse projeto do amigo, só o tempo dirá, os usuários dirão e o tempo livre dele para melhorar o projeto também. Por que não dar uma chance pro amiguinho?

[rafaelglauber]

edmilsomcarlos,

Não acredito que as pessoas achem que não pode-se criar nada, mas sim não deve-se “reinventar” a roda, por isso que sempre se discute o nível de inovação dessas novas implementações, só isso!!!

[Adolfo_Rodrigues]

Na boa amigos, me registrei faz pouco tempo mas o que eu tenho a dizer é que ninguém neste fórum é encorajado a criar nada, a propor nada e nem a inventar nada.

Eu discordo de você, Edmilson. O pessoal que postou até agora só fez questionar e debater a criação do autor do framework, de forma construtiva e educada. Não vi em nenhum momento (pelo menos neste post) qualquer iniciativa de desencorajamento.
Não estava claro para mim que o framework jamais fará algo além de DI. Se não fosse este debate, o propósito do miocc não estaria claro para mim.
Não entendo porque as pessoas, de forma geral, (e não estou falando de você) não gostam de debater ou se sentem “desconfortáveis”, “intimidadas”, “atacadas” com críticas. Acho que elas perdem a oportunidade de ganhar outros olhares para os assuntos.