Não há como setar o valor de um objeto Integer com um int?
Não é possível… AAAAHhhhhhhhhHHhh…
Crie um novo Integer.
int num = 7;
Integer numero = new Integer(num);
Integers (e todos os outros wrapper objects) sao imutaveis, assim como a boa e velha java.lang.String 
Achava que org.omg.corba.IntHolder tivesse getter e setter, mas não tem (embora represente um int “mutável”). Esse objeto representa parâmetros do tipo in como [IN OUT] ou [OUT] em CORBA, portanto é mutável. Só que não tem um “getter” ou um “setter” legal.
Nâo!!!
Eu não posso criar Integer novos!!!
Integers são imutáveis??? Nãaaaaaaaaoooo
Sério, estava pensando em criar um mapa para objetos, só que usando primitivos como chaves. Será que é uma boa idéia usar List e simular a chave com o index dos elementos, que é primitivo, em vez de usar Map onde serei forçado a usar o satânico Integer?
Quão mais rápido é um List.get(int) do que um Map.get(Integer)?
Código com List:
public static PowerClass getSomethingr(int i) {
return (PowerClass) list.get(i);
}Código com Map:
public static PowerClass getSomethingr(Integer i) {
return (PowerClass) map.get(i);
}Pera, se eh pra por/tirar de um Map, pra que vc precisa modificar o valor do Integer?
É uma parada meio louca, queria aproveitar uma instância de Integer e usá-la como chave em cada Map.put, alterando apenas o seu valor interno (com um int) antes de chamar o put. Mas acho que é coisa doida.
Então não quero mais mudar Integer, quero saber se é válido usar uma List com o index simulando uma chave (só que primitiva ) ou é melhor usar o Map e o maldito Integer como chave, sendo preciso criiiiaaaarrrrr um Integer a cada put.
Sacastes?
Tem seus pros e contras - numa ArrayList, voce vai desperdicar um espacinho consideravel caso os IDs sejam muito diferentes (ja que MAX(id) = list.size())
Pq não cria seu proprio IntegerMutavel() com seus getters e setter ??? :twisted:
Pq IntegerMutavel eh um nome horrivel pra classe 
O que voce pode fazer, no entanto, eh chamar ela de IntegerID, ou NotaFiscalID, e, se vc implementar equals(), hashCode() e compareTo() direitinho (dica: delegue para os equivalentes da java.lang.Integer), fica bonito
Os ids serão sequenciais.
Agora eu tô pensando: acho isso loucura. Imagina que para cada put, em vez de criar um novo objeto chave Integer, eu apenas altere o valor interno de uma instância já existente e então a adicione à lista. Acho que o código nem compila por que vou estar tentando usar uma mesma instância para várias chaves.
Acho que poderia copiar a instância (teria que descobrir como) e depois alterar o valor interno, mas nem sei se isso é mais rápido que criar um objeto.
Aliás estou precisando de rapidez e acho que um int nativo será mais rápido do que qualquer objeto
Outra coisa: será que essa classe abaixo é criada mais rápido que um Integer?
class Jaspion {}Os ids serão sequenciais.[/quote]
Resolvido seu problema entao
[quote=renato3110]Outra coisa: será que essa classe abaixo é criada mais rápido que um Integer?
class Jaspion {}As duas sao tao pequenas, e instanciar objetos eh tao barato em Java que realmente nao vai fazer diferenca. Depois, voce esta fazendo otimizacao prematura. Pode ir ali pro canto, de castigo, pensar na vida.
[quote=cv]Resolvido seu problema entao :)[/quote] é
???
E se eu precisar criar 500 trilhões de objetos? :mrgreen:
E se eu precisar criar 500 trilhões de objetos? :mrgreen: [/quote]
Acho que
Changeman ch = new Changeman(1);é tão barato quanto
Integer it = new Integer(1);senão for mais barato. Seria como compara o mais rapido: Superman x The Flash; :?
Desde que Changeman fosse
class Changeman{
int number;
public Changeman(int i ){
number = i;
}
}
Mas e se eu precisar criar 500 trilhões de changemans em comparação com Integers ou Madimbus, sacou? Essa pequena diferença então começará a se manifestar…
Bom, se a quantidade dos teus indices eh de 500 trilhoes, com certeza acho que voce tera outros problemas para se preocupar. 
Editado: caramba - “com certeza acho” ficou boa. Oh indecisao.
Marcio Kuchma
O ponto do cv é:
Será que você vai repcisar criar isso tudo? Será que vale a pena se preocupar com isso agora? Será que isso vai ser útil algum dia? Será? Séééérááááá?
Google: “knuth optimization evil”
[]s
[quote=pcalcado]O ponto do cv é:
Será que você vai repcisar criar isso tudo? Será que vale a pena se preocupar com isso agora? Será que isso vai ser útil algum dia? Será? Séééérááááá?
Google: “knuth optimization evil”
[]s[/quote]
O cv falou que não tinha diferença, eu estou falando que tem diferença caso você precise criar muitos objetos e precise da melhor performance possível.
Jááááááéééééééééééééé
Pois é, e a resposta é essa + o que o kuchima falou.
Antes de pensar em velocidade, você deve pensar em resolver o problema.
Se estamos falando de um caso hipotético onde isso já teria sido implementado e essa preocupação realmente se fez necessária, aí a resposta é: sim, um Iteger seria obviamente mais rápido, mas essa diferença é mínima, é o tempo de copiar uma referência. Para testar faça um programinha que execute as classes um trilhão de vezes e tal.
Voltando ao mundo real, pergunto:
Agora, essa situação vai chegar?
Num caso onde seu um trilhão de índices são necessários, provavelmente você vai poder compensar a perda de performance acrescetnando mais servidores ou melhorando X e Y na sua máquina.
Vale a pena perder alguma performance mínima em troca de funcionalidade (falando de forma genérica)? A minha opinião é que eu só dou uma opnião depois de conhecer o cotnexto e medir a performance.
[]s