O que esperar no J2SE 1.5

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…

:slight_smile:

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? :wink:

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 :wink:

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

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

:slight_smile:

[quote=“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…
^__^[/quote]

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

[quote=“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[/quote]

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

[quote=“dukejeffrie”][quote=“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[/quote]

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![/quote]

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 :wink:

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 :slight_smile:

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! :slight_smile:

[quote=“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); } } [/quote]

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!!!

:slight_smile:

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.