O que esperar no J2SE 1.5

Jézus! Vou ter que aprender Java de novo!

Foi a mesma impressão que eu tive.
Fico me perguntando. Isso tudo não é uma quebra de paradigma suficientemente grande para podermos chamar isso de J3SE?

Cara*#@!Meu Chapéu!!!Não sei mais Java…huahauha

eu adorei poder fazer isso aqui:

System.out.printf("name count");
    System.out.printf("%s %5d", user,total);

Meu deus … java é complicado demais. Vou começar a estudar delphi

…

:mrgreen:

"marciolx":

eu adorei poder fazer isso aqui:

System.out.printf("name count");
    System.out.printf("%s %5d", user,total);

:D

import static java.lang.System.out;

public class Foo{

   public static void main(String[] args){
       out.printf("Olá, {0}!! Hoje é {1}", user.getName(), today.getDate());
   }

}

:P

eu particularmente odiei os Statics imports, vai gerar muita confusão.

e tbm nao gostei os negocios como:
List<String> l = new ArrayList<String>();

isso eh meio estranho, se voce quer fazer uma funcao generica? como faz? teria que fazer algo como:
public List<retorno o q aqui> funcao(List<Object> lista);

ahh, vi um exemplo assim:
Integer i = 10; // conversao automatica
Integer i2 = 20; // conversao automatica

int resultado = i + i2;

seria uma sobrecarga de operadores? mas eu nao posso fazer isso nas minhas classes? so nestas pre-estabelidas?

"maxguzenski":

isso eh meio estranho, se voce quer fazer uma funcao generica? como faz? teria que fazer algo como: public List<retorno o q aqui> funcao(List<Object> lista);

Que tal assim?

public class SeiLa<A>{

   private ArrayList<A> l = new ArrayList<A>();

   public SeiLa(){}

   public List<A> metodo(A args...){
      //...
   }

}

E usaria...

//...
SeiLa<Integer> s = new SeiLa<Integer>();
List<Integer> l = s.metodo(1, 2, 3, 4);

Eba … o JWS ficou mais legalzinho … bem a tempo pro meu projeto, quer dizer, acho … quanto tempo depois do beta pra sair uma versão final? (nao acompanhei os outros betas).

Gosto muito do Autoboxing/Unboxing, Generics … mas o Enhanced for Loop não me convenceu, ficou meio feioso … prefiro iterar sobre as coleções mais didaticamente (pro leitor do código :roll: ), podiam então ter criado o foreach mesmo.

Que tal fazermos uma compilação dos melhores links da dita cuja?

[]´s

Apesar do nome, Generic eh legal… Static imports sucks hein?!.. a sintaxe do “foreach” pessoalmente tambem nao me agrada, e a desculpa de querer evitar colocar mais uma keyword nao cola… no final das contas, o byte code gerado nao seria o mesmo em todos os casos?! :? nao eh taaao complexo assim assimilar uma coisinha a mais…

Apesar de tudo ( e apesar da Sun ser… a Sun ), ta ficando rulez

Parece que o “booom” do .net fez o pessoal correr um pouquinho.

Rafael

Não gosto de autoboxing, pelo menos ficou me parecendo mais 1 gambiarra para resolver a iteração entre generics e tipos primitivos.

Mas sem dúvida alguma a coisa que mais vai alavancar novidades e melhorias é metadata, alem disso tempos agora umas APIs bem legais: util.concurrent, javax.manangement na j2se.

Aí vai o primeiro:
:arrow: http://java.sun.com/developer/technicalArticles/releases/j2se15/

Static import faz mto sentido. Eu gostei, pelo menos… vc quer ver de onde diabos veio uma variavel, vc ja vai automaticamente pro comeco do arquivo ou olha no outline view… e em ambos os casos, vc vai dar de cara com os imports, sem precisar fazer aquele truque de implementar uma interface soh com constantes

Alem de finalmente acabar o nojinho que dava usar java.lang.Math

Adicionar uma nova keyword na sintaxe quebra MUITO codigo legado que por acaso usava aquela palavra como identificador. Eh soh perguntar pro pessoal do JUnit se eles gostaram quando a Sun resolveu introduzir assert

“cv”:

Adicionar uma nova keyword na sintaxe quebra MUITO codigo legado que por acaso usava aquela palavra como identificador. Eh soh perguntar pro pessoal do JUnit se eles gostaram quando a Sun resolveu introduzir assert ;)

É vero, fiz uma pesquisa rápida aqui no repositorio, find -name “*.java” -exec grep foreach {} ;, e achei varias ocorrencias, uma keyword nova seria péssimo, hehehe.

Hm, mas pq ter que ir ate la em cima qdo na proria linha vc poderia saber a classe? ler

Math.abs()

me parece melhor do que ler

abs()

O static import nao me livra da implementacao nao?! ou seja, eu ainda vou ter a interface/classe com os membros static, a unica diferenca eh que nao vai ser preciso explicitamente referenciar a classe… ou tem algo que eu nao vi?

Rafael

Isso ate da pra considerar…

O estranho vai ser se, no futuro, comecar cosias como "ah, a gente nao pode fazer certo pq senao alguns sistemas iram dar erro de compilacao… temos que manter a compatibildade com o java 1.1 ainda "…

Rafael

pô… num saquei coleh a de metadata veio…
Alguem faz um exemplozinho pratico preu entender por favor ?

Há um exemplo de cada nova funcinolidade aqui:
http://java.sun.com/developer/technicalArticles/releases/j2se15/

Eu tambem não saquei muito esse metadata… mas tambem, ainda nem li o exemplo direito.

Até.

Caramba, esse negócio de List<tipo> é template???

Hehehe… tá ficando ainda mais igual ao C++! Gosto disso… hehe

Agora pra ficar bom, só colocar ponteiros e sobrecarga de operadores… se bem que se eu entendi direito, tem algo parcido que vai sobrecarregar os operadores de = do int para o Integer por exemplo, é isso?

Sabe, eu estava pensando, porque só com strings (talvez tenham outras classes, quem sabe os Number) você pode usar o +, se + é um operador… isso não seria sobrecarga de operador já? Fiquei na dúvida…

Sim sim … mesmo esquema. Chama-se Generics

Eita …não entra nessa discussão que vão te bater :shock:

Provavelmente nunca haverá aritmética de ponteiros em Java (senão vira C super turbinado o que causaria problemas mais sérios do que o C tem - não por culpa dele, mas dos programadores! :oops: )

Não vai sobrecarregar nada … o Autoboxing/Unboxing vai fazer a conversão automática de tipos primitivos para seus wrappers (de int pra Integer, long pra Long, etc.) quando necessário (não necessariamente em uma atribuição (=) pelo que eu entendi, por isso não é sobrecarga).
É um recurso legal se for bem usado, mas o que vai aparecer de código que você nunca vai saber o que tá sendo usado (o objeto ou o tipo primitivo) vai.

Sim, é sobrecarga … mas foi uma decisão de projeto e não quiseram liberar pra nois :?

[]s

Hmmm… alguem consegue arrumar uma unica razao pra se fazer aritmetica de ponteiros em Java? Serio, eu parei pra pensar nisso outro dia, e simplesmente nao tem a menor necessidade. Entao, pra que complicar o trabalho do GC, que ja é difícil?

Uma feature Must Have que tem eh o tal do Class Data Sharing. No entanto, achei que o ganho seria maior. Com esse recurso muita coisa que era aberta do rt.jar eh mapeado diretamente na memoria. Diminui o tempo de start da JVM. Espero que continue tendo avancos nesse sentido.

Uma dúvida cruel…

:arrow: Uma aplicação java feita para 1.4.x vair rodar melhor na 1.5?

Falow galera

Provavelmente, black_fire! Nao tem mtos motivos pra rodar mais devagar, com todo esse monte de melhorias

Ponteiros em Java? :shock: Ia ser o samba da Heap doida!
Aí Cv…3000msg´s!Huahauhuah…mais um motivo para bebermorar hein?! :lol:

