A questao nao eh se open-source eh bom ou se eh ruim, mas sim se open-source eh bom ou ruim para o futuro do Java.
Isso deve ser avaliado pelos pontos positivos e negativos que geram e nao apenas pelo oba-oba filosofico de que tem que ser open-source de todo jeito. Confesso que eu fiquei meio receoso quando soube da noticia, mas com os pontos levantados por alguns colegas, tou comecando a achar que vai ser realmente um bom negocio.
Como se as grandes empresas nunca tivessem cometido erros estrategicos, principalmente a sun.
E-mail (POP, IMAP, SMTP e outros) e HTTP sao padroes. Nao tem ‘source’ pra ser aberto. Algumas implementacoes desses protocolos sao opensource, algumas nao.
seria ótimo isso para o java , para a comunidade que usa o java, a extensibilidade iria ajudar muito a evolução, mas precisa organizar uma forma melhor de versionar isso em pacotes da sun.
Falando nisso, :lol: alguém sabe se existe na JVM alguma implementação que além de detectar a existênci de DeadLocks consiga solucioná-los, ou dando a vez para outro processo, ou matando 1 ou n processos, ou dando um rollback nas escritas dos processos ?
O quero dizer com os protocolos é que sua implementação é aberta, todo protocolo é composto por regras, que definem como deve funcionar, sem estas regras dificilmente iria se implementar um software que utilize este ou aquele protocolo. Existem inúmeros protocolos fechados do qual nao há acesso.
Use um telegrafo como exemplo, vamos dividilo em camadas simplificadas (sem expadir): fisica: o meio pelo qual a informação é transportada.
lógica: As regras para que o usuário possa compreender o seu conteúdo.
Se estas regras não fossem de domínio publico, não seria possivel que duas pessoas se comunicassem pelo telegrafo. Esta regra nos permite gerar o software necessario para o seu funcionamento.
Existem protocolos cuja as regras não livres, ou seja alguns poucos conhecem. Se vc não tem acesso a estas regras, não poderá entender o seu funcionamento.
Imagine o http com suas regras de dominio de algumas poucas empresas. Se vc quisesse criar uma aplicação que utilizasse este protocolo teria de pagar para implementar este protocolo em sua aplicação. Isto ocorre com alguns protocolos, incluindo a propria ARPANET foi de dominio militar e liberado posteriormente para universidades o utilizarem.
A questão é: Ter medo o opensource não vai parar o seu crescimento. Todos podemos ganhar com a abertura do java, basta abrir a mente para novas possibilidades. Além de que já existem várias jvm(s) e ser ou não opensource não vai impedir que outras sujam.
Com o código fonte vc podera ajudar a Sun a melhorar o que já existe. Quando vc cria uma aplicacao desktop vc geralmente instala a jre da sun, pois jvm da M$ não atende as necessidades. Se escolher um servidor escolha um com o sistema da Sun. É simples, vc tem a liberdade de escolha. Use o que vc quiser.
Muita coisa boa é opensource, náo julge a qualidade desta forma. Expreimente o firefox. veja se ele não atende as suas necessidades. O java está para aumentar os seus horizontes e não diminuilos.
O grande ponto é a incerteza. Acho que ninguém é ingênuo (espero que não) de achar que opensource é coisa do demônio, muito menos a salvação da humanidade. A grande incerteza é como garantir compatibilidade entre as diversas implementações de JVMs que possam surgir por aí. Hoje em dia, com tudo sendo controlado pela Sun, já é um trabalho bem complicado manter compatibilidade entre Sun JVM, IBM JVM, Apple JVM, JRockit …, imagine se começarem a surgir zilhões de projetos malucos por aí. Além disso, no começo das brigas dos servidores J2EE, apesar de toda a especificação e bla bla bla sobre compatibilidade, as empresas sempre disponibilizavam extensões “bonitinhas” para tornar a vida do desenvolvedor mais fácil e torná-lo refém desta solução. Em modelos open-source tradicionais, nada pode impedir que isso aconteça.
Por outro lado, quantos forks famosos de Ruby/Python/Perl/PHP existem por aí? Hmmmm? Nenhum? Então, pode ser que Java siga a mesma tendência e, além disso, como o louds falou, ninguém em sã consciência vai usar um fork de J@v@ se este não tiver sido aprovado nos testes de compatibilidade.
Acho que o ponto então não é discutir se abrir ou não o Java vai ser bom. A questão é discutir como deve ser feita esta abertura para que a plataforma não seja afetada.
E o que eu quis dizer eh que existe uma diferenca entre protocolos abertos e fechados e implementacoes dos mesmos - que tambem podem ser abertas ou fechadas.
Pra exemplificar, HTTP eh um protocolo aberto (definido por uma serie de RFCs) que tem implementacoes abertas (Apache, Lighttpd, etc) e fechadas (IIS, WebLogic, WebSphere).
Seria interessante se existisse algum grupo mantenedor do Java de qualquer maneira, assim como o kernel do Linux tem. Assim, este ficaria responsável por validar as futuras implementações.
Forks são uma coisa boa, são a melhor forma de permitir experimentação, pesquisa e inovação.
Supondo que alguém resolvesse implementar continuations em Java, muito melhor fazer um fork de uma JVM production-ready que desenvolver em cima de uma plataforma de pesquisa como a SableVM ou JikesRVM. Vai ser muito mais facil depois comparar os resultados.
Tudo bem que hoje a JRL permite o uso da JVM da Sun para pesquisa, mas não seria possivel o público em geral testar o resultado disso.
Enfim a realidade é que em 2007 vai existir pelo menos uma JVM 1.4 ou 1.5 open source e dificilmente vai ser a da Sun. Em 2008/9 esse número deve aumentar para pelo menos 2.
Hoje a maioria das plataforma embutidas usam JVM derivadas de projetos open source, como Kaffe e Wonka.
Mesmo considerando que eu posso, por exemplo, Rodar código Java no meio de JRuby ou não pdoer chamar móduilos nativos? Uma aplicação desenvolvida em JRuby pode não funcionar em Ruby, visto que a paltaforma original não suporta este nível de integração com Java.
Mas, pensando bem, pode ser que neste caso esta integração funcione mais como uma biblioteca externa, mas uma biblioteca que não pode ser utilizada em algum cenário. Não sei.
Acoplamento a implementacao de GregorianCalendar, e a calendarios [/quote]
Uma coisa que persiste na minha cabeca.
Eu tive q implementar uma Wapper de uma lib que a IBM nao suporta mais nos novos compiladores, o sistema que a utilizava em todos os para calculos de datas do sistema em calendario Juliano.
la vai eu atras das explicacoes das diferencas dos testes unitarios e descubro que um FDP de um papa nao tinha nada pra fazer e resolveu tirar dias do calendario. :evil:
Alguem na face da terra ja trabalhou em um sistema com calendario Juliano ?
Qual seria a vantagem disso ?
Acoplamento a implementacao de GregorianCalendar, e a calendarios [/quote]
Uma coisa que persiste na minha cabeca.
Eu tive q implementar uma Wapper de uma lib que a IBM nao suporta mais nos novos compiladores, o sistema que a utilizava em todos os para calculos de datas do sistema em calendario Juliano.
la vai eu atras das explicacoes das diferencas dos testes unitarios e descubro que um FDP de um papa nao tinha nada pra fazer e resolveu tirar dias do calendario. :evil:
Alguem na face da terra ja trabalhou em um sistema com calendario Juliano ?
Qual seria a vantagem disso ?
[/quote]
Pelo que entendi, menos dias do ano = natal mais rápido adoro ganhar presentes :twisted:
Agora, falandos sério, não dá pra utilizar em aplicações comerciais. Sem chance.
[quote=cv]E qual o problema nisso? Se o Gava eh melhor pra determinadas tarefas, use Gava, nao Java. Compatibilidade nao eh a unica coisa em jogo ao decidir por usar uma tecnologia, e pode ser trocada por vantagens em outros fatores (performance, consumo de memoria, UIs decentes, que seja).
[/quote]
Isso me lembra o pessoal de C++. É multiplataforma, mas você precisa escolher bem as suas bibliotecas, etc, etc, etc. Fala qualquer coisa e a resposta “mas pode ser feito”.
Isso é péssimo para o Java. Ele caíria na vala comum das outras linguagens “multiplataforma, mas com alguns poréns”.
Bom, o JCP é cheio de política no meio e interesse de vendedores. Mas ignorando esse fato, existem VÁRIAS considerações a serem tomadas além da tecnológica.
No contexto de “negócios”, sim, são incompetentes. Se não fossem hoje estaríamos programando em outra coisa, Smalltalk, Python ou o que seja.
Você pode achar ruim o Java não ter isso ou aquilo, mas ele teve um bom apelo com quem importa (decision makers e empresas).
