Acho que uma instancia “new” pode gastar mais memoria do que fazer uma chamada static direto.
Mas nao tenho certeza disso, vcs que me corrijam se estiver enganado.
Ninguem poderia ajudar com a minha dúvida, por favor? :?:
[quote=joaosiqueira]Ola pessoal,
Uma duvida:
O processo que o modificador static faz nao e a mesma ideia que uma Reflection ?
Sempre que dizemos que um Reflection e mais lento do que dar um new, certo??
Portanto teria que dizer que o static e mais lento tb que fazer uma instanciaçao, nao e?
Qual o opiniao de vcs nisso?
abrs 
[/quote]
Não. Não necessariamente. Não.
E sua pergunta já estava respondida pelo post do victorwss.
Não confunda carregar uma classe com instanciar uma classe. São coisas bem diferentes.
Carregar uma classe = A JVM lê um arquivo .class e inicialmente vê apenas um monte de bytes. Então ela lê estes bytes e monta a estrutura da classe (com os métodos, atributos e todas as instruções que há nos métodos). Toda esta estrutura é carregada internamente na JVM e pode ser parcialmente acessada por meio da classe java.lang.Class. Sempre que uma classe é carregada, a JVM cria um objeto do tipo java.lang.Class para representá-la. Imediatamente após isto ser feito, a JVM inicializa os valores dos atributos estáticos bem como os blocos de inicialização de classe (na verdade toda esta inicialização nos bytecodes aparece como um método chamado “<clinit>”.
Instanciar uma classe = A JVM aloca uma área de memória do tamanho necessário para a instância e a limpa (para evitar problemas com memória não-inicializada, comuns em C e C++). Por estar limpa significa que todos os atributos terão o valor inicial false para campos boolean, 0 para os demais primitivos e null para campos de tipo objeto. Em seguida a JVM coloca na primeira parte desta área alocada o ponteiro para o objeto Class correspondente (que é aquilo que o método getClass() retorna) e após isto, o construtor é invocado como se fosse um método void.
Para a classe ser instanciada, ela precisa ser primeiramente carregada.
Sempre que a JVM vê que uma classe precisa ser carregada, ela a carrega automaticamente sem que você peça isso. Se na inicialização da classe uma exceção for lançada, um ExceptionInInitializerError é lançado. Isso é um Error porque em geral a hora em que uma classe é inicializada costuma ser pouco previsível ou controlável. E se a classe não pôde ser inicializada corretamente, então fatalmente ela não poderá ser usada adequadamente.
victorwss,
Muito boa boa sua explicaçao, gostei mesmo.
Mas nesse momento nao teriamos que concordar com o ccaneta?
Quando diz que o fato de usar uma classe carregada usaria menos memoria e evitaria o tempo de instanciar uma classe, ao contrario do new em que temos que carregar e depois instanciar?
Pensando assim usar um static seria mais vantajoso?
Eu penso logicamente que 1 passo e sempre mais rapido que 2 passos, agora nao sei a opiniao de voces em relaçao a isso…
O que vcs opinam?
[quote=Mauricio Linhares][quote=joaosiqueira]Thingol,
Entao podemos dizer que qdo eu faço uma Reflection de uma classe, estou carregando da mesma forma que um static faz?
Se eu pensar neste modelo, sempre que dizer que um Reflection e mais lento do que dar um new, certo?? Teria que dizer que o static e mais lento tb, nao e?
O que vc acha disso?
:twisted: [/quote]
Impressão minha ou esse cara escreve feito o Márcio Duran?[/quote]
Impressão minha ou ele é um fake do Mr. Duran Duran?
[quote=joaosiqueira]victorwss,
Muito boa boa sua explicaçao, gostei mesmo.
Mas nesse momento nao teriamos que concordar com o ccaneta?
Quando diz que o fato de usar uma classe carregada usaria menos memoria e evitaria o tempo de instanciar uma classe, ao contrario do new em que temos que carregar e depois instanciar?
Pensando assim usar um static seria mais vantajoso?
Eu penso logicamente que 1 passo e sempre mais rapido que 2 passos, agora nao sei a opiniao de voces em relaçao a isso…
O que vcs opinam?
[/quote]
Um passo é mais rápido que dois passos, obviamente. Mas sua aplicação não rodará duas vezes mais rápido só porque você teve preguiça de usar OO e usou static em tudo quanto é quanto. O motivo é simples: a instanciação de objetos não é parte mais custosa de aplicação. O que é custoso é mandar queries no banco de dados, escrever arquivos, enviar dados via rede, fazer serialização, parsear XML… Ou seja, instanciar ou não objetos é coisa ínfima, perto de muitas outras coisas.
E eu já falei que não é recomendável usar variáveis estáticas em ambiente Java EE, devido aos múltiplos classloaders, não falei? Sabia que há problema na serialização de objetos quando a variável é estática? Lembre-se também que muitos containeres dependem que seus métodos não sejam estáticos.
Então qual é o ponto? Você quer provar que orientação a objetos não vale a pena?
Leonardo3001,
Nao estamos pensando em fatores de midleware, somente num simples trecho de codigo java ao maximo da performance…
Pelo que vejo, vc ja esta concordando comigo em alguma coisa:
1 processo e mais rapido que 2…
Portanto se com um metodo static eu evito um processo de instanciaçao, vemos que um static por mais desaconselhavel de praticas de design, J2EE e etc, e mais rapido e nao podemos negar!
Quando vamos começar a pensar que o simples gera o avançado, e nao pensar que nem sempre temos memoria em todos os dispositivos… ja pensou se um aplicativo java da Nasa pudesse usar o que um simples cadastro exige num mero PC!!
:shock:
Essa aula de Static e Refletion já vai ser bom pro seu curriculum hein… mais ainda Heap e Stack são assuntos basico até para certificação Java hein… [size=18]; )[/size]
[quote=joaosiqueira][quote=Leonardo3001]
Um passo é mais rápido que dois passos, obviamente. Mas sua aplicação não rodará duas vezes mais rápido só porque você teve preguiça de usar OO e usou static em tudo quanto é quanto. O motivo é simples: a instanciação de objetos não é parte mais custosa de aplicação. O que é custoso é mandar queries no banco de dados, escrever arquivos, enviar dados via rede, fazer serialização, parsear XML… Ou seja, instanciar ou não objetos é coisa ínfima, perto de muitas outras coisas.
[/quote]
Leonardo3001,
Nao estamos pensando em fatores de midleware, somente num simples trecho de codigo java ao maximo da performance…
Pelo que vejo, vc ja esta concordando comigo em alguma coisa:
1 processo e mais rapido que 2…
Portanto se com um metodo static eu evito um processo de instanciaçao, vemos que um static por mais desaconselhavel de praticas de design, J2EE e etc, e mais rapido e nao podemos negar!
Quando vamos começar a pensar que o simples gera o avançado, e nao pensar que nem sempre temos memoria em todos os dispositivos… ja pensou se um aplicativo java da Nasa pudesse usar o que um simples cadastro exige num mero PC!!
:shock:
[/quote]
Não realidade, quando concordo que “um é mais rápido que dois”, não implica que concordo que static é mais rápido que dar new. Na verdade, não tenho a inteligência do Kumpera para detalhes do baixo nível do Java. Tudo que sei é que, pela minha experiência, não há diferenças, para o usuário, entre uma aplicação que usa static de outra que não usa.
J2EE não é só para middleware. A maioria das pessoas usam a plataforma para fazer aplicações web também.
Quando não se tem memória, deve-se evitar usar muitos recursos, só isso, não tem nada a ver fazer instanciação ou não. Outra, otimizações locais não resultam em grandes melhorias no resultado final. Otimizar é pensar globalmente, na aplicação como um todo, não em detalhes irrelevantes de baixo nível.
Aplicações da Nasa, ou até do Google, tem requisitos tão especiais que acredito que eles utilizam só a linguagem Java, a plataforma é proprietária feita por eles mesmos. Mas ainda assim, acho impossível eles sugerirem que se deva usar static ao invés de instanciar objetos.
Você não consegui relacionar static com SOA ,você sabe como isso fuciona ?
Numa análise fria, nestes termos super-simplificados, sim, static é mais rápido.
E quem vir essa frase acima e for usar static pra tudo, e digo parabéns. Parabéns por ferrar com toda a arquitetura do teu projeto p/ ganhar alguns microsegundos. Ou parabéns por usar uma arquitetura totalmente procedural numa linguagem orientada a objetos, e ignorar todos os outros recursos úteis da linguagem.
A discussão foi ótima com toda a explicação técnica do que acontece nos bastidores, útil para quem quiser fazer algo extremamente avançado e específico. Para o resto, isso só serve para inflar o ego pra dizer que estavam certos, mesmo que não tenha a mínima importância na vida deles.
[quote=Bruno Laturner]Numa análise fria, nestes termos super-simplificados, sim, static é mais rápido.
E quem vir essa frase acima e for usar static pra tudo, e digo parabéns. Parabéns por ferrar com toda a arquitetura do teu projeto p/ ganhar alguns microsegundos. Ou parabéns por usar uma arquitetura totalmente procedural numa linguagem orientada a objetos, e ignorar todos os outros recursos úteis da linguagem.(…)…
[/quote]
:arrow:In object-oriented Java were a great improvement over the procedural paradigm (Naturalmente isso é baseado em que Arquitetura estamos falando se Framework) ou se ERP´s,ou você quer discutir OFBIZ ?,pois nessa tecnologia existem serviços static, você sabia ???
Bruno,
Acredito que a razao aqui nao e provar nada para ninguem dizendo vc esta certo ou errado, e apenas buscar uma melhor soluçao num momento critico…
No mundo de TI, existem momentos em que termos a melhor arquitetura e a melhor saida… mas como digo, existem outros momentos em que queremos somente perfomance ao limite!!
Ai nao adianta botarmos patterns, patterns, pq o que vai deixar rapido de verdade é o código simples ao extremo e quanto mais estruturado melhor! Como um profissional de TI posso lhe garantir!
Mas a grande enquente aqui foi, so se um static era mais rápido num metodo, e como podemos concluir isso é verdade! Depois de muita polemica e contradiçao no forum GUJ.
Se pensarmos isso é bonito? Talvez nao, mas se olharmos de outro angulo as vezes e a melhor soluçao, so cabe a vc decidir quando fugir ao extremo.
Uma coisa que brasileiro adora é tomar decisões na seguinte base:
- Eu acho que…
- Ouvi falar que…
- Me falaram que…
e a pior: - Minha opinião é que…
Em vez de fazer experimentos e verificar os números. Nesse caso é relativamente fácil determinar os números.
Como dizia um personagem do Jô Soares, “meu negócio é números”.
Então que tal fazer alguns “benchmarks” e ver qual é a diferença de tempo entre usar “static” ou não?
Já vou antecipando que a diferença é desprezível na maior parte dos casos de uso, mas não tomem minha palavra por verdade absoluta.
[quote=thingol]
Então que tal fazer alguns “benchmarks” e ver qual é a diferença de tempo entre usar “static” ou não?
Já vou antecipando que a diferença é desprezível na maior parte dos casos de uso, mas não tomem minha palavra por verdade absoluta. [/quote]
Thingol,
Estou partindo por lógica que 1 passo e mais rápido que 2…
Ai e so a questao de averiguar o quanto mais rápido, mas a lógica sempre vem antes de testar e programar…
Quem nunca ouviu de “tentiva e erro na programaçao”, ai quem sofre é o compilador! rs…
:roll:
[quote=thingol]
Então que tal fazer alguns “benchmarks” e ver qual é a diferença de tempo entre usar “static” ou não?[/quote]
Não podemos ter intuições ou entender observância sobre o que é o melhor estudo de viabilidade ou escalabilidade de fatores complicadores, você toma decisão através de uma calculadora ciêntifica.
[quote]
Já vou antecipando que a diferença é desprezível na maior parte dos casos de uso, mas não tomem minha palavra por verdade absoluta. [/quote]
A verdade absoluta foi negar ao proprio benchmarks, por entender que decisões vão de um entendimento ciêntifico de sua intuição.
A lógica diz apenas :
Se vou executar 1 passo em vez de 2, vou gastar menos tempo.
A experimentação diz:
Executar apenas 1 passo, em vez de 2, economiza apenas 0,002% do tempo de processamento*, e não vale a pena.
Não dá para determinar essa porcentagem só por lógica. E pela minha experiência não dá para determinar essa porcentagem nem sabendo exatamente quais são as instruções adicionais que o computador irá executar, porque o tempo de processamento das instruções de máquina é complexo demais para ser calculado com precisão nas máquinas modernas. Antigamente, você poderia saber que uma instrução ADD gastava 4 ciclos de máquina em um microprocessador 8086 e como ele rodava a 4,77 Mhz você saberia que o ADD gastava 4 * (1 / 4770000) segundos = 0,839 microssegundos. Mas hoje em dia isso não pode ser determinado tão simplesmente assim.
- Estou dizendo 0,002, mas obviamente esse tempo tem de ser determinado - é para isso que serve a experiência. Método científico, não é “tentativa e erro”, hein?
Qualquer experimentaçao só existe pq alguem usou alguma logica…
A tipica frase: Penso, logo, existo… Uma aula de filosofia eheheh
Enfim, se imaginarmos que num projeto de milhares de classes poderemos evitar uma instanciaçao e poucar memoria e GC ter que ser acionado, pq isso nao seria bem vindo as vezes! Imagina a economia que teriamos
A unica dúvida que fico: O Refactoring utiliza o mesmo processo de carga que um static ?
saudaçoes 
Você está confundindo “refactoring” com “reflection”.
A rigor, o processo de reflection (onde é que a tal “reflection” entrou na história?) é naturalmente um pouco lento (já que envolve obter métodos e classes por nome, em vez de usar suas referências já “prefabricadas”), mas foi devidamente acelerado pela JVM para se tornar útil, a partir do Java 1.4.
Leia um pouco sobre como a reflection foi acelerada pela JVM a partir do Java 1.4 - o processo é um bocado complexo, e envolve a criação de classes anônimas e temporárias pela JVM. Depois do almoço eu digo como é que a reflection é implementada.