Existe algum Id que identifica cada objeto de uma tela?
Voce diz, um ID para cada componente, tipo um numero serial? Acho que nao tem isso nao ( bom, o nome dele opde ser considerado um id hehe ).
Alguem confirma isso, por favor.
Rafael
Bem, minha opinião é a mesma do rafael…
nao existe um id dos componentes…
ex: JFrame - o id é JFrame…é o q o identifica…eheheh
falowww
Rafael Steil é isso mesmo, é como se fosse um numero serial
Bom, voce pode tenta usar o metodo hashCode() para pegar o hash de cada Objeto, porem nao da para garantir que o numero sera unico sempre.
Rafael
bem… eu tenho uma idéia, + num sei se funciona… vc pode colocar todos os seus objetos numa lista, ou num vetor, sei lá o que vc achar melhor… aí vc vai ter o id de cada um…
té
Valeu pessoal, vou testar o hashCode() para ver se o numero é fixo, se não for vou usar a ideia da lista…
Esse código deve ajudar a Gerar IDs não randômicos, e sem repetição.
import java.rmi.server.ObjID;
public class ObjectUtils {
public static String generateStringID() {
ObjID uid = new ObjID();
return uid.toString();
}
public static int generateIntID() {
ObjID uid = new ObjID();
return uid.hashCode();
}
}ou ainda, voce pode incorporar em seus objetos um Atributo do tipo ObjID, e trabalhar com ele quando necessário.
Espero poder ter ajudado.
Funcionou, muito obrigado ozielneto
Vale lembrar que o codigo acima soh funciona com o hashCode() pq o metodo foi sobrescrito… o metodo hashCode por si soh nao devolve numeros unicos por objetos
Guilherme Silveira
Ola,
Qual a vantagem de usar esse ObjID ?? Só vejo desvantagens, sincronização desnecessária, mais lento.
Pq não usar simplesmente uma variável estática que é incrementada a cada chamada ???
[]'s
com certeza…
o classico:
class X {
private static long counter = 0;
public synchronized static long getID() {
return ++counter;
}
}O metodo nao ia precisar ser sincronizado? Eu nao lembro se o ++counter eh atomico ou nao…
Temos de tomar cuidado com conteúdos estáticos, pois consomem uma área de memória importante para a JVM, não tem acesso sincronizado, e em ambientes clusterizados e com recursos de alta disponibilidade pode causar problemas de sincronismo e até mesmo persistência, pois o valor fica associado a classe e não ao objeto.
O Java é OOP (Oriented Object Programming) e não OSP (Oriented Static Programming)…
Acho que existem várias soluções. E a melhor depende do problema.
Para aplicativos comerciais, que se usa muitos objeto mapeados para banco de dados, o melhor mesmo é identificar um objeto por um atributo com valor único, indexado e que faça parte do domínio do problema, evitando Sequence ou Autonumeration proprietários de cada Database.
Para software básico, podemos fazer de várias maneiras. com o ObjID, ou java.rmi.server.UID, ou até mesmo com a solução do Guilherme.
Acho que não estamos aqui para nos criticar e sim para trocar informações.
Com certeza, o negocio eh trocar informacoes, tanto que achei sua solucao interessante, pq nao conhecia o UID do rmi do java, e achei estranho o negocio do HashCode por isso fui atras do source code do mesmo pra entender o pq q o HashCode poderia ser usado pra gerar numeros unicos.
Sobre o problema de usar variavel estatica como no exemplo que eu dei, sugerido pelo pelo M. Lopes (marcelo? mauricio? manoel? martin?), eh tambem utilizado pela classe ObjID/UID, entao da meio que na mesma. O codigo de exemplo que dei utiliza o metodo sincronizado. O codigo do ObjID/UID possui mais recursos nessa sincronizacao mas nao sei o quao necessarios sao eles (verificacao do tempo para criar o UID).
Nao creio que exista outro jeito de gerar ID’s individuais para objetos sem ter um valor estatico para toda a classe/aplicacao (seja ele numa variavel estatica de uma classe, em um arquivo ou no banco de dados), existe algo do genero? A ideia de nao usar o Sequence (oracle?) ou Autonumeration (sql server?) seria entao de gerar esse numero como Global ID no banco de dados (numa tabela a parte) ou retirar os ID’s de uma variavel estatica (o exemplo que dei e o teu exemplo com ObjID)… o que nao nos livra do estatico, sincronizacao e tudo mais…
Entao eu fiquei com uma duvida enorme agora, como a ObjID gera ID’s unicos se em seu codigo esta:
objNum = generator.nextLong();Sendo que:
private static final Random generator;
private final long objNum;Isto eh, o valor de objNum sera um valor randomico “long” gerado pela classe java.util.Random atraves do nextLong, que gera valores randomicos e nao valores sequenciais, de forma que o mesmo numero pode ser gerado duas vezes:
[quote]
nextLong
public long nextLong()
Returns the next pseudorandom, uniformly distributed long value from this random number generator’s sequence. The general contract of nextLong is that one long value is pseudorandomly generated and returned. All 264 possible long values are produced with (approximately) equal probability. The method nextLong is implemented by class Random as follows:
public long nextLong() {
return ((long)next(32) << 32) + next(32);
}
Returns:
the next pseudorandom, uniformly distributed long value from this random number generator’s sequence.[/quote]
Eu tenho a impressao que estou deixando passar algo com a variavel space que o ObjID utiliza, voce sabe me dizer o que eh Oziel?
Ou talvez seja o constructor que estou vendo que seja o errado.
De qualquer maneira a versao da classe eh 1.27 de 02/03/18 (18/03/2002)
Sugestoes?
Abracon,
Guilherme[/code]
Achei!
Estava faltando analisar o bloco estatico de inicializacao do ObjID… e logo acima estava a seguinte classe estatica e final:
private static final class InsecureRandom extends Random {
/** unnecessary serialVersionUID to keep watchdog tools happy */
private static final long serialVersionUID = -698228687531590145L;
private long nextNum;
public synchronized long nextLong() {
return nextNum++;
}
}Semelhancas com o codigo exemplo? :lol:
Eh a mesma coisa 
Abraco
Guilherme
[quote=“ozielneto”]Temos de tomar cuidado com conteúdos estáticos, pois consomem uma área de memória importante para a JVM, não tem acesso sincronizado, e em ambientes clusterizados e com recursos de alta disponibilidade pode causar problemas de sincronismo e até mesmo persistência, pois o valor fica associado a classe e não ao objeto.
[/quote]
Ouço grilos agora… Ninguém estava criticando você, Oziel. O Marco (mlopes, vc é Marco, né?) estava, sim, criticando aristotelicamente a sua idéia. Nenhuma idéia é boa se não passa por uma contra-prova.
Ele ainda foi mais longe, pensando no custo de processamento de sincronizar um método. Ele sabe fazer isso, ele não foge da sincronização. Mas ele acha lento. O pessoal da Sun tb acha lento.
O Guilherme deu uma solução ótima, e ele sim, foi criticado, mesmo veladamente, e chamado de ingênuo, quando vc diz que a solução dele só serve para software básico.
Ao mesmo tempo, vc falou besteira. Vc falou em “clusterização” e “recursos de alta disponibilidade” quando nem uma coisa nem outra tem a ver com o seu código. Se vc tivesse lido o Javadoc, vc veria que o id “único” gerado pelo ObjId é único para cada máquina. O mesmo acontece com o UID. Lá no Javadoc tem dicas de como fazer para gerar um Id único para um ambiente distribuído.
Isso num fórum de Java Básico, onde a maioria das pessoas têm dúvidas complexas com soluções simples. Seria melhor incentivá-los a olhar o Javadoc e a bolar soluções básicas para seus problemas antes de conquistar os ambientes distribuídos do que dar-lhes uma solução pronta e obscura.
Você também falou em consumo de memória “importante para a JVM”, como se variáveis estáticas roubassem memória da JVM. Qual abordagem vc acha que consome mais? Por acaso uma classe interna estática é SOP (Static Oriented Programming)?
[]s.
P.S.: esta sim é uma crítica pessoal. Mas não tenho nada contra a sua pessoa, e sim contra essa postura, venha de quem vier.