Quando a ir contra as especificações, isso é resultado de propaganda de empresas criminosas. Essa preocupação é uma enorme BESTEIRA. Paremos um pouco e pensemos sobre um padrão do JCP: J2EE; quantos vendedores de container certificados não vendem seus produtos com toneladas de extensões? Ate ladrão arabe consegue contar. Agora pensemos sobre outro padrão CSS, qual a implementação mais compativel? Paga ela não é.
Vamos muito alem disso, entrem em www.classpath.org e investigem o cvs da maior implementação do class library do j2se, vcs vão encontrar bem menos extensões que na JRockit.
O RMS e o ESR sabem apenas aquilo que é do interesse deles, não o da comunidade. Leiam as listas de projetos como o classpath e o gcj (da GNU por sinal!), eles estão mais preocupados em ter acesso aos TCK (um doce para quem adivinhar o por que), que a SCSL seja menos restritiva e outras medidas que não envolvem tornar a jvm da Sun open source.
Parece que a maioria aqui ainda ve essa comunidade como um bando de adolecentes imaturos que fazem apenas por hobbie. Isso mudou, a varios anos por sinal.
Quando as extensões fragmentarem o java, isso não tem como acontecer, dado que voce não pode chamar nada que não passe no TCK de java.
Nem a Chapeuzinho Vermelho acredita em WORA. Talvez funcione com aplicações j2se escritas com cuidado.
Porém para J2EE e J2ME isso é uma enorme piada. Quem nunca teve problemas de deployment com J2EE é porque nunca saiu do fejão com arroz. Quem nunca teve odio com um vendedor de J2ME é pq nunca brincou com Siemens, certo Bani?
É, isso infelizmente é verdade…
Nos meus quase 2 anos programando Java 2/3 do tempo trabalhei com coisas proprietárias e com incompatibilidades absurdas… No começo era Portlets do Websphere (que agora já tem JSR mas ninguém usa) e hoje estou na diversificada vida das centenas de modelos de celulares.
Mas mesmo assim acho que se não existisse a padronização seria pior, até mesmo pelo processo de aprendizagem.
Ueh - mas voce queria que o Linus escrevesse a LSB antes de comecar o kernel? :lol:
Marcio Kuchma[/quote]
Nao to jogando a culpa no Linus, mas sim na licenca. E, depois, o kernel eh o de menos nesse caso. Veja, a Redhat criou o RPM… entao a conectiva foi la, pegou o source e comecou a modificar “para adequar as suas necessidaeds”… Resultado: rpm da conectiva da varias imcompatibiliades com rpm da Redhat… Nesse meio tempo, a suse vez a mesma coisa, e melou mais ainda… E ai chegou o Mandrake…
Por mais que vc consiga pegar um rpm de uma distro e instalar na outra, sempre acaba tendo q dar um --force, --no-deps… e ai acontece que uma versao usa um arquivo de db - ou pior, formato de db diferente - da outra versao da outra distro… e ta feita a meleca… Voce eh obrigado a soh usar rpm’s compativeis… Isso seria mais dificil de acontecer com um “controle” maior.
Soma isso ao filesystem, arquivos de configuracao e tudo mais… vira uma meleca soh… eh ridiculo vc ficar ouvido coisas do tipo “… a minha placa de som funciona perfeito na distro X, mas na Y nao vai nem a pau”…
Ha coisas zoneadas em partes do java, mas quem deseja ter todo o resto zoneado?
Voce tá equivocado rafael, o formato dos pacotes RPM é padronizado e nenhuma distro usa versões modificadas. O que acontece é que o formato é incompativel entre as major releases (rpm 2.x não funciona com rpm 3.x e vice-versa) então pode acontecer esse tipo de problema.
Quando a cada distro empacotar de uma forma diferente, eu não vejo maiores problemas com isso. Afinal, depois de ter escolhido sua distro voce não deveria usar pacotes para outras. Principalmente se falando das distribuições comerciais, que costumam usar versões patched da maioria dos programas para manter a estabilidade do sistema.
Levante a mão o usuario/desenvolvedor de windows que nunca teve o seu dll hell. Levante a mão quem nunca teve problemas com os pkg do Solaris. Quem nunca teve problema com um build do ports?
Filesystem? Voce se refere ao fato de ter muitas opções de filesystems? Sim, ter opções é ruim, acho que o governo deveria acabar com essa libertinagem. Cada filesystem tem sua utilidade e nicho, não existe o “the one filesystem” logo não mais lógico que existirem varios.
Arquivos de configuração. As distros mais user friendly te permitem configurar quase tudo via os paineis de controle delas. E quanto ao problema de compatibilidade de hardware, isso é 101% culpa dos fabricantes e não do software livre. Ou voce acha que escrever um driver para placa de video com ZERO de documentação, apenas via engenharia reversa é viavel?
[quote=“Rafael Steil”]
Ha coisas zoneadas em partes do java, mas quem deseja ter todo o resto zoneado?
Rafael[/quote]
Estranhamente aqui onde eu trabalho as maquinas mais zoneadas são justamente as que não rodam linux.
Entao eh pq vc nunca precisou de um pacote que soh tivesse para uma determinada distro, ou que a versao disponivel para tua distro estive mais velha.
Talvez entao voce nunca tenha tentado pegar um rpm no rpmfind.net, instalar no braco e depois, ao rodar o apt-rpm da Conectiva, descobrir que ele queria remover 800 megas em arquivos pq o rpm que vc instalou no braco modificou os arquivos de configuraco de rpm que soh existem no conectiva no braco.
OK, entao vc tambem nao poderia reclamar de, no caso do Java open source, ter comecado a usar uma vm e, mudar de ideia no meio do caminho, e descobrir que o teu programa nao toda na vm do oturo fabricante.
Linux eh muito baguncado e muito incompativel entre si… Se tivesse um minimo aceitavel de compatibilidade, nao teria milahres de esforcos pra tentar padronizar direito. E dificilmente vao conseguir pq cada um quer fazer do seu proprio jeito.
Mais uma vez: quem quer ter o Java ( “mais” ) complicado ainda?
Voce nao entendeu: o driver que funciona 100% numa distro nao funciona em outra. Ou seja… o driver ja foi escrito e tudo mais… muitas vezes pode ser ate oficial… Mas nao funciona em tudo… ou vc nunca viu “certificado apenas para redhat linux?”??
Vamos lá Rafael, não vou defender mais o RPM pq é um(a) xxxxxxx (introduza seu palavrão preferido) e da altos problemas mesmo.
Porém isso nunca vai se aplicar ao caso do java já que a Sun não vai liberar acesso a marca do Java. É aquilo eu estou falando a uns 10 posts, uma implmentação FS/OSS não vai poder se chamar de Java a não ser que ela passe no TCK, caso contrario a Sun deverá tomar as devidas providencias.
E a situação não vai piorar não, ou quem nunca teve problemas devido a bugs nas JVMs que passaram no TCK? A JRockit 7.x é famosa por dar segfault rodando tomcat…
Quando a usar extensões de uma dada JVM isso vai do desenvolvedor, mas como eu falei, fazendo isso não estará mais trabalhando com java.
Alem disso extensões são a melhor forma de se criar um padrão, não por um comite de vendedores. Com a abertura atual do JCP, as JVMs abertas se tornariam uma staging area para a evolução do j2se de forma muito melhor.
Ha alguns pontos obscuros em tudo isso, mas parece que nunca a “comunidade” vai estar satisfeita… sempre irao querer mais e mais…
Se, por qualquer que seja a razao, em algum futuro, Java se torar open source, pelamordedeus, que nao seja GPL… ( rms bufaria um mohte )
Ha alguns pontos obscuros em tudo isso, mas parece que nunca a “comunidade” vai estar satisfeita… sempre irao querer mais e mais…
Se, por qualquer que seja a razao, em algum futuro, Java se torar open source, pelamordedeus, que nao seja GPL… ( rms bufaria um mohte )
Rafael[/quote]
Para a Sun tornar a implementação dela GPL ou semelhante é bem mais negocio que usar uma licensa estilo BSD/Apache.
Outra coisa, pouco importa se a Sun fizer isso, dando acesso para o TCK, assim uma JVM OSS vai poder dizer que é java, e tornando a SCSL menos viral assim resolve o estrago que ela está causando.
Nao conheco direito o RPM (Debian rules :D), entao nao vou comentar isso diretamente. O Louds ja comentou tambem a maioria dos pontos que gostaria de levantar. Vou apenas “recomentar” um item:
O RPM tem problemas de compatibilidade de um fornecedor para outro (vamos assumir isso como verdade para efeitos de discussao). Como voce mesmo mencionou, o kernel eh o de menos.
Eu penso que o mesmo vale para o Java e outras coisas. Sera que se eu gero um EAR usando o WSAD eu consigo rodar em qualquer servidor J2EE? Ou no caso dos banco de dados - ha quantos anos nao existe o padrao de SQL? E fazer uma query nao-trivial rodar em diferentes RDMS eh um saco. E isso antes que tivessemos MySQL, PostgreSQL e cia por ai…
Nao eh uma suposta abertura de codigo que vai zonear tudo de vez. Talvez sim, talvez nao - acho bem mais importante a questao da aderencia aos padroes e a utilizacao destes padroes por parte dos desenvolvedores. Se todos fizessem o CSS seguindo o padrao especificado e se os fabricantes aderissem a esses padroes (i.e.: IE :D)), o mundo seria bem melhor e nao veriamos injurias injustas contra Mozilla e outros que “nao rodam CSS direito”.
Obs.: no momento nao sou contra nem a favor da suposta abertura. Tambem nao quero convencer ninguem.
É isso aí, kuchma. vou pegar carona na frase do louds:
Louds, andei lendo todos os links que vc passou, classpath.org e tudo mais. Confesso que eu mudei meu ponto de vista.
Tudo tem a ver com a outra discussão sobre o Groovy e o (alerta! adjetivo descaradamente desnecessário) maravilhoso artigo Enablers and Problems (veja também os links) que caiu na minha mão.
Os padrões não podem nunca ser impostos. Achar que a Sun tem que ter total controle sobre o Java ou que as JVMs têm todas que obedecer às regras de um grupinho é como achar que todo desktop têm que ter janelas e um botão “iniciar”.
Se as extensões que um pessoal implementar na JVM forem úteis, mais cedo ou mais tarde a comunidade inteira adota. Assim como se Groovy for mesmo útil, tanto faz se tem JSR ou não, o pessoal adota. Mas como tudo o que é útil, tem que passar no teste de uso. E só vai ser usado se estiver disponível.
Então virei a casaca e sou agora a favor da abertura. Pra quem desenvolve em Java, não vai mudar nada da noite pro dia. Vai mudar a cada nova major release, desde que pessoas que têm vontade de ajudar a evoluir tenham também poder para tal.
O preço que a gente paga é o mesmo preço de quem faz download do rpmfind.net (até parece que apt-get resolve): vai ter coisas que só funcionam na JVM X e não na sua. Eu tô achando o preço pequeno.
)