Alguém sabe quando será lançada(ou previsão de lançamento) a versão estável da J2SE1.5(ou seria J3SE como falou o Daniel…)?

Que tal processamento gráfico… não sei em Java, mas em C, quando se usa arimética de ponteiros, é muito mais rápido que sair fazendo putPixel() aqui e ali… tá, um ou dois não dão diferença, mas tenta 147456000 (640x480x60), que é até baixo para um jogo hoje em dia…

Claro, o drawImage() acelera bem tudo isso, mas o problema é quando você precisa alterar os pixels você mesmo, como para um efeito especial e coisa e tal…

Aliás, tem uma coisa que não gosto muito do java… quando estou usando page flipping em tela cheia, e eu preciso fazer um desenho acessando um BufferedImage, eu preciso criá-lo antes, limpá-lo a cada quadro, desenhá-lo, e só aí colar o resultado no Graphics que for retornado pelo método getDrawBuffer() da classe BufferStrategy!

Tem um jeito de pular essa etapa da criação e pegar ao invés de Image um BufferedImage?

Mais uma pergunta… (acho que eu deveria fazer outro tópico depois :-P), é possível criar BufferedImage que use a memória de vídeo? Ou ele tenta isso já para mim? Digo isso pois a transferência do vídeo para o vídeo é muito mais rápida…

Obrigado… e viva os ponteiros! hehehe

“dudaskank”:

o sei em Java, mas em C, quando se usa arimética de ponteiros, é muito mais rápido que sair fazendo putPixel() aqui e ali… tá, um ou dois não dão diferença, mas tenta 147456000 (640x480x60), que é até baixo para um jogo hoje em dia…
^__^

2 coisas:

-aritmetica de ponteiro hoje me dia so tem utilidade para coisas muuuuito bizarras, muito ao ponto de voce nao conseguir expressar direito em temos de bases e indices. Para todo o resto os compiladores fazem um servico muito bom.

-se o teu jogo usa putPixel e nao aceleracao via hardware ele vai ser lento mesmo feito todo em assembly.

Olá

Saindo totalmente do tema da pasta para dizer que ponteiros são a grandeza e a desgraça do C. Há coisas quase impossíveis de serem feitas em C sem ponteiros, há coisas quase impossíveis de serem refatoradas ou consertadas em C quando feitas com ponteiros.

É óbvio que em casos especiais os ponteiros são essenciais, são aqueles casos muito bizarros que o louds falou. Mais ou menos uns 90% do uso dos ponteiros em C é para manipular strings e isto em Java já é feito usando a classe String ou usando array de bytes. Uns outros 9,99% são para chamar funções dinamicamente em menus e isto em Java se pode fazer com Reflection. Os últimos 0,01% são os tais casos especiais que 99,99% dos programadores nunca precisou usar. Na prática a distribuição em C é diferente pelo abuso de uso dos ponteiros.

Pelo parágrafo acima concluo como o CV que não há necessidade de ponteiros em Java.

[]s
Luca

“Rafael Steil”:

O static import nao me livra da implementacao nao?! ou seja, eu ainda vou ter a interface/classe com os membros static, a unica diferenca eh que nao vai ser preciso explicitamente referenciar a classe… ou tem algo que eu nao vi?

Rafael

Tem algo que vc não viu: o javac vai dar erro de compilação pq “getInstance()” é ambíguo, já que vc deu static import em mais de uma factory. Hahahahaha!!! :twisted:

Eu acho static import a coisa mais ridícula que inventaram. E tenho dito.

[]s!

Ontem eu li sobre o Class Data Sharing direitinho… não é bem o que eu pensei que fosse. Certo mesmo seria ter essas classes na memória OnceAndOnlyOnce, usando memória compartilhada.

O texto não é claro, mas dá a entender que cada JVM faz seu mapa. Tb andei lendo sobre o MappedByteBuffer e não ficou claro pra mim se ele lê do arquivo, se ele joga tudo na RAM (ou swap, ou sei lah), etc.

