Quanto que vai custar o Java licença Enterprise Edition? OpenSolaris? o que é bom é cobrado não tem jeito, acabou a sugação.
Concordo com o chun, o OpenSolaris dificilmente tem futuro, pouca gente usa. Precisaria de muito dinheiro investido pra que ele possa dar algum retorno. Se a Oracle ainda não deu sinal pra eles, é porque ainda está tentando procurar alguma saída, mas se não encontrar, é melhor largar de mão.
E concordo também quanto à ideia de que visar lucro é do demônio, e que se a empresa se interessa por lucro significa que ela não é boa. Isso não é do Software livre, mas das visões de esquerdas que apodrecem o país. Aliás, visão jurássica de esquerda, porque até os políticos de esquerda mais sérios de qualquer país, deixaram de pensar assim há anos.
O que é bom, a Oracle está mantendo: o Glassfish foi incorporado ao portfólio na mesma licença que a Sun usava, o Virtual Box também continuou com a versão livre e a comercial evoluindo…até o OpenOffice teve notícias boas, há anos que o pessoal pressionava a Sun pra utilizar o gstreamer no lugar do JMF e ela nunca aceitou, agora a Oracle deu o aval.
Ow Alex,
Quanto que vai custar o Java? Acompanho suas defesas em vários sites open source em relação a Oracle, creio que deve ter informações mais direta da Oracle sobre os produtos e o que eles planejam, esse OpenSolaris já estava morto assim como a Sun, só quero saber logo o custo da Licença do Java para me preparar melhor, se vai ser por Download ou por DVD.
Value obrigado.
Existe uma diferença de Ideais entre Lideres do OpenSource e Lideres do Capital.
A Oracle é empresa de Capital, se parar e pensar um pouco vão ver o que a oracle esta fazendo, Ela está fazendo oque toda empresa grande capitalista faz:
-Comprou outra empresa pensando em expandir no mercado
-Comprou pensando em lançar novos produtos
-Comprou pensando em ampliar a gama de clientes
-Comprou pensando em centralizar/dominar tecnologias
-Comprou para se tornar bem maior e talvez inatingivel pela SAP(principal concorrente)
Mensionei a SAP por que eles não estão parados, compraram a Business Objects e a Sybase por estes dias.
O que eles estão fazendo agora é cortar gastos, eliminar projetos que não geram receita, melhorando os produtos Oracle já existentes e por ai vai. Isso é o que acontece quando uma empresa que visa capital compra uma empresa que visa conheçimento e colaboração, Colocam o Conhecimento para Gerar Receita.
Já me disseram que o Oracle Forms agora é java, e por ai vai…
Sem querer apontar certos ou errados, nem profetizar a revolução das maquinas…rsrs
O que acontence é isso, e penso que não é nada bom para o OpenSource.
[quote=knowledgebr]Ow Alex,
Quanto que vai custar o Java? Acompanho suas defesas em vários sites open source em relação a Oracle, creio que deve ter informações mais direta da Oracle sobre os produtos e o que eles planejam, esse OpenSolaris já estava morto assim como a Sun, só quero saber logo o custo da Licença do Java para me preparar melhor, se vai ser por Download ou por DVD.
Value obrigado.[/quote]
O java não vai custar nada, porque essas empresas precisam de nós desenvolvedores.
Sobre o OpenSolaris, realmente é uma pena porque é tecnologia 80% java. Até alguns modelos de drivers são escritos com java nele. Pra mim o opensolaris é uma fonte rica de estudo e conhecimento .Ele é mais uma questão cultural mesmo.
Pode não dar lucro, mas é uma tecnologia excelente.
Drivers escritos em Java ?
Voce bebeu ?
Java é UMA BOMBA para interagir com hardware… alias… ele NEM FAZ ISSO… precisa de uma lib nativa…
voce poderia me mostrar o codigo fonte de algum DRIVER feito em Java no OpenSolaris ?
[quote=chun]Drivers escritos em Java ?
Voce bebeu ?
Java é UMA BOMBA para interagir com hardware… alias… ele NEM FAZ ISSO… precisa de uma lib nativa…
voce poderia me mostrar o codigo fonte de algum DRIVER feito em Java no OpenSolaris ?
[/quote]
Parece que você está por fora da realidade chun. Qualquer linguagem pode ser usada para desenvolver drivers, só basta que estes sejam gravados
como módulos de um kernel.
Não é bomba não. É somente uma linguagem de programação e um sistema que te dê infraestrutura para isso.
Basta que um kernel seja adaptado, o que o opensolaris faz muito bem.
Esse projeto já existe há muitos anos.
[quote=juliocbq][quote=chun]Drivers escritos em Java ?
Voce bebeu ?
Java é UMA BOMBA para interagir com hardware… alias… ele NEM FAZ ISSO… precisa de uma lib nativa…
voce poderia me mostrar o codigo fonte de algum DRIVER feito em Java no OpenSolaris ?
[/quote]
Não é bomba não. É somente uma linguagem de programação e um sistema que te dê infraestrutura para isso.
Basta que um kernel seja adaptado, o que o opensolaris faz muito bem.
Esse projeto já existe há muitos anos.
http://developers.sun.com/solaris/learning/driver/index.jsp[/quote]
CREDO … li o PDF , eles deixao bem claro que a parte de interação com o hardware deve ser feita com um driver feito em C
ou seja… apenas uma “MASCARA” para o driver real…
simplesmente UM XUNXO
Lamentável…
[quote=chun][quote=juliocbq][quote=chun]Drivers escritos em Java ?
Voce bebeu ?
Java é UMA BOMBA para interagir com hardware… alias… ele NEM FAZ ISSO… precisa de uma lib nativa…
voce poderia me mostrar o codigo fonte de algum DRIVER feito em Java no OpenSolaris ?
[/quote]
Não é bomba não. É somente uma linguagem de programação e um sistema que te dê infraestrutura para isso.
Basta que um kernel seja adaptado, o que o opensolaris faz muito bem.
Esse projeto já existe há muitos anos.
http://developers.sun.com/solaris/learning/driver/index.jsp[/quote]
CREDO … li o PDF , eles deixao bem claro que a parte de interação com o hardware deve ser feita com um driver feito em C
ou seja… apenas uma “MASCARA” para o driver real…
simplesmente UM XUNXO
Lamentável…[/quote]
[quote]2.Considerations when embedding a JVM in the
kernel
The main design issues we encountered in porting Squawk into the Solaris
kernel were:
- Different execution model The Java Virtual Machine was intended to
run a single user application, potentially composed of many threads. The
lifetime of a JVM instance is determined by the execution behavior of
the application. The application is typically initiated by a user and
begins by calling the main method. Normal termination occurs by either
the main method returning, or the application calling System.exit.
Abnormal termination can be due to an internal cause (e.g., an uncaught
exception within the application) or an external cause (e.g., the JVM
process being terminated in response to a signal).
Little of this is appropriate within the kernel. We chose to restructure the
execution model to make it appropriate for device drivers, described in
Section 4. - Access to C state and functions The Java Native Interface (JNI)
[Liang99] is usually used to access state and functions external to a Java
application. However, Squawk does not implement the JNI; further, it is
a heavyweight mechanism for access to kernel services, providing more
generality than is required. We chose to devise and implement a simpler
mechanism, described in Section 5. - Division into kernel modules Extensions to the kernel are structured as
loadable kernel modules. We need to choose an appropriate partition of
our system into modules (Section 6). - Lack of library support The kernel does not have the C libraries
available to applications, including the standard C library (libc).
Therefore, it is not possible to simply take an existing user-level JVM
and run it, as is, within the kernel. If some feature from the C libraries is
needed, it may have to be re-implemented in the kernel. We minimized
this effort by starting with a JVM that has few library requirements.[/quote]
Não viaja chun, o que eles fizeram foi embutir uma jvm no kernel, e o exemplo é portar um driver escrito em c para java.
Ao meu ver uma idéia revolucionária, quue a microsoft tenta implementar no singularity(Acho que você nem sabe o que é isso).
juliocbq , mostra os 80% do codigo do OpenSolaris em Java.
A especificação descrita utiliza uma interface da JVM que é feita utilizando uma ponte em C , tanto que tem um aviso quanto a performance.
pra mim isso é XUNXO.
E eles nem podem fazer diferente , senão vao quebrar a especificação de JAva , então não pode ser chamado mais de JAva. Assim como o Google fez com o Dalvik.
[quote=chun]juliocbq , mostra os 80% do codigo do OpenSolaris em Java.
A especificação descrita utiliza uma interface da JVM que é feita utilizando uma ponte em C , tanto que tem um aviso quanto a performance.
pra mim isso é XUNXO.
E eles nem podem fazer diferente , senão vao quebrar a especificação de JAva , então não pode ser chamado mais de JAva. Assim como o Google fez com o Dalvik.[/quote]
Huahua, chun, você acaba sendo engraçado… Onde tem interface de jmv?
Essa ponte que você está falando já é a própria máquina virtual que está embutida no kernel, ou seja, o kernel do opensolaris entende bytecode, e pode conversar com o hardware utilizando o próprio bytecode. Onde é que está o xunxo nisso?
Outra besteira é comparar a squalk com a dalvik. Uma coisa não tem nada haver com outra. A squalk é uma vm praticamente escrita em próprio java, e é ela que é usada hoje para se embarcar sistemas, e é também a mesma que é usada no kernel do opensolaris. A dalvik tem um bytecode próprio e um compilador java próprio( é outra idéia, e mesmo assim não deixa de ser java)
é uma grande tecnologia, mas a oracle poderá fazer o mesmo que a hp fez com várias tecnologias dela.
Agora sobre o desempenho é verdade. Você pode ter uma perda mesmo devido a razões de magnitude.
[quote=juliocbq][quote=chun]juliocbq , mostra os 80% do codigo do OpenSolaris em Java.
A especificação descrita utiliza uma interface da JVM que é feita utilizando uma ponte em C , tanto que tem um aviso quanto a performance.
pra mim isso é XUNXO.
E eles nem podem fazer diferente , senão vao quebrar a especificação de JAva , então não pode ser chamado mais de JAva. Assim como o Google fez com o Dalvik.[/quote]
Huahua, chun, você acaba sendo engraçado… Onde tem interface de jmv?
Essa ponte que você está falando já é a própria máquina virtual que está embutida no kernel, ou seja, o kernel do opensolaris entende bytecode, e pode conversar com o hardware utilizando o próprio bytecode. Onde é que está o xunxo nisso?
Outra besteira é comparar a squalk com a dalvik. Uma coisa não tem nada haver com outra. A squalk é uma vm praticamente escrita em próprio java, e é ela que é usada hoje para se embarcar sistemas, e é também a mesma que é usada no kernel do opensolaris. A dalvik tem um bytecode próprio e um compilador java próprio( é outra idéia, e mesmo assim não deixa de ser java)
é uma grande tecnologia, mas a oracle poderá fazer o mesmo que a hp fez com várias tecnologias dela.
Agora sobre o desempenho é verdade. Você pode ter uma perda mesmo devido a razões de magnitude.
[/quote]
Acho que voce esta confundindo…e nao esta entendendo… que INDEPENDENTE de JVM , a LINGUAGEM JAVA , para continuar sendo considerada JAVA , não pode acessar codigo NAO GERENCIADO de DENTRO da JVM…
ou seja… nao importa , se vc esta escrevendo um driver em JAVA , ele vai acessar uma classe que faz BIND em uma DLL nativa para acessar dispositivos NATIVOS…
Se voce fizer o acesso por DENTRO da linguagem java… acesso DIRETO , sem WRAP , isso deixa de ser Java , pois quebra a especificação da JVM e da Linguagem (sim , acredite , voce nao pode sair criando besteiras e depois ainda chamar de Java)
Dalvik não é Java por este motivo.
Para um driver , performance é algo INDISCUTIVELMENTE ESSENCIAL.
Seria uma tremenda besteira você escrever um driver que controla por exemplo… acesso a VIDEO , com uma plataforma que não foi feita para trabalhar com esse tipo de abordagem…
Quem disse que 80% do codigo do Opensolaris eh feito em java foi VOCE…
Quando digo INTERFACE com uma dll nativa , quero dizer um ACESSO e não uma interface nos moldes de java.
A dalvik tem um bytecode proprio , e uma LINGUAGEM PROPRIA , que muitos chamao de JAVA e não é
Inclusive muito dela respeita a TJVMS.
Bacana o nível técnico da conversa, mas quem está certo nesta conversa? Um fala que é asneira e o outro fala que é papo furado, fiquei na dúvida.
[quote=chun][quote=juliocbq][quote=chun]juliocbq , mostra os 80% do codigo do OpenSolaris em Java.
A especificação descrita utiliza uma interface da JVM que é feita utilizando uma ponte em C , tanto que tem um aviso quanto a performance.
pra mim isso é XUNXO.
E eles nem podem fazer diferente , senão vao quebrar a especificação de JAva , então não pode ser chamado mais de JAva. Assim como o Google fez com o Dalvik.[/quote]
Huahua, chun, você acaba sendo engraçado… Onde tem interface de jmv?
Essa ponte que você está falando já é a própria máquina virtual que está embutida no kernel, ou seja, o kernel do opensolaris entende bytecode, e pode conversar com o hardware utilizando o próprio bytecode. Onde é que está o xunxo nisso?
Outra besteira é comparar a squalk com a dalvik. Uma coisa não tem nada haver com outra. A squalk é uma vm praticamente escrita em próprio java, e é ela que é usada hoje para se embarcar sistemas, e é também a mesma que é usada no kernel do opensolaris. A dalvik tem um bytecode próprio e um compilador java próprio( é outra idéia, e mesmo assim não deixa de ser java)
é uma grande tecnologia, mas a oracle poderá fazer o mesmo que a hp fez com várias tecnologias dela.
Agora sobre o desempenho é verdade. Você pode ter uma perda mesmo devido a razões de magnitude.
[/quote]
Acho que voce esta confundindo…e nao esta entendendo… que INDEPENDENTE de JVM , a LINGUAGEM JAVA , para continuar sendo considerada JAVA , não pode acessar codigo NAO GERENCIADO de DENTRO da JVM…
ou seja… nao importa , se vc esta escrevendo um driver em JAVA , ele vai acessar uma classe que faz BIND em uma DLL nativa para acessar dispositivos NATIVOS…
Se voce fizer o acesso por DENTRO da linguagem java… acesso DIRETO , sem WRAP , isso deixa de ser Java , pois quebra a especificação da JVM e da Linguagem (sim , acredite , voce nao pode sair criando besteiras e depois ainda chamar de Java)
Dalvik não é Java por este motivo.
Para um driver , performance é algo INDISCUTIVELMENTE ESSENCIAL.
Seria uma tremenda besteira você escrever um driver que controla por exemplo… acesso a VIDEO , com uma plataforma que não foi feita para trabalhar com esse tipo de abordagem…
Quem disse que 80% do codigo do Opensolaris eh feito em java foi VOCE…
Quando digo INTERFACE com uma dll nativa , quero dizer um ACESSO e não uma interface nos moldes de java.
A dalvik tem um bytecode proprio , e uma LINGUAGEM PROPRIA , que muitos chamao de JAVA e não é
Inclusive muito dela respeita a TJVMS.
[/quote]
Java que estamos falando é de uma plataforma, não tem nada haver com linguagem.
Não existe acessar código não gerenciado de uma jvm. O que simplesmente a squalk faz é parecido com o que o hotspot faz na sua máquina, com a diferença do programa rodar com todas as permissões do sistema, ou seja, em kernel mode.
Dentro da squalk vai rodar somente código gerenciado, e é claro que a squalk tem um mapeamento(bind) no kernel(Assim como o android faz com a dalvik no kernel dele).
A dalvik, ou qualquer outra vm pode ter qualquer programa desenvolvido em qualquer linguagem rodando nela, pois basta um compilador(que gera instruções para dalvik) para a mesma. Da mesma maneira você escreve em linguagem java e compila e roda um programa na clr(a vm dotnet). Agora, todo mapeamento é feito usando-se jni(até mesmo o jna), e se não me engano isso faz parte da especificação da java(linguagem).
É claro que a dalvik roda seu próprio bytecode, mas existe um compilador(ou conversor) java(linguagem) para ela.
Para um driver, desempenho é essencial sim, até porque eu trabalho com isso e sei muito bem. Se eu levar em conta que a squalk já compilou o bytecode para nativo, posso dizer que esse driver pode ser tão rápido quanto o outro em c.
Sim, fui eu mesmo que disse, já que o desktop seria escrito em java também. Mas a oracle matou o projeto.
Então… o java que estou falando é da LINGUAGEM JAVA… e que eu saiba , não existe NENHUMA outra LINGUAGEM para a JVM que não seja JAVA. Todas que existem , compilao para bytecode java OU rodam em cima da SPEC de Scripts… seja linguagem JAVA nao suporta , entao a linguagem compilada para ela nao vai suportar.
"Não existe acessar código não gerenciado de uma jvm."
Existe sim… se chama JNI.
Se squalk apenas realizar um trabalho de JIT , não é o suficiente para escrever device drivers.
Na minha opiniao , escrever um driver em JAVA só para dizer que usou a linguagem java , não tem utilidade nenhuma…
A magica toda vai estar na DLL feita em C/C++.
[quote=chun]Então… o java que estou falando é da LINGUAGEM JAVA… e que eu saiba , não existe NENHUMA outra LINGUAGEM para a JVM que não seja JAVA. Todas que existem , compilao para bytecode java OU rodam em cima da SPEC de Scripts… seja linguagem JAVA nao suporta , entao a linguagem compilada para ela nao vai suportar.
"Não existe acessar código não gerenciado de uma jvm."
Existe sim… se chama JNI.
Se squalk apenas realizar um trabalho de JIT , não é o suficiente para escrever device drivers.
Na minha opiniao , escrever um driver em JAVA só para dizer que usou a linguagem java , não tem utilidade nenhuma…
A magica toda vai estar na DLL feita em C/C++. [/quote]
Claro que existem, e cito Ruby e Pyton que rodam na jvm. O bytecode é o mesmo, mas as linguagens são diferentes e exigem analizadores lexicos diferentes, compiladores diferentes.
O objetivo do jni é conversar com outros assemblies, não acessar código não gerenciado(apesar de poder ser usada para isso).
[quote]Java que estamos falando é de uma plataforma, não tem nada haver com linguagem.
Não existe acessar código não gerenciado de uma jvm. O que simplesmente a squalk faz é parecido com o que o hotspot faz na sua máquina, com a diferença do programa rodar com todas as permissões do sistema, ou seja, em kernel mode.
Dentro da squalk vai rodar somente código gerenciado, e é claro que a squalk tem um mapeamento(bind) no kernel(Assim como o android faz com a dalvik no kernel dele). [/quote]
Não distorça as minhas palavras.
A mágica está num modelo mais robusto de kernel, e não em uma linguagem de programação.
não acho justo dizer que uma tecnologia é um lixo sem saber como ela funciona. O open solaris pode não dar lucro, mas está longe de ser um lixo.
juliocbq ,
hehehe… voce por acaso VIU como funciona o compilador do Ruby para bytecode da JVM ?
hehehe…
ele TRADUZ praticamente para JAVA utilizando classes especialmente criadas para isto… e depois compila ESTAS CLASSES para bytecode…
Sem a instrução invoke_dynamic do JDK 7 é impossível realizar esta transformacao de forma nativa…
Resumindo… esta na JVM ? é Java, nem que por cima você tenha uma roupa dizendo que a marca é ruby.
Voce realmente acredita que a distancia entre Java e Ruby está apenas no compilador e na analise léxica ? (quando dentro da jvm é claro)
[quote=chun]juliocbq ,
hehehe… voce por acaso VIU como funciona o compilador do Ruby para bytecode da JVM ?
hehehe…
ele TRADUZ praticamente para JAVA utilizando classes especialmente criadas para isto… e depois compila ESTAS CLASSES para bytecode…
Sem a instrução invoke_dynamic do JDK 7 é impossível realizar esta transformacao de forma nativa…
Resumindo… esta na JVM ? é Java, nem que por cima você tenha uma roupa dizendo que a marca é ruby.
[/quote]
Qual é o problema de traduzir para java e depois ser compilado para bytecode?
O importante é que pyton ou ruby se transformem em bytecode. O invoke_dynamic só vai melhorar o processo de solução de um problema.
Agora só relembrando, nossa conversa não tem nada haver com isso. Eu só estou lhe dizendo que open solaris não é lixo e é uma ótima tecnologia, apesar de a oracle possivelmente descontinuá-lo.