Curiosamente, este foi o FUD q a Sun usou para justificar para o
mundo pq não abria seu código relativo à plataforma Java.
"Forks" só prosperam se o q for oferecido no novo "branch" for
superior ou mais interessante aos desenvolvedores do q o q é
oferecido pela árvore principal. A especificação Java é uma só, o q
pode sofrer "fork" é apenas a implementação de diversas
especificações da plataforma. Se esse código for melhor, contanto q
siga a especificação, o q - em tese- garantiria a execução sem
problemas de tudo o q já temos, não há razão para um "fork" trazer
"caos e desordem" à plataforma. Inclusive, q eu me lembre, na época
do JDK 1.x, a JVM mais rápida e fiel à especificação era da Watcom (q
fim levou mesmo?). Se algum equivalente produzir um código melhor,
vamos lá!
Vale lembrar q nada impede um fork do kernel linux, do projeto Mono,
dos interpretadores python, ruby, php, e por aí vai, e nunca vi
ninguém ficar "temeroso" com isso.
Agora, tendo em vista o ritmo dos projetos livres de Java em
andamento, acho muito difícil alguém sair com um fork interessante . . .
[ ]s,
olival.junior
Em 14/11/2006, às 05:54, Jonathas Pereira escreveu:
Olá,
Precisamos tomar o cuidado para não criarmos várias
versões do Java e evitar a fragmentação dessa platafoma.
A comunidade pode se organizar para manter tudo em
um só lugar, semelhante ao projeto GCC. http://gcc.gnu.org
Existem milhares e milhares de projetos escritos em Java.
A fragmentação dela agora seria um desastre.
Jonathas Pereira
http://www.logness.com.br
_______________________________________________
PSL-Brasil mailing list
PSL-Brasil@listas.softwarelivre.org
http://listas.softwarelivre.org/mailman/listinfo/psl-brasil
Regras da lista:
http://twiki.softwarelivre.org/bin/view/PSLBrasil/
RegrasDaListaPSLBrasil
_______________________________________________
PSL-Brasil mailing list
PSL-Brasil@listas.softwarelivre.org
http://listas.softwarelivre.org/mailman/listinfo/psl-brasil
Regras da lista:
http://twiki.softwarelivre.org/bin/view/PSLBrasil/RegrasDaListaPSLBrasil