Mas de qq jeito eu gostei.

[]s

“dukejeffrie”:

“Rafael Steil”:

O static import nao me livra da implementacao nao?! ou seja, eu ainda vou ter a interface/classe com os membros static, a unica diferenca eh que nao vai ser preciso explicitamente referenciar a classe… ou tem algo que eu nao vi?

Rafael

Tem algo que vc não viu: o javac vai dar erro de compilação pq “getInstance()” é ambíguo, já que vc deu static import em mais de uma factory. Hahahahaha!!! :twisted:

Eu acho static import a coisa mais ridícula que inventaram. E tenho dito.

[]s!

Eu ia tocar nesse ponto no outro post, mas com um exemplo diferente: quando voce tem metodos estaticos com nomes iguais ( como no caso do getInstance ), e em cada lugar vc usa um static import diferente…

Tipo, na classe A vc da static import nos metodos das classe S1, e usa os metodos estaticos da classe S2 referenciando a classe.
Soh que na classe B vc da static import em S2, e usa os estaticos de S1 referenciando a classe…

Vai dar uma zona… Claro, se o cara for um pouco esperto ele vai se “ligar” desse “detalhe” e fazer direito, mas se ja nao fazem direito com a coisas mais simples, como podemos esperar que facam direito com isso?! :?

Rafael

e eu estou aguardando ansioso a atualização do “The Java Language Specification”
Haja fôlego da Sun pra tanto trabalho…

Eu estou pensando muito em imagens, pois elas precisam de muita velocidade. E neste caso, acho que a aritmética de ponteiros é excelente. Por exemplo, estou fazendo alguma coisa num vetor de inteiros que estou preparando para colocar num BufferedImage e imprimir na tela. Em Java eu precisaria fazer assim:

// posso fazer como uma dimensão também, mas farei com duas
int matrix[][] = new int[y][x];
int i, j;
for(i = 0; i < y; i++) {
    for(j = 0; j < x; j++) {
        matrix[i][j] = algumMetodoQueRetornaACor(i, j);
    }
}

O problema é que, para a matriz saber onde será colocada a cor, ela tem que fazer uma operação assim: i * x + j, e, mesmo que os computadores sejam super-rápidos hoje, uma multiplicação e uma soma sempre demoram muito mais que um incremento, que seria usado nos ponteiros.

Antes de Java, C++ já fazia isso. Mas ainda tinha ponteiros

Não entendi nem um nem outro…

Bem, descontando-se as porcentagens, o que seriam estes casos especiais… e também não entendi essa parte de distribuição, o que você se refere aí?

Isso é verdade pra qualquer linguagem, e claro não só para jogos, tem também as animações, os filmes, enfim, tudo que tenha um monte de pixels por segundo…

É por isso que eu uso BufferedImage

Ah, sim, claro que com meus incríveis argumentos e influência não conseguirei introduzir isso no Java, e também não estou reclamando tanto… mas que podia ser melhor podia!

Falou!

“dudaskank”:

// posso fazer como uma dimensão também, mas farei com duas int matrix[][] = new int[y][x]; int i, j; for(i = 0; i < y; i++) { for(j = 0; j < x; j++) { matrix[i][j] = algumMetodoQueRetornaACor(i, j); } }

Primeiro, em java voce não utiliza matrizes multidimensionais. Segundo, como já tinha falado, os compiladores são muito mais espertos que voce imagina. Existem 2 otimizações para esse seu caso que torna o uso de ponteiros completamente inutil, me refiro a induction variables e array bounds check elimination, a primeira tem mais de 20 anos, a segunda exige algumas tecnicas recentes para ser efetiva.

Vejamos:

int * matrix = new int[10 * 20];

for(int i = 0; i < 10; ++i) {
  const int px = i * 20;
  for(int j = 0; j < 20; ++j) {
     matrix[px + j]  = calculaCor(i,j);
  }
}

Esse código o compilador traduz sem o menor problema para usar ponteiros. Vide fortran, isso acontece o tempo todo.

