O OpenSolaris Governing Board, entidade administrativa da comunidade OpenSolaris, está ameaçando abandonar a gestão da comunidade e devolvê-la à Oracle, o que segundo especialistas, decretaria a morte desta versão do sistema operacional Solaris.
Segundo o BR-Linux, as tensões entre a Oracle e a comunidade OpenSolaris têm sido visíveis desde fevereiro, como resultado de a empresa ignorar todas as tentativas de contato da entidade.
De acordo com o ?ultimato?, ou a Oracle indica uma pessoa de contato apta a tomar decisões referentes ao OpenSolaris até 16 de agosto, ou a diretoria comunitária vai decretar sua própria dissolução, passando o controle do projeto para a própria Oracle.
Ainda segundo a publicação, a gota d?água parece ter sido a reunião da comunidade marcada para essa semana, agendada com um vice-presidente da empresa, que deixou de comparecer e não teria apresentado qualquer explicação.
Triste… Vamos torcer para a Oracle levar a sério o comunidade do OpenSolaris…
[]´s
R
rdgms
Realmente… vamos torcer!!!
saudades da Sun…
bate até uma tristeza entrar no site da sun e ver o logo da oracle…
G
garcia-jj
Não muito a ver com o tópico… mas o Glassfish 3.0.1 vá vem com o logo da Snorcle, e agora chama-se Oracle GlassFish Server e GlassFish Server Open Source Edition. O server adapter para rodar o Glassfish embedded está agora dentro do Oracle Enterprise Pack for Eclipse, que aliás roda muito bem com o Eclipse Helios.
As documentações da API já estão com o logo da Snorcle, bem como os PDFs do JEE tutorial.
M
Marky.Vasconcelos
Triste noticia.
A Oracle poderia fazer qualquer coisa pra mostrar interesse, nem que fosse colocar alguem para falar com o povo do OpenSolaris.
E como alguém que nao lembro quem gosta de falar:
“Corram para as colinas”
C
chun
Eu acho que a Oracle esta certa , tem que acabar mesmo.
NINGUEM usa OpenSolaris… Solaris é MUITO MAIS uma questão CULTURAL do que realmente o funcionamento em plataformas fora da SPARK…
é BESTEIRA e PERDA DE TEMPO incentivar algo que dependa MUITO MAIS DA CULTURA do que da CAPACIDADE de operacao…
É mais facil vender o SOLARIS a preços mais baixos , e deixar quem preferir , que compre.
E
eduveks
chun:
Eu acho que a Oracle esta certa , tem que acabar mesmo.
NINGUEM usa OpenSolaris… Solaris é MUITO MAIS uma questão CULTURAL do que realmente o funcionamento em plataformas fora da SPARK…
é BESTEIRA e PERDA DE TEMPO incentivar algo que dependa MUITO MAIS DA CULTURA do que da CAPACIDADE de operacao…
É mais facil vender o SOLARIS a preços mais baixos , e deixar quem preferir , que compre.
Concordo e discordo, mas no fundo acabo por concordar.
É que o OpenSolaris trás para o mundo x86 um sistema muito robusto, principalmente o ZFS que é brutal, mas já há n muito tempo fizeram o ZFS para Linux. Robusto no sentido de ter recursos exclusivos do Solaris aberto.
De qualquer forma, eu já passei por isto, de ter uma placa wireless que não conseguia arranjar o driver para Linux, mas consegui o driver do fabricante para OpenSolaris! O que me expantou na altura, e já usei bastante o OpenSolaris, e gostei, mas num servidor sério em x86 não largo mão do CentOS.
No OpenSolaris é raro vir atualizações e alguns pequenos bugs permanecem por muito tempo, como um bug do screensaver que era ridiculo que mostrava umas mensagens de erro do GTK, não dúvido que este erro ainda continue…
Também o OpenSolaris é útil para ter a capacidade de fazer alguns testes de configuração e serviços, mas não o considero robusto o suficiente para algo mais sério e dúvido que um dia chegue a ser, muito menos ao nível do CentOS, acho que ter uma solução para servidores opensource melhor que o CentOS é muito difícil.
Para servidor não dá… para desktop muitooo menos, tudo é uma grande luta e eu fui louco o suficiente para tentar usa-lo como desktop por um tempo!
Tenho pena que isto aconteça, pois é menos um sistema, e é menos uma flexibilidade, mas tb acho q n vai fazer muita falta mesmo…
K
Kenobi
A Oracle é bastante focada, se algo não traz resultado (mídia, imagem, demanda) ela abandona e OpenSolaris pra mim é um projeto morto. Tá certa ela, ficar gastando vela com defunto morto e enterrado ? :twisted:
C
chun
"É que o OpenSolaris trás para o mundo x86 um sistema muito robusto, principalmente o ZFS que é brutal, mas já há n muito tempo fizeram o ZFS para Linux. Robusto no sentido de ter recursos exclusivos do Solaris aberto. "
Me desculpe , para mim isso é balela… quer tornar o mundo robusto… libere o codigo do ZFS sob GPL… e pronto… todo mundo vai usar no linux.
M
MatHeuZ
Não precisa ter medo!!!
O Google vem ai!!!
Com comunidades abertas e sem visão de lucro selvagem como a Oracle.
O desenvolvimento Android é Java
O openSolaris é baseado em Unix --> BSD
O Google tem
Android é baseado no linux!!!
e os aplicativos são todos feitos em Java!!!
O Google também tem um sistema operacional, ChromeOs.
O ChromeOs é baseado em Linux
Se a Oracle continuar assim vai perder a gente para o Google.
Não se engane: Google, Oracle, IBM e Microsoft querem a mesma coisa: lucro!
Se Google escolheu Linux e java é porque é financeiramente mais vantajoso para eles, não por causa de uma ideologia como vc deve imaginar.
J
juliocbq
huahua…é verdade. Mas a ideologia da google é melhor que a da oracle, e diferente da segunda, eles não sabem somente ganhar dinheiro, mas sabem também criar tecnologia. Nisso a sun era muito melhor que a oracle.
M
MatHeuZ
renamed:
MatHeuZ:
Não precisa ter medo!!!
O Google vem ai!!!
Com comunidades abertas e sem visão de lucro selvagem como a Oracle.
O desenvolvimento Android é Java
O openSolaris é baseado em Unix --> BSD
O Google tem
Android é baseado no linux!!!
e os aplicativos são todos feitos em Java!!!
O Google também tem um sistema operacional, ChromeOs.
O ChromeOs é baseado em Linux
Se a Oracle continuar assim vai perder a gente para o Google.
Não se engane: Google, Oracle, IBM e Microsoft querem a mesma coisa: lucro!
Se Google escolheu Linux e java é porque é financeiramente mais vantajoso para eles, não por causa de uma ideologia como vc deve imaginar.
Posso estar errado mas, eu li o livro “A história do negócio de midia…” da Google, e percebi que os criadores da Google tem uma mentalidade diferente em questão de como ganhar dinheiro e podem ter vantagem sobre os outros (pelo que eu vi a Google da mais valor para inovação e criação do que para o dinheiro) o foco é diferente, o foco não é no dinheiro foco é no cliente.
F
fabiomazzo
Não só o Google pensa em lucro (o que não é ruim, é normal) como praticamente monopoliza alguns mercados (o que é pessímo). Não entendo entendo essa mania do pessoal endeusar o Google e endomoniar a Microsoft, Oracle, etc.
Isso simplesmente não é coerente, conheço muita gente envolvida com o universo Open Source que endeusam o Google. Nada contra, mas o Google não fazem nada de diferente das outras empresas, a maior parte dos produtos deles são fechados.
Se algúem é contra a forma como a Oracle e outras empresas trabalham deveriam apoiar os projetos abertos e comunitários e não torcer pelo Google.
C
chun
hehe… se vc leu um livro do Google , é claro que ele vai se fazer de santo
é a mesma coisa que ler um livro do Bruno (goleiro do flamengo) onde ele diz que é inocente… e vc acreditar… afinal… está escrito
Papel aceita qualquer coisa.
L
Luiz_Aguiar
Sinceramene, OpenSolaris não fará falta pra absolutamente ninguém… já vai tarde!
M
MatHeuZ
fabiomazzo:
Não só o Google pensa em lucro (o que não é ruim, é normal) como praticamente monopoliza alguns mercados (o que é pessímo). Não entendo entendo essa mania do pessoal endeusar o Google e endomoniar a Microsoft, Oracle, etc.
Isso simplesmente não é coerente, conheço muita gente envolvida com o universo Open Source que endeusam o Google. Nada contra, mas o Google não fazem nada de diferente das outras empresas, a maior parte dos produtos deles são fechados.
Se algúem é contra a forma como a Oracle e outras empresas trabalham deveriam apoiar os projetos abertos e comunitários e não torcer pelo Google.
Desculpe-me mas não estou endeusando a Google estou apenas procurando outra solução aberta e parecida com o OpenSolaris.
que por sinal é até melhor pelo fato de ser baseado no linux e não no Unix.
Parecida também pelo fato deles usarem muito o Java também (pelo menos até o momento, qualquer hora podem mudar para a linguagem Go que é uma mescla de Java, Python, C)
Quanto ao lucro, sim é muito bom, todos querem dinheiro no bolso mas estamos falando de comunidade
comunidade criação de base para o desenvolvedor.
Já pensou vc reinventar a roda toda vez que for programar?
Graças as comunidades e a ideia da comunidade Java nos não precisamos reinventar as coisas.
Use uma coisa pronta e trabalhe em cima dela, ganha-se muito dinheiro com isso.
E também criamos coisas mais complicadas e inteligentes.
olha o PHP --> blog, twitter, rede social , moodle, helpdesk, portais, Forum, etc.
tudo isso foi criado primeiro em comunidade open source do PHP
sem contar o linux
e até o Java foi criado assim!!!
Fala ai que evolução teve as empresas pagas???
elas ao contrario copiam o que existe das comunidades!!!
Experimente fazer isso, vc vai ver que é lucrativo.
tudo tem uma maneira de ganhar dinheiro.
Estou falando tudo isso porque acredito que acabando com a comunidade
diminui muito a evolução das linguagens!!!
E diminui nossa flexibilidade de criação.
completando
explicando:
As empresas pagas só copiam das comunidades
é para isso que serve a comunidade, para ser copiada mesmo e desenvolver a criação.
mas é necessario colaborar também e não só ficar sugando como vampiro!!!
M
MatHeuZ
Luiz Aguiar:
Sinceramene, OpenSolaris não fará falta pra absolutamente ninguém… já vai tarde!
verdade!!!
F
fabiomazzo
MatHeuZ:
fabiomazzo:
Não só o Google pensa em lucro (o que não é ruim, é normal) como praticamente monopoliza alguns mercados (o que é pessímo). Não entendo entendo essa mania do pessoal endeusar o Google e endomoniar a Microsoft, Oracle, etc.
Isso simplesmente não é coerente, conheço muita gente envolvida com o universo Open Source que endeusam o Google. Nada contra, mas o Google não fazem nada de diferente das outras empresas, a maior parte dos produtos deles são fechados.
Se algúem é contra a forma como a Oracle e outras empresas trabalham deveriam apoiar os projetos abertos e comunitários e não torcer pelo Google.
Desculpe-me mas não estou endeusando a Google estou apenas procurando outra solução aberta e parecida com o OpenSolaris.
que por sinal é até melhor pelo fato de ser baseado no linux e não no Unix.
Parecida também pelo fato deles usarem muito o Java também (pelo menos até o momento, qualquer hora podem mudar para a linguagem Go que é uma mescla de Java, Python, C)
Quanto ao lucro, sim é muito bom, todos querem dinheiro no bolso mas estamos falando de comunidade
comunidade criação de base para o desenvolvedor.
Já pensou vc reinventar a roda toda vez que for programar?
Graças as comunidades e a ideia da comunidade Java nos não precisamos reinventar as coisas.
Use uma coisa pronta e trabalhe em cima dela, ganha-se muito dinheiro com isso.
E também criamos coisas mais complicadas e inteligentes.
olha o PHP --> blog, twitter, rede social , moodle, helpdesk, portais, Forum, etc.
tudo isso foi criado primeiro em comunidade open source do PHP
sem contar o linux
e até o Java foi criado assim!!!
Fala ai que evolução teve as empresas pagas???
elas ao contrario copiam o que existe das comunidades!!!
Experimente fazer isso, vc vai ver que é lucrativo.
tudo tem uma maneira de ganhar dinheiro.
Estou falando tudo isso porque acredito que acabando com a comunidade
diminui muito a evolução das linguagens!!!
E diminui nossa flexibilidade de criação.
completando
explicando:
As empresas pagas só copiam das comunidades
é para isso que serve a comunidade, para ser copiada mesmo e desenvolver a criação.
mas é necessario colaborar também e não só ficar sugando como vampiro!!!
Acho que houve uma confusão, eu não discordo de você nesses aspectos, discordei quanto ao Google. Acredito na comunidade Open Source e sei o quanto isso pode trazer de ganhos, inclusives financeiros, para todos nós. E é claro, é necessário retribuir.
Contribuir e dar os devidos créditos, veja um exemplo que ninguem se atenta: A Apple disse a pouco tempo atrás que ela possui o navegador mais moderno do mercado. Ótimo. Só que ela não disse que o renderizador do Safari é do projeto KHTML, do KDE. Provavelmente deve apenas mencionar na licensa, que ninguem lê.
Fugi um pouco do assunto mas é isso ai,
Abs
K
knowledgebr
Quanto que vai custar o Java licença Enterprise Edition? OpenSolaris? o que é bom é cobrado não tem jeito, acabou a sugação.
M
marcosalex
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.
K
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.
J
joao.junior
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.
J
juliocbq
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.
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.
C
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 ?
J
juliocbq
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 ?
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.
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 ?
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.
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…
J
juliocbq
chun:
juliocbq:
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 ?
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.
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…
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.
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).
C
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.
J
juliocbq
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.
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.
C
chun
juliocbq:
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.
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.
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.
K
knowledgebr
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.
J
juliocbq
chun:
juliocbq:
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.
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.
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.
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.
C
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++.
J
juliocbq
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++.
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).
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).
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.
J
juliocbq
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.
C
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.
C
chun
Voce realmente acredita que a distancia entre Java e Ruby está apenas no compilador e na analise léxica ? (quando dentro da jvm é claro)
J
juliocbq
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.
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.
C
chun
Qual o problema ? Poderia descrever vários… vamos para alguns:
Performance
Performance
Performance
Performance
Classes inuteis
Performance
ahhh , eu estava esquecendo… tem o problema da performance tambem
OU vc acha que é “barato” simular o sistema de metodos dinamicos em uma linguagem estatica ?
J
juliocbq
chun:
Qual o problema ? Poderia descrever vários… vamos para alguns:
Performance
Performance
Performance
Performance
Classes inuteis
Performance
ahhh , eu estava esquecendo… tem o problema da performance tambem
OU vc acha que é “barato” simular o sistema de metodos dinamicos em uma linguagem estatica ?
que eu saiba o jit já resolveu esse problema que você se preocupou na primeira execução do programa. Além do mais, o ruby do java é mais rápido que o original.
Agora, seguinte, tudo que eu te posto posto também fontes. Você não me deu nem uma. Como pode passar credibilidade dessa maneira?
Sem falar que nossa conversa disvirtuou de open solaris para compiladores, execução de software ruby e python.
C
chun
JIT não faz milagres…
A primeira previa com a clausula invoke_dynamic mostrou-se 25% mais rapido que os metodos tradicionais… e eu considero 25% a mais de velocidade algo paupavel.
E ser mais rapido que o original , no caso do ruby , nao eh grande coisa, afinal , todos sabem que a R.I. é uma droga.
Quanto a dirvirtuar , concordo, voltamos ao OpenSolaris…
Cade os 80% do codigo dele em java mesmo??
J
juliocbq
chun:
JIT não faz milagres…
A primeira previa com a clausula invoke_dynamic mostrou-se 25% mais rapido que os metodos tradicionais… e eu considero 25% a mais de velocidade algo paupavel.
E ser mais rapido que o original , no caso do ruby , nao eh grande coisa, afinal , todos sabem que a R.I. é uma droga.
Quanto a dirvirtuar , concordo, voltamos ao OpenSolaris…
Cade os 80% do codigo dele em java mesmo??
faz milagre sim…
Pode até ser mais rápida, apesar de eu não ver nenhuma fonte postada que diga que ele mostrou-se 25% mais. Sem fontes não dá para ter credibilidade, além do mais, para linguagens de produção o fator desempenho não tem muita importância.
Sobre o opensolaris eu já te respondi logo acima, mas você não lê os artigos que eu te posto.
C
chun
ok ok…
detalhe: Wikipedia para voce é fonte… eu chamaria de outra coisa
J
juliocbq
chun:
ok ok…
detalhe: Wikipedia para voce é fonte… eu chamaria de outra coisa
No mestrado trabalhei com uma linguagem que chama Haskell, o compilador dela gera código C/C++ e depois compila esse código pra código nativo.
Funciona, mas o código gerado é bem menos eficiente do que um código nativo. Pra aplicações onde a produtividade do Haskell compensa e performance não é gargalo, está ok, mas se a meta é gerar código eficiente, é um ponto negativo.
Imagino que os compiladores pra JVM atuais sofram o mesmo problema.
Mas não consegui entender se o OpenSolaris consegue executar bytecodes diretamente do kernel como se fosse código nativo. Se for verdade, daria pra fazer device drivers em Java, sim. Pelo menos até onde eu entendo.
C
chun
uma JVM dentro de um KERNEL de sistema operacional, da forma que JVM é concebida hoje , na minha opinião , é loucura e uma besteira tremenda…
O julio trata java como apenas um JIT da vida… existem milhares de outras implicações dentro de um device driver.
ps: o increvel é o cara realmente acreditar na wikipedia…
J
juliocbq
chun:
uma JVM dentro de um KERNEL de sistema operacional, da forma que JVM é concebida hoje , na minha opinião , é loucura e uma besteira tremenda…
O julio trata java como apenas um JIT da vida… existem milhares de outras implicações dentro de um device driver.
ps: o increvel é o cara realmente acreditar na wikipedia…
De maneira alguma, e você novamente está distorcendo o que eu disse. Não existe mistério nenhum em um driver, que é somente um módulo( dll ou qualquer outro assembly do tipo com permissões extras no so) que é utilizado por um kernel. Essa vm é a mais simples de todas, e a menor delas, foi feita justamente pra isso.
Não existem milhares de implicações dentro de um driver, até porque eu trabalho com isso e sei como funciona.
Claro, até porque hoje a wiki está de igual pra igual com a britânica. Você está a mais de 5 anos desinformado.
J
juliocbq
marcosalex:
No mestrado trabalhei com uma linguagem que chama Haskell, o compilador dela gera código C/C++ e depois compila esse código pra código nativo.
Funciona, mas o código gerado é bem menos eficiente do que um código nativo. Pra aplicações onde a produtividade do Haskell compensa e performance não é gargalo, está ok, mas se a meta é gerar código eficiente, é um ponto negativo.
Imagino que os compiladores pra JVM atuais sofram o mesmo problema.
Mas não consegui entender se o OpenSolaris consegue executar bytecodes diretamente do kernel como se fosse código nativo. Se for verdade, daria pra fazer device drivers em Java, sim. Pelo menos até onde eu entendo.
A squalk mapeia o kernel do open solaris. É como rodar uma aplicação java em qualquer máquina com vm, com a diferença que esta roda em uma vm de mais baixo nivel.
Detalhe é que essa idéia é tão boa, que a microsoft tem uma pesquisa chamada singularity, que é desenvolver um SO nesses moldes. É um microkernel com vm embarcada(CIL/C#). Nele, tudo(qualquer linguagem que seja compilada para CIL) pode ser executada, e inclusive os drivers podem ser desenvolvidos usando uma linguagem dessas qualquer.
C
chun
Eu fico imaginando uma HEAP dentro de um espaço de kernel… ia ser algo bem interessante…
Quanto a sua empolgação referindo-se a microsoft… a mesma embarca em projetos mais do que furados a ANOS…
então ela considerar uma ideia fabulosa , não me causa empolgação nenhuma…
Repito , se fosse tão mágico , TODO MUNDO usaria , e o mundo inteiro estaria louco para implementar…
O problema é a tal “letrinha minuscula” no final…
ps: repito , Wikipedia como fonte confiavel de alguma coisa… tsc tsc… pergunte ao seu professor o que ele acha de vc colocar a wikipedia como FONTE de alguma coisa…
J
juliocbq
chun:
Eu fico imaginando uma HEAP dentro de um espaço de kernel… ia ser algo bem interessante…
Quanto a sua empolgação referindo-se a microsoft… a mesma embarca em projetos mais do que furados a ANOS…
então ela considerar uma ideia fabulosa , não me causa empolgação nenhuma…
Repito , se fosse tão mágico , TODO MUNDO usaria , e o mundo inteiro estaria louco para implementar…
O problema é a tal “letrinha minuscula” no final…
ps: repito , Wikipedia como fonte confiavel de alguma coisa… tsc tsc… pergunte ao seu professor o que ele acha de vc sitar a wikipedia como FONTE de alguma coisa…
ok, mas dê uma lida no livro que eu postei acima, é muito bom.
A
Adelar
[quote=juliocbq]
marcosalex:
No mestrado trabalhei com uma linguagem que chama Haskell, o compilador dela gera código C/C++ e depois compila esse código pra código nativo.
Funciona, mas o código gerado é bem menos eficiente do que um código nativo. Pra aplicações onde a produtividade do Haskell compensa e performance não é gargalo, está ok, mas se a meta é gerar código eficiente, é um ponto negativo.
Imagino que os compiladores pra JVM atuais sofram o mesmo problema.
Mas não consegui entender se o OpenSolaris consegue executar bytecodes diretamente do kernel como se fosse código nativo. Se for verdade, daria pra fazer device drivers em Java, sim. Pelo menos até onde eu entendo.
A squalk mapeia o kernel do open solaris. É como rodar uma aplicação java em qualquer máquina com vm, com a diferença que esta roda em uma vm de mais baixo nivel.
Detalhe é que essa idéia é tão boa, que a microsoft tem uma pesquisa chamada singularity, que é desenvolver um SO nesses moldes. É um microkernel com vm embarcada(CIL/C#). Nele, tudo(qualquer linguagem que seja compilada para CIL) pode ser executada, e inclusive os drivers podem ser desenvolvidos usando uma linguagem dessas qualquer.
Interessante… valeu pela dica.
Att.
J
juliocbq
Só uma coisa, stack ou heap, qulquer um é uma área de memória, e vai ser guardado na ram, não no kernel(que aliás, vai estar em outra área da ram também).
C
chun
Detalhe , uma HEAP é algo bem mais singular que uma simples STACK… acho melhor voce não comparar as duas coisas.
Outra coisa , falei em “Espaco de Kernel” nao no “espaço do kernel” larga mão e lê direito.
J
juliocbq
chun:
Detalhe , uma HEAP é algo bem mais singular que uma simples STACK… acho melhor voce não comparar as duas coisas.
Outra coisa , falei em “Espaco de Kernel” nao no “espaço do kernel” larga mão e lê direito.
sendo no ou de se entende pela mesmo coisa. Você pensava que a vm estaria na mesma área de memória que o kernel, o que não é verdade.
Pode comparar sim, as duas são simplesmente espaços reservados a guardar variáveis de programas(são estruturas de dados diferentes, mas possuem o mesmo intuito na arquitetura de um sistema operacional), com a diferença que uma stack no winxp tem espaço de 8mb, e é usada para guardar variáveis locais, enquanto uma heap guarda todas as instâncias.
Olha, você pode não usar a wiki, mas pelo menos tente usar o google em suas pesquisas.
C
chun
Uma HEAP é um simples espaço ? Hummmmm… ok entao.
O intuito da HEAP é servir de PILHA ? Hummmmmm… ok entao.
E
eduveks
Só queria chamar atenção para duas coisas…
:arrow: chun, tenho a certeza que vc já viu como o bytecode funciona, e vc acha q o bytecode só pode ser revertido em Java? E para gerar um bytecode bom tem que gerar um código Java e depois compilar com a JVM? Ok, o JRuby pode fazer assim, eu no CajuScript fiz assim, mas estou mudando isto para usar o BCEL que só trás vantagens, até me custa a acreditar que o JRuby n gere o bytecode diretamente.
Por exemplo, um simples:
try {
System.out.println("try");
} catch (Exception e) {
System.out.println("catch");
System.out.println(e);
} finally {
System.out.println("finally");
}
O bytecode gerado por este bloco de código, poderá ser revertido apenas em Java!? Claro que não, que o bytecode n vai ter nada de Java, não dá para dizer que o bytecode é Java, bytecode é bytecode da JVM e nada de Java! Por isso não vejo por que a guerra ai, vc pega no bytecode deste try/catch e converte até num try/catch alá VB ou sei lá o que, que pouco tem no bytecode de sintaxe Java. Ou melhor não tem nada de sintaxe Java. Portanto uma vez em bytecode Java deixa de existir. A origem pode ter sido um código Java, como pode ter sido Scala, etc… dês que consiga converter a sintaxe de input num bytecode válido para a JVM. Então o que que é o tão precioso Java? A sintaxe? A JVM? O bytecode? O que que é imutável nisto?
:arrow: opensolaris já usei e gostei! pena o desenvolvimento ser lento e bugs demorarem para serem resolvidos como já tinha citado, mas é um sistema que teria muito futuro, até por que a barreira do hardware nem é tão grande assim, tem os drivers principais, até os drivers 3D, a meses instalei no notebook da minha empresa e funcionou tudo, até a webcam.
E para usar como um sistema de teste seria excelente. O opensolaris esta morrendo ou já esta com a morte garantida, mas o Solaris esta muito longe de estar morto, basta ver na área da banca, os sistemas da Reuters e por ai fora, e ter um sistema aberto para fazer testes e desenvolvimento é maravilhoso, pois só o ambiente de testes e desenvolvimento custa muito usando o Solaris e máquinas reais, com o opensolaris esta parte ficaria mais barata ainda podendo usar VMs. Ainda acho que haveria vantagens em ter o OpenSolaris vivo, mas para a Oracle é capaz de não ter vantagem.
Até para o desenvolvimento do Solaris, era bom ter uns cobaias onde poderiam lançar updates de testes que seria testados pelos usuários do OpenSolaris e depois ser portados para o Solaris com maior fiabilidade.
C
chun
eduveks:
Só queria chamar atenção para duas coisas…
:arrow: chun, tenho a certeza que vc já viu como o bytecode funciona, e vc acha q o bytecode só pode ser revertido em Java? E para gerar um bytecode bom tem que gerar um código Java e depois compilar com a JVM? Ok, o JRuby pode fazer assim, eu no CajuScript fiz assim, mas estou mudando isto para usar o BCEL que só trás vantagens, até me custa a acreditar que o JRuby n gere o bytecode diretamente.
Por exemplo, um simples:
try {
System.out.println("try");
} catch (Exception e) {
System.out.println("catch");
System.out.println(e);
} finally {
System.out.println("finally");
}
O bytecode gerado por este bloco de código, poderá ser revertido apenas em Java!? Claro que não, que o bytecode n vai ter nada de Java, não dá para dizer que o bytecode é Java, bytecode é bytecode da JVM e nada de Java! Por isso não vejo por que a guerra ai, vc pega no bytecode deste try/catch e converte até num try/catch alá VB ou sei lá o que, que pouco tem no bytecode de sintaxe Java. Ou melhor não tem nada de sintaxe Java. Portanto uma vez em bytecode Java deixa de existir. A origem pode ter sido um código Java, como pode ter sido Scala, etc… dês que consiga converter a sintaxe de input num bytecode válido para a JVM.
:arrow: opensolaris já usei e gostei! pena o desenvolvimento ser lento e bugs demorarem para serem resolvidos como já tinha citado, mas é um sistema que teria muito futuro, até por que a barreira do hardware nem é tão grande assim, tem os drivers principais, até os drivers 3D, e para usar como um sistema de teste seria excelente. O opensolaris esta morrendo ou já esta com a morte garantida, mas o Solaris esta muito longe de estar morto, basta ver na área da banca, os sistemas da Reuters e por ai fora, e ter um sistema aberto para fazer testes e desenvolvimento é maravilhoso, pois só o ambiente de testes e desenvolvimento custa muito usando o Solaris e máquinas reais, com o opensolaris esta parte ficaria mais barata ainda podendo usar VMs. Ainda acho que haveria vantagens em ter o OpenSolaris vivo, mas para a Oracle é capaz de não ter vantagem.
Até para o desenvolvimento do Solaris, era bom ter uns cobaias onde poderiam lançar updates de testes que seria testados pelos usuários do OpenSolaris e depois ser portados para o Solaris com maior fiabilidade.
E o que Bytecodes tem a ver com heap ? A JVM garante não só a execução de bytecodes, mas tambem um COMPORTAMENTE PADRAO… que deve ser seguido por qualquer COISA que um dia queira ser chamda de Java…
Logo… o comportamento deste “Driver” deve seguir o comportamento padrao de um JVM… resposta a thread identica , forma de isolamentos… e isso conta… vai impactar DIRETAMENTE na performance , e isso em um driver , é incocebivel em varios cenarios !
O PRECIOSO de JAVA está EXATAMENTE nisso… ele GARANTE o ambiente onde é executado… desde comportamente até mesmo “features”…
e isso REALMENTE é importante para WORE…
Opensolaris NUNCA teve futuro… nao apenas devido a essa quantidade de baboseiras descritas aqui… mas devido ao fato de ser um projeto FECHADO que foi ABERTO com a visao de eh OpenSource , entao tem futuro e é bom…
OpenSolaris nasceu morto.
Se a oracle for esperta , ela pelo menos libera os componentes dele sob GPL v2, assim podemos aproveitar o ZFS no kernel do linux como padrao.
C
chun
Detalhe , fico imaginando esse teu driver 3d escrito em Java.
Essa mania de BALA DE PRATA que Fan Boys do java tem é algo que realmente irrita.
E
eduveks
Eu acrescentei umas coisas no meu post acima… e se puder chun atualiza ou resume a minha citação em “…” por favor, gracias.
Mas repito aqui:
Então o que que é o tão precioso Java? A sintaxe? A JVM? O bytecode? O que que é imutável nisto?
Chun, vc fala tando tem Java, como algo que não pode mudar, mas o que vc defende tanto como sendo o tal “Java imutável”!?
Isto que não entendi bem ainda… qual é a parte do Java que é o tesouro imutável do Java?! Q se mudar já não pode ser chamado de Java??? A especificação?
J
juliocbq
eduveks:
Eu acrescentei umas coisas no meu post acima… e se puder chun atualiza ou resume a minha citação em “…” por favor, gracias.
Mas repito aqui:
Então o que que é o tão precioso Java? A sintaxe? A JVM? O bytecode? O que que é imutável nisto?
Chun, vc fala tando tem Java, como algo que não pode mudar, mas o que vc defende tanto como sendo o tal “Java imutável”!?
Isto que não entendi bem ainda… qual é a parte do Java que é o tesouro imutável do Java?! Q se mudar já não pode ser chamado de Java??? A especificação?
eduveks, não perca seu tempo discutindo com quem não sabe o que fala. Eu já desisti.
C
chun
eduveks:
Eu acrescentei umas coisas no meu post acima… e se puder chun atualiza ou resume a minha citação em “…” por favor, gracias.
Mas repito aqui:
Então o que que é o tão precioso Java? A sintaxe? A JVM? O bytecode? O que que é imutável nisto?
Chun, vc fala tando tem Java, como algo que não pode mudar, mas o que vc defende tanto como sendo o tal “Java imutável”!?
Isto que não entendi bem ainda… qual é a parte do Java que é o tesouro imutável do Java?! Q se mudar já não pode ser chamado de Java??? A especificação?
Eu defendo uma plataforma constante e com regras bem definidas… nao só eu , a Sun tmb defendia isto.
Existem regras para você chamar ALGO de Java… se você não segue , não vem dizer que é Java.
Existe um livro que descreve a linguagem… e outro que descreve o comportamento de uma JVM java…
Siga eles… e pronto , terás java… fora isto , terás alguma coisa parecida com java.
C
chun
juliocbq:
eduveks:
Eu acrescentei umas coisas no meu post acima… e se puder chun atualiza ou resume a minha citação em “…” por favor, gracias.
Mas repito aqui:
Então o que que é o tão precioso Java? A sintaxe? A JVM? O bytecode? O que que é imutável nisto?
Chun, vc fala tando tem Java, como algo que não pode mudar, mas o que vc defende tanto como sendo o tal “Java imutável”!?
Isto que não entendi bem ainda… qual é a parte do Java que é o tesouro imutável do Java?! Q se mudar já não pode ser chamado de Java??? A especificação?
eduveks, não perca seu tempo discutindo com quem não sabe o que fala. Eu já desisti.
Uma pessoa que diz que uma HEAP é uma STACK… não tem autoridade para falar isto.
J
juliocbq
chun:
juliocbq:
eduveks:
Eu acrescentei umas coisas no meu post acima… e se puder chun atualiza ou resume a minha citação em “…” por favor, gracias.
Mas repito aqui:
Então o que que é o tão precioso Java? A sintaxe? A JVM? O bytecode? O que que é imutável nisto?
Chun, vc fala tando tem Java, como algo que não pode mudar, mas o que vc defende tanto como sendo o tal “Java imutável”!?
Isto que não entendi bem ainda… qual é a parte do Java que é o tesouro imutável do Java?! Q se mudar já não pode ser chamado de Java??? A especificação?
eduveks, não perca seu tempo discutindo com quem não sabe o que fala. Eu já desisti.
Uma pessoa que diz que uma HEAP é uma STACK… não tem autoridade para falar isto.
Não distorça as minhas palavras.
C
chun
Você continua a compara uma heap com uma STACK… e ainda diz que elas possuem o mesmo intuito…
tsc… tsc…
S
Shelson
Eu gosto muito do OpenSolaris.
Uso no dia-a-dia e recomendo.
Se a Oracle nao continuar com este projeto OpenSource, eu pagarei pela licença do Solaris.
Solaris eh uma das melhores coisas que a Oracle disponibiliza.
Nele, eu posso desenvolver Java, me sentir protegido contra invasões, usar ZFS/crossbown e todos os recursos nativos.
:arrow: Qual Linux/distro(nao sei como eh a nomenclatura disso) tb tem ZFS ?
T
tralsl
Shelson:
Eu gosto muito do OpenSolaris.
Uso no dia-a-dia e recomendo.
Se a Oracle nao continuar com este projeto OpenSource, eu pagarei pela licença do Solaris.
Solaris eh uma das melhores coisas que a Oracle disponibiliza.
Nele, eu posso desenvolver Java, me sentir protegido contra invasões, usar ZFS/crossbown e todos os recursos nativos.
:arrow: Qual Linux/distro(nao sei como eh a nomenclatura disso) tb tem ZFS ?
serah verdade q as proximas versoes do java lançados pela sun/oracle terão um licenciamento diferenciado ?
M
marcosalex
Shelson:
:arrow: Qual Linux/distro(nao sei como eh a nomenclatura disso) tb tem ZFS ?
A licença que a Sun adotou pro ZFZ é incompatível com a GPL, apesar de ser aberta. Por isso nenhuma distro pôde adotá-lo. Pra concorrer com o ZFZ a Oracle (sim, ela) criou o brtfs sob a GPL (sim, quem fala que a Oracle não apóia iniciativas open source ou é desinformado ou mentiroso) com o propósito de ser o principal filesystem pro Linux. Agora que ela possui o ZFS também, ela não se posicionou, mas o desenvolvimento do brtfs continua forte.
C
chun
Acho uma tremenda besteira eles continuarem o desenvolvimnento do brtfs…
