[quote=AbelBueno]
A primeira coisa que me veio a mente quando li esse código foi: como o C# consegue garantir que o objeto tenha um construtor default?
Daí eu vi que você precisa definir na assinatura do método que ele tenha um new vazio.
Eu já me contentaria em ter uma forma mais simples de pegar o tipo real usado no método, mesmo que ainda mantivesse a erasure.[/quote]
No C# você deve especificar isso no seu tipo T:
public static T createT() : where new() {
}
Aquele where faz com que o compilador cheque se T tem essa garantia.
No C# T também não está restrito a objetos.
Em termos de features da linguagem, eu discordo. No Java 5 foram incluídos os generics, os enums, o for each, os var args, autoboxing e o static import.
Foi incluído o printf e o Formatter, os Timers de alta precisão, o suporte a 64 bits, o pacote java.util.concurrent e as bibliotecas de instrumentação e uma versão beta do Garbage-First collector.
Todas foram mudanças muito significativas e bastante inovadoras para época - já que as linguagens adjacentes não tinham muitos desses recursos.
Agora o C# passou na frente, e é o Java que está correndo atrás do prejuízo. Nesse caso, a Oracle não pode se manter se movendo mais lentamente que a concorrência.
Isso dá uma grande vantagem, na minha opinião. O usuário não precisa saber onde está rodando a aplicação .Net. A aplicação é que se encarrega de saber sozinha.
Pior do que isso, o instalador padrão da VM Java também não desinstala nada, e nem altera adequadamente nem o PATH e nem o CLASSPATH para novas versões. É o usuário que tem que saber configurar isso. Uma tarefa para qual usuários comuns não deveriam ser delegados.
Veja, se o próprio Eclipse e o Netbeans sentiram necessidade de criar uma versão com “Java Bundled”, e incluir eles mesmos o Java para facilitar a instalação, quem dirá aquele que entrega um programa Java para um usuário 100% leigo.
Isso dá uma grande vantagem, na minha opinião. O usuário não precisa saber onde está rodando a aplicação .Net. A aplicação é que se encarrega de saber sozinha.
Pior do que isso, o instalador padrão da VM Java também não desinstala nada, e nem altera adequadamente nem o PATH e nem o CLASSPATH para novas versões. É o usuário que tem que saber configurar isso. Uma tarefa para qual usuários comuns não deveriam ser delegados.
Veja, se o próprio Eclipse e o Netbeans sentiram necessidade de criar uma versão com “Java Bundled”, e incluir eles mesmos o Java para facilitar a instalação, quem dirá aquele que entrega um programa Java para um usuário 100% leigo.[/quote]
Olhando por essa perspectiva sim, mas em questão de retrocompatibilidade soa um tanto quanto estranho. O vm deveria tratar isso para evitar transformar o sistema todo num depósito de softwares obsoletos.
Também espero que isso aconteça. Chegou a hora.
[/quote]
Mais um. E acredito que o façam, o Java 7 tirou a compatibilidade do jurássico Java 1.2 e 1.3. Como eram muito antigos, houve poucos relatos de alguém que tenha perdido bibliotecas por pararem de funcionar.
É esse que eu uso. Gosto bastante, mas como toda aplicação Java, consome bastante recurso sim. De qualquer forma, as máquinas hoje tem recurso de sobra para agentar IDEs, então esse é o último fator que olho.
Voltando ao assunto Java 8, ainda acho que a linguagem está muito atrás da concorrência:
-
O recurso de Lambda saiu muito atrasado. Ele já existe há 2 anos em C++, e há muitos em C#.
-
Há poucas novidades em bibliotecas que permitam processamento assíncrono, uma das grandes vantagens de usar lambda. Nada comparado ainda ao async e await do C#.
-
Os “default methods” são uma piada comparados aos extension methods. Bem menos flexíveis, e bem menos interessantes.
-
Os recursos de Collections e Streams usando lambda são bem legais, mas ainda não se comparam ao LINQ (de onde foram copiados), nem em elegância da sintaxe, nem em poder de processamento, nem em flexibilidade.
-
Exceto pela API de Date/Time, não houve nenhuma API nova significativa. Ok, tivemos a adição de Streams e de comandos nas colections, mas vejo isso como uma consequencia natural do lambda - e um esforço pequeno, já que foi uma cópia descarada do C#.
Para uma versão que demorou tanto a sair, na minha opinião, ainda é bastante decepcionante - mesmo sendo ainda uma mudança mais significativa do que o Java 6 e 7. [/quote]
Bom, eu comprei uma licença para pessoa física do webstorm por 99 obamas.
Também não gosto disso, fica um monte de VMs pesando a máquina, programas incompatíveis entre uma e outra VM e pra integrá-los também é uma marreta. MS pra mim sempre foi boa pra causar uma primeira impressão, mas com o tempo essas presepadas vai desanimando os desenvolvedores mais avançados. Prefiro a abordagem do Java que sempre deixa a VM mais nova no mesmo PATH.
Já o JDK é mais enjoado, mas é feito para desenvolvedores.
Também não gosto disso, fica um monte de VMs pesando a máquina, programas incompatíveis entre uma e outra VM e pra integrá-los também é uma marreta. MS pra mim sempre foi boa pra causar uma primeira impressão, mas com o tempo essas presepadas vai desanimando os desenvolvedores mais avançados. Prefiro a abordagem do Java que sempre deixa a VM mais nova no mesmo PATH.
Já o JDK é mais enjoado, mas é feito para desenvolvedores.
[/quote]
Pra mim se for para tornar compatível então deixe todo ele assim. Como não é, era preferível o usuário instalar a vm específica e não o instalador fazer isso automático. No caso acho que é para aliviar o usuário final.
ViniGodoy ,
o que eu estou mais curioso no Java9 é a execução paralela nativa por GPU na JVM usando HSA(Heterogeneous System Architecture). Se bem implementado, muita coisa boa pode sair daí…
Para quem não sabe o que é:
http://www.networkworld.com/news/2014/021314-amd39s-arm-chips-not-yet-278767.html
Podiam começar colocando oficialmente a Yeppp para dentro do JDK. Seria uma ótima oportunidade para adicionar sobrecarga de operadores na linguagem.