dudaskank,
Aritmética de Ponteiros Traria o Caos a linguagem Java…
imagine q um ponteiro é desreferenciado,mas ele acaba apontando(caca do programador)-indiretamente- para o ponteiro q o desreferencia,e este aponta para outro q aponta para outro…sua Heap estoura sem vc utilizar nenhum loop explícito(estrutura),e logo vc recebe um OutOfMemoryError… :shock:
A Heap eh Vasta,mas não eh infinita…li um artigo uma vez,q muitos dos problemas q ocorrem principalmente qdo alguns programas travam,como um Editor De Texto,um Aplicativo qquer eh pq uma tarefa q deixou de ser executada continua sendo referenciada em memória,e essa referência não foi completamente limpa…tah certo q pode ter n motivos para isso,mas vc sabe a q eu tô me referindo… :roll:
Um amigo,programador em C/C++ há mais de 10 anos,me falou q quando um programa eh pequeno,coisa de até 2,3 mil linhas ponteiros são sempre uma mão na roda(fácil de gerenciar),o problema eh quando vc tem um programa q eh gigantesco,200mil linhas de códigos,e outros trechos do programa(q foram escritos por outros) fazem acesso as suas funções/implementações… Cada um(programador),tem seu modo de implementar,e ás vezes,comflita com outros conceitos de outro(bom) programador…3 excelentes programadores podem gerar um programa com muitos mais defeitos do q um excelente e 2 medíocres,pq 1 excelente vai conseguir gerenciar(ou não…)os 2 tecnicamente inferiores,mas 3 excelentes programadores com técnicas distintas de programar…põe um programa q funciona no mercado,mas q erros futuros acabam comprometendo o produto(alguém aí disse Windows?),a aritmética de ponteiros contribui muito para isso…
O pior erro é o que passa na compilação e na execução…
-esse eh terrível!!!

Existem várias pesquisas sobre implementações seguras de ponteiros, a maioria foca em criar construções na linguagem que permitam acesso rápido e seguro a memoria.

A última vez que eu usei aritmética de ponteiros foi para escrever um alocador de memoria. Isso foi a um bom tempo atraz e tinha requisitos completamente não triviais.

Este código aí já faz tudo isso? Ele elimina a checagem do tamanho do vetor? Só isso!!!

Caramba… não sabia…

Também tem um outro jeito que eu fazia em C para isso, usando uma tabela de tamanho “y” para armazenar as multiplicações:

int imagem[] = new int[x*y];
int linhas[] = new int[y];
int i;

for(i = 0; i < y; i++) {
    linhas[i] = x * i;
}
// .....
for(i = 0; i < y; i++) {
    for(j = 0; j < x; j++) {
        imagem[linhas[i]+j] = geraCor(i, j);
    }
}

Isto é mais rápido, pelo menos em C/C++, porque não há a multiplicação… e sem a checagem de índice com certeza deixaria mais rápido.

Por favor louds, me ilumine, como faço pra não checar os índices do vetor!!!

vc nunca usou STL ne?

void processa_imagem(int *start, int *end) {
   while(start != end) {
      *start++ = gera_pixel();
   }
}

teu código em c++ é muito mais lento que a versão usando indexão direta pq usa 1 indireção inutil.

for(i = 0; i < y; i++) {
    int ix = i *x;
    for(j = 0; j < x; j++) {
        imagem[ix+j] = geraCor(i, j);
    }

O fato é que ninguem processa imagens assim, então não vale nem a pena discutir mais. Hoje em dia se o teu filtro não usar streams de memoria ele vai ser muito lento.

…Instalei o JDK 5 (beta) e deste então venho tendo problemas ao acessar chats na web ( não carregam) …paginas que precisam da jvm tbm não executam o aplicativo.

Alguma ideia…

Sim, desinstale :shock: e instale um JDK estável 8)

Ou reporte todo seu ambiente/configuração pro pessoal da Sun pra ajudar nos ajustes finos :lol: e depois continue baixando patches até consertar o problema :roll: