[quote=Botocudo][quote=ViniGodoy]
Parece que a Oracle tem em mente fazer uma boa limpeza na sintaxe do Java. Espero que realmente façam isso.
Ainda que isso quebre a compatibilidade em alguns casos, muitas vezes é importante fazer uma faxina na casa. Principalmente quando a linguagem ultrapassa os 10 aninhos de existência.[/quote]
O responsável pelo JDeveloper e outras monstruosidades fazer “faxina” no Java? E pra rodar em sensores?
Fala sério…
Java está condenado ao que sempre foi [EDIT: Trolling][/quote]
Se eles fizerem mesmo uma boa limpeza na linguagem, talvez até você aprenda a programar em java mine troll 8)
Como o Paulo citou, a Sun deixou o Java estagnar por muito tempo, agora o Java precisa correr pra não perder mercado. O Java 7 já foi um avanço e a coisa acelera com o Java 8.
Sobre FPGAs, meu mestrado foi sobre isso, sou fascinado pelo tema. Desenvolvemos um compilador em Haskell para programar esses dispositivos, é uma tecnologia muito interessante.
[quote=marcosalex]Como o Paulo citou, a Sun deixou o Java estagnar por muito tempo, agora o Java precisa correr pra não perder mercado. O Java 7 já foi um avanço e a coisa acelera com o Java 8.
Sobre FPGAs, meu mestrado foi sobre isso, sou fascinado pelo tema. Desenvolvemos um compilador em Haskell para programar esses dispositivos, é uma tecnologia muito interessante.[/quote]
Já estamos perdendo mercado…
3 meses atras estava desempregado e via MUITO mais vagas para java do que .net, agora… estou vendo iguais ou favoráveis ao lado do .net.
[quote=marcosalex]Como o Paulo citou, a Sun deixou o Java estagnar por muito tempo, agora o Java precisa correr pra não perder mercado. O Java 7 já foi um avanço e a coisa acelera com o Java 8.
Sobre FPGAs, meu mestrado foi sobre isso, sou fascinado pelo tema. Desenvolvemos um compilador em Haskell para programar esses dispositivos, é uma tecnologia muito interessante.[/quote]
Opa, interessante. No caso Kaskell era usado de que forma? O Haskell era usado para descrever os circuitos que a FPGA implementaria, tal como o VHDL faria?
[quote=matheuslmota][quote=marcosalex]Como o Paulo citou, a Sun deixou o Java estagnar por muito tempo, agora o Java precisa correr pra não perder mercado. O Java 7 já foi um avanço e a coisa acelera com o Java 8.
Sobre FPGAs, meu mestrado foi sobre isso, sou fascinado pelo tema. Desenvolvemos um compilador em Haskell para programar esses dispositivos, é uma tecnologia muito interessante.[/quote]
Opa, interessante. No caso Kaskell era usado de que forma? O Haskell era usado para descrever os circuitos que a FPGA implementaria, tal como o VHDL faria?[/quote]
Sim, linguagens funcionais são muito mais intuitivas pra descrever hardware porque os circuitos grosseiramente também são funções lógicas. Hardware que em VHDL exigem 200 linhas de código, conseguimos implementar em 15 linhas. E construir compiladores de linguagens novas em Haskell também é prático.
[quote=juliocbq]A parte de gpu já está praticamente implementada com o javafx 2.1 que está incluso no jdk 7 após o update 2. Eu andei fazendo um test drive e posso garantir que está a um ano luz de distância do swing. É totalmente integrada com o sistema operacional.
O novo toolkit gráfico se chama glass windowing toolkit e vai alavancar o java para soluções desktop com interfaces ricas
Já havia passado a hora de acabar com aquele falso puritanismo que dizia que java deveria rodar isolado dos sistemas.
[/quote]
Júlio, em que sentido é melhor? Mais fácil de montar um layout ou é simplesmente mais rápido ?
[quote=cheio_de_duvidas][quote=juliocbq]A parte de gpu já está praticamente implementada com o javafx 2.1 que está incluso no jdk 7 após o update 2. Eu andei fazendo um test drive e posso garantir que está a um ano luz de distância do swing. É totalmente integrada com o sistema operacional.
O novo toolkit gráfico se chama glass windowing toolkit e vai alavancar o java para soluções desktop com interfaces ricas
Já havia passado a hora de acabar com aquele falso puritanismo que dizia que java deveria rodar isolado dos sistemas.
[/quote]
Júlio, em que sentido é melhor? Mais fácil de montar um layout ou é simplesmente mais rápido ?
Obrigado!
[/quote]
É mais fácil, tem muito mais desempenho(porque usa a placa aceleradora e troca de mensagens do sistema nativo), mais bonito porque você pode usar css3 para alterar os widgets como no qt.
Em suma, é uma versão muito(muito mesmo) melhorada do swt. Quando o javafx 2.1 for lançado, e como já existe o openjfx(para linux) você vai ver que o java em termos de desktop vai ficar bem melhor do que é hoje. O swing pode ser muito bem portável, mas está muito longe de dar a experiência que o usuário quer em aplicações desse tipo. Eu estive fazendo a conta na minha casa com alguns testes e vi que se o netbeans fosse portado para o glass, ele ocuparia pouco mais de 200 mb na ram. Hoje aqui, e agora ele está ocupando 724mb de ram.
Isso porque toda a biblioteca do swing tem que ser bootada na ram pra jvm usar. O glass está a um ano luz do swing.
Você até pode evitar para ids e campos, mas não para processamento matemático.
A vantagem é que aí está a promessa de que não precisaremos mais nos preocupar se um tipo é ou não primitivo, e que as operações serão feitas da maneira mais eficiente possível. No fundo, é ter um tipo primitivo, com as facilidades dos tipos não primitivos. :)[/quote]
Você até pode evitar para ids e campos, mas não para processamento matemático.
A vantagem é que aí está a promessa de que não precisaremos mais nos preocupar se um tipo é ou não primitivo, e que as operações serão feitas da maneira mais eficiente possível. No fundo, é ter um tipo primitivo, com as facilidades dos tipos não primitivos. :)[/quote]
primitivos são (muito) mais rápidos[/quote]
Isso é verdade. Mas depende também da qualidade do compilador. Se tiverem cacife para fazer algo bom dessa forma só tem a melhorar para nós.
Você até pode evitar para ids e campos, mas não para processamento matemático.
A vantagem é que aí está a promessa de que não precisaremos mais nos preocupar se um tipo é ou não primitivo, e que as operações serão feitas da maneira mais eficiente possível. No fundo, é ter um tipo primitivo, com as facilidades dos tipos não primitivos. :)[/quote]
primitivos são (muito) mais rápidos[/quote]
Isso é verdade. Mas depende também da qualidade do compilador. Se tiverem cacife para fazer algo bom dessa forma só tem a melhorar para nós. [/quote]
o problema é que envolve chamadas de métodos e tal. primitivos são calculados diretamente. eu particularmente gostaria de usar apenas os objetos (acho que ficaria mais padronizado). mas o desempenho teria que ser bastante bom
O C# já faz isso hoje. Você pode fazer coisas como:
O compilador é capaz de determinar o tipo da variável em compile time, e transformar isso a chamada a métodos. Eu realmente acho que eles vão copiar o modelo, onde você tem um int normal, e o tipo int? que permite null (e provavelmente é mapeado para um wrapper). De qualquer forma, a VM também é capaz de fazer operações com o int? na forma de int, quando vê que são seguras.
Mas desde o princípio, sempre achei que esse deveria mesmo ser um papel da VM e do compilador, e não do programador.
O C# já faz isso hoje. Você pode fazer coisas como:
…[/quote]
Seria interessante que colocassem algo como inferência de tipos, mais ou menos como temos em Scala. Assim o tipo a ser retornado seria o tipo requerido, sendo chamado o método de conversão mais conveniente.
O C# já faz isso hoje. Você pode fazer coisas como:
…[/quote]
Seria interessante que colocassem algo como inferência de tipos, mais ou menos como temos em Scala. Assim o tipo a ser retornado seria o tipo requerido, sendo chamado o método de conversão mais conveniente.
[/quote]
tipo uma conversão implícita? como fazem nas sobrecargas de operadores?
O C# já faz isso hoje. Você pode fazer coisas como:
…[/quote]
Seria interessante que colocassem algo como inferência de tipos, mais ou menos como temos em Scala. Assim o tipo a ser retornado seria o tipo requerido, sendo chamado o método de conversão mais conveniente.
[/quote]
tipo uma conversão implícita? como fazem nas sobrecargas de operadores?[/quote]
Parecido com isto. No caso de Scala pode não ser indicado o tipo, sendo este inferido a partir do tipo do dado que está sendo recebido:
Como em Java o tipo deve ser indicado ele poderia ser usado para escolher uma função de conversão apropriada do lado direito da expressão. Assim:
