Arquivo Discussoes de Programacao e Tecnologia Pessoal, vocês já repararam como cada vez mais estão levando o Java para o lado WEB ao invés de desktop?
Pode perceber, nas 3 últimas Java Magazine os assuntos de capas foram algo relacionado a WEB.
Para todas as pessoas que não conhecem Java, logo dizem: "Java é igual PHP (credo :x ) pra faze coisas para WEB né???
Precisamos mudar isso galera… Como podemos começar???
Forte Abraço a todos
Que tal listar os porques do “precisamos mudar isso”? A percepcao de que Java eh uma linguagem boa para aplicacoes Web nao esta errada na maioria dos casos 
Bem, eu só desenvolvo aplicações desktop em Java. E me desculpe quem diga que é lento, mas na minha opnião, 70% do motivo de ficar lento é a má programação. Todas minhas aplicações convertidas para Java ficaram mais leves e rapidas do que as originais em VB e Delphi.
Java para Desktop é excelente. Incrivelmente flexivel podendo criar qualquer tipo de componente e multiplataforma.
É claro que eu sinceramente gostaria que pudesse compilar, ficaria ainda mais rapido e o fonte continuaria multiplataforma. Pra mim o que importa é o fonte, não perde-lo mesmo que eu troque de SO como ja troquei anteriormente. Eu adorava Delphi até o .Net, hoje só uso Linux e adeus meus projetos em Delphi Se tivesse feito em Java ainda estaria com eles.
obs.: não to dizendo pra não usar Java pra Web! E sim para usar Java em tudo! 
Sim concordo completamente com você!!! 
Mas seria mais legal ainda se Java fosse consagrado também como “The Best” para desktop também certo???/
Forte Abraço…
Sim concordo completamente com você!!!Mas seria mais legal ainda se Java fosse consagrado também como “The Best” para desktop também certo???/
Forte Abraço…
Eu acho java o “the best” para desktop. 8)
A Paz!!
Eu acho java o “the best” para desktop. 8)
A Paz!!
Eu tb mas acho mas precisamos demonstrar isso a todos o VBzeros (quanto mais longe melhor)
Forte abraço…
Eu acho java o “the best” para desktop. 8)
A Paz!!
Eu tb mas acho mas precisamos demonstrar isso a todos o VBzeros (quanto mais longe melhor)
Forte abraço…
Cara pra falar para VBzeros é cruél pois eles estão acostumados com Wizards e tudo mais.
Tenho um colega VBzero que foi usar o Netbeans e achou “java ruim” pois ele “foi colocar um botão na janela e ele tomou o a janela inteira”…Eu mereço mesmo… :lol:
A Paz!!
Cara te dou completa razão… Como é difícil discutir sobre tecnologia com VBzero né…
Eu acho java o “the best” para desktop. 8)
A Paz!!
Eu tb mas acho mas precisamos demonstrar isso a todos o VBzeros (quanto mais longe melhor)
Forte abraço…
Precisamos é? Deixem que eles morram na escória das linguagens DnD…
O que é excitante em java é como vc desenvolve e não pra que vc desenvolve. Se vc escreve corretamente a sua lógica de negócio e não vincula ela a nada (nem a swing nem à componentes web), vc pode contruir o seu view como uma aplicação swing ou pra web.
Particularmente eu prefiro desenvolver pra desktop. Trabalho bastante com swing. Sobre ser lento, realmente é mais lento sim, não há dúvidas. Mas não é tão mais lento. Pra desenvolver eu uso o jEdit que é feito em java e é bem tranquilo de usar.
bom, eu acho que para mudar isso o pessoal tinha q começar a fazer freewares para desktop em java e divulga-los
O que é excitante em java é como vc desenvolve e não pra que vc desenvolve. Se vc escreve corretamente a sua lógica de negócio e não vincula ela a nada (nem a swing nem à componentes web), vc pode contruir o seu view como uma aplicação swing ou pra web.
Isso não está relacionado diretamente à Java.
A linguagem surgiu e se difundiu numa era onde as pessoas podem se preocupar mais coma rquitetura do que com contar bits, apenas está no lugar certo na hora certa. Você pdoe ter a mesma coisa com quase qualquer plataforma.
[]s
Eu estou há algum tempo pensando em uma coisa e acho que este é um bom momento para compartilhar com vocês.
O Portage, sistema de instalação de pacotes do Gentoo, é implementado em Python (linguagem script orientada a objetos). Alguns utilitários para o GoboLinux foram escritos em Ruby (outra linguagem script orientada a objetos).
Comecei, então, a “viajar”: como seria, por exemplo, um sistema de instalação de pacotes para Linux implementado em Java? Seria viável? (confesso que até comecei a brincar, tentando trazudir algumas rotinas no Portage para Java, mas desisti logo, pois o código é muito grande). Seria vantajoso? (uma vez que, em princípio, não usufruiríamos de uma importante característica do Java: ser multiplataforma).
Olá
Veja os instaladores do Oracle. São todos em Java e são bem bonitinhos com botões arredondados e tudo o mais.
[]s
Luca
Não, não acho que seria vantajoso. Ok, poderia ser legal virar para o mundo e dizer “Hey, Java também serve para instalador de sistema operacional. Hip Hip Hurra!”. Mas, ponto final.
Primeiro, porque reescrever algo que já funciona muito bem sem adicionar novo valor ao produto é como jogar dinheiro pela janela (se quiser, pode jogar na janela de casa).
Segundo, porque scripts se encaixam muito bem neste tipo de aplicação de automatização de tarefas. E, acredite, se uma rotina bem escrita em Ruby já estiver razoavelmente grande, é possível que esta mesma rotina fique monstruosa em Java. Groovy talvez ficasse legal, mas aí é preciso ver se a nova versão vai adicionar algum valor à versão antiga.
Terceiro, deixa a galerinha dos scripts se divertirem com alguma coisa útil huauhahuahua
para quem acha que java é lento para desktop:
http://www.portaljava.com/home/modules.php?name=Forums&file=viewtopic&t=13257
:shock:
Não analisei a fundo os códigos testados não, mas o teste parece bacana!
[]'s
Isso não está relacionado diretamente à Java.A linguagem surgiu e se difundiu numa era onde as pessoas podem se preocupar mais coma rquitetura do que com contar bits, apenas está no lugar certo na hora certa. Você pdoe ter a mesma coisa com quase qualquer plataforma.
[]s
É mesmo, vc tem razão. :shock:
Mas fala sério, fazer isso com Java é um tesão que poucas outras linguagens tem né? :twisted:
(ops!, só falei isso aqui, por que é um forum de java, hehehe)
Eu acho java o “the best” para desktop. 8)
A Paz!!
Eu tb mas acho mas precisamos demonstrar isso a todos o VBzeros (quanto mais longe melhor)
Forte abraço…
Falando em VBzeros eu acho muito interessante quando alguém que programa a X anos em VB ou Delphi (eu não to falando mal, eu vim do Delphi e foi assim comigo) e de repente falam:
Olha, montar telas é legal, mas não tem como otimizar isso não? Vou ter que ficar fazendo como se fosse html? (Essa segunda eu ouvi essa semana, doeu o ouvido)
Mas tá valendo… acho que existem linguagens e linguagens e também pessoas e pessoas.
O importante não é saber java. O importante é saber programar. (Assembler não vale 8) )
Eu programo em Cobol no meu trampo e no início eu tinha o pé atrás. Aprendi muito em conceitos de indexação de arquivos e tudo mais… Cobol Rules! E tem outra: Tá pagando o meu pão…
O importante é estar satisfeito com a linguagem que trabalha. De assembler a java, seja qual for.
Ps.: Me confirmem essa. É verdade que na NASA só programam em Assembler? Dizem que é confiável, e tals…
Ps2.: Como diz o Daniel Destro: “Java sim, mas sem ser piégas”
Ps3.: Mas que é um Tesão é mesmo…
Ps4.: Sem mais ps.
bom, o robozinho que ta em marte é programado em java!
Ps.: Me confirmem essa. É verdade que na NASA só programam em Assembler? Dizem que é confiável, e tals…
É mentira! Posso afirmar com toda segurança do mundo, apesar de estar muito distante de conhecer os processos de desenvolvimento de software da NASA. Segue:
i) Assembly não é uma linguagem de programação;
ii) Assembly é uma linguagem de montagem (lembra das suas aulas de SW Básico? o compilador que vc implementou deveria gerar código de montagem…);
iii) Assembly não é produtivo e é impossivel implementar um simulador de um onibus espacial usando só assembly! [o nível de abstração é muito baixo];
iv) Logo, a NASA usa várias tecnologias e desenvolve tecnologias também;
para quem acha que java é lento para desktop:
http://www.portaljava.com/home/modules.php?name=Forums&file=viewtopic&t=13257
Sobre este mini-benchmark, eu resolvi encarar o desafio e implementar o teste Java vs. C# (insônia, tédio e cafeína resultam nestas coisas).
Aí vão os códigos (a versão Java é cópia ipsis-literis da versão original publicada no PortalJava, url acima).
//Java
public class QuicksortTest {
private static final int SIZE = 1000000;
public static void main(String[] args) {
int array[] = new int[SIZE];
long beginFill = System.currentTimeMillis();
for (int i = 0; i < SIZE; i++) {
array[i] = i % 100;
}
long endFill = System.currentTimeMillis();
long beginSort = System.currentTimeMillis();
quicksort(0, SIZE - 1, array);
long endSort = System.currentTimeMillis();
System.out.println("Preenchimento de array: "+(endFill - beginFill)+" ms");
System.out.println("Ordenação de array: "+(endSort - beginSort)+" ms");
}
public static void quicksort(int p, int q, int array[]) {
if (p < q) {
int j = p - 1;
int aux = array[q];
for (int i = p; i <= q; i++) {
if (array[i] <= aux) {
int taux = array[i];
array[i] = array[++j];
array[j] = taux;
}
}
quicksort(p, j - 1, array);
quicksort(j + 1, q, array);
}
}
}
//C#
using System;
namespace GUJ
{
class Quicksort
{
private const int SIZE = 1000000;
[STAThread]
static void Main(string[] args)
{
int[] array = new int[SIZE];
DateTime beginFill = DateTime.Now;
for (int i = 0; i < SIZE; i++){
array[i] = i % 100;
}
DateTime endFill = DateTime.Now;
DateTime beginSort = DateTime.Now;
quicksort(0, SIZE - 1, array);
DateTime endSort = DateTime.Now;
Console.WriteLine("Preenchimento: {0}", endFill.Subtract(beginFill));
Console.WriteLine("Ordenação: {0}", endSort.Subtract(beginSort));
Console.ReadLine();
}
public static void quicksort(int p, int q, int[] array)
{
if (p < q)
{
int j = p - 1;
int aux = array[q];
for (int i = p; i <= q; i++)
{
if (array[i] <= aux)
{
int taux = array[i];
array[i] = array[++j];
array[j] = taux;
}
}
quicksort(p, j - 1, array);
quicksort(j + 1, q, array);
}
}
}
}
Usando tanto Sun JVM 1.4.2_06 e 1.5.0, o código na versão Java lançou um StackOverflowError e não executou. O mesmo para a versão C# executada sobre o .NET Framework versões 1.0.37 e 1.1.24.
Agora, já que eu não estava tãooooooo disposto assim para consertar o quicksort do colega Felipe, resolvi brincar de avaliar qual API implementa um mecanismo de ordenação de arrays mais decente.
Para tanto, eu usei a classe java.util.Arrays, para o exemplo usando Java e a classe System.Array para o exemplo usando C#. Os códigos:
//Java
import java.util.Arrays;
public class ArraySortingTest {
private final static int SIZE = 1000000;
public static void main(String[] args) {
int array[] = new int[SIZE];
long beginFill = System.currentTimeMillis();
for (int i = 0; i < SIZE; i++) {
array[i] = i % 100;
}
long endFill = System.currentTimeMillis();
long beginSort = System.currentTimeMillis();
Arrays.sort(array);
long endSort = System.currentTimeMillis();
System.out.println("Preenchimento de array: "+(endFill - beginFill)+" ms");
System.out.println("Ordenação de array: "+(endSort - beginSort)+" ms");
}
}
//C#
using System;
namespace GUJ
{
class ArraySorting
{
private const int SIZE = 1000000;
[STAThread]
static void Main(string[] args)
{
int[] array = new int[SIZE];
DateTime beginFill = DateTime.Now;
for (int i = 0; i < SIZE; i++){
array[i] = i % 100;
}
DateTime endFill = DateTime.Now;
DateTime beginSort = DateTime.Now;
Array.Sort(array);
DateTime endSort = DateTime.Now;
Console.WriteLine("Preenchimento: {0}", endFill.Subtract(beginFill));
Console.WriteLine("Ordenação: {0}", endSort.Subtract(beginSort));
Console.ReadLine();
}
}
}
Resultados foram:
:arrow: JVM 1.4.2 (Client): Preenchimento = 50ms | Ordenação = 150ms
:arrow: JVM 1.4.2 (Server): Preenchimento = 30ms | Ordenação = 210ms
:arrow: JVM 1.5.0 (Client): Preenchimento = 40ms | Ordenação = 130ms
:arrow: JVM 1.5.0 (Server): Preenchimento = 20ms | Ordenação = 195ms
:arrow: .NET Framework 1.0: Preenchimento = 40ms | Ordenação = 320ms
:arrow: .NET Framework 1.1: Preenchimento = 50ms | Ordenação = 280ms
Tirem suas conclusões.
(Ambiente de execução: Athlon XP 2800+, 512Mb Ram, Windows XP SP2)
P.S.: Desconsiderei o startup-time, pois:
Tirem suas conclusões.(Ambiente de execução: Athlon XP 2800+, 512Mb Ram, Windows XP SP2)
Conclusao: maquina bacana. Parabens. :mrgreen:
Achei interessante que a VM Server eh mais rapida no preenchimento dos dados porem mais lenta na ordenacao.
Qual a diferenca entre ambas?
Marcio Kuchma
Achei interessante que a VM Server eh mais rapida no preenchimento dos dados porem mais lenta na ordenacao.Qual a diferenca entre ambas?
Tava aqui me perguntando a mesma coisa…
E se jogassemos o Pascalzão no combate??? Qual seria a situação?
Se eu tiver disposto de noite faço esse teste.
Chega de microbenchmarks, pelo amor de deus :evil:
Daqui a pouco vem alguem e diz “ah, mas eu faco isso rodar muuuuuuuuuito mais rapido usando C”. Aih outro vem e diz que nao, Java eh mais rapido. Ai vem outro com uma CFLAGS de meio quilometro. Ai vem outro com a mesma coisa em pascal. Ai vem outro com assembly. Ai vem outro com uma modelo pelada rebolando. Ai vem o Faustao, e depois o Gugu, e a gente acabou com a civilizacao e nem percebeu. PAREM.
Essa não deixa de ser uma má idéia. Agora há daquele que deixar essa discussão cair nos ouvidos do Gugu ou do Faustão…
Falando sério, acho que estes testes são muito imparciais. Não dá pra avaliar a performance de uma linguagem apenas com um cálculo gingantesco dentro de um loop se reptindo várias vezes. As linguagens vão ter pontos onde sua performance será otimizada e outras em que haverá deficiências. Corrijam-me caso esteja errado, mas JAVA, por exemplo, por ter tipos primitivos, a priori, vai ser mais performatica nos cálculos do que uma linguagem completamente OO onde um integer vai ser um objeto, e por aí vai… esses testes são legais pra ficar brincando em casa, mas nada que vá te fazer escolher uma linguagem à outra…
Gustavo Guilherme BacK
Essa não deixa de ser uma má idéia.…
Falando sério, acho que estes testes são muito imparciais.
:?: :?: :?: :?: :?: :?: :?: :?: :?:
tendi xongas :roll:
[]s
Back, linguagens nao tem performance, pq linguagens nao executam, rodam ou sao mensuraveis no espaco de tempo de nenhuma maneira interessante. Os interpretadores, sim
:oops: Ops! Verdade, mas quando se vai avaliar a performance, como nesse caso, quase sempre se vincula com a linguagem, mas como você disse não é isso que vai fazer diferença na execução de um teste. Fiz confusão…
Gustavo Guilherme BacK
Achei interessante que a VM Server eh mais rapida no preenchimento dos dados porem mais lenta na ordenacao.Qual a diferenca entre ambas?
Tava aqui me perguntando a mesma coisa…
A VM Server é mais rápida para preenchimento porque, se vocês repararem a forma como o array é preenchido (em um loop)é possível de se otimizar e fazer as demais bizarrices que o Hotspot faz para ganhar desempenho.
Agora, não faço a menor idéia do porquê ela é mais lenta para ordenação. Talvez ela tenha perdido tempo demais tentando otimizar antes de executar, coisa que a Client VM não faz (tanto assim).
Mas, basicamente (e a grosso modo), a Client VM é ajustada para oferecer um desempenho médio, mas com um leve consumo de memória, enquanto a Server VM vai procurar fazer de tudo o que for possivel para obter o melhor desempenho e gastar a memória que puder para isso. E é por isso que a Server VM perde no micro-benchmark-de-fundo-de-quintal-do-Daniel®, pois a aplicação não dura tempo o bastante para a VM conseguir recuperar, a longo prazo, o tempo que ela perdeu otimizando as “paradinhas”. O louds pode explicar estas coisas melhor do que eu. LOOOUUUUDSS!!
Mas, concordo com o CV. Estes mini-benchmarks de fundo de quintal (como o que eu fiz) não costumam provar nada. Mas foi um bom passa-tempo até eu conseguir pegar no sono
Tá, desculpa minha ignorancia, mas como que executa a Server VM e como executar a Cliente VM:?:
Essa história de Server e Client VM são novas pra mim. Nunca tinha tomado conhecimento disso.
eita … execute só java pra ver as opcoes … tem -server e -client no meio delas.
Olá
Discordo completamente. Gostei muito do seu teste e foi muito elucidativo, dos melhores que já vi. Parabéns!
E ainda achei excelente o fato de você ter comparado usando também a opção -server. A JVM como padrão é otimizada para inicialização rápida e pouco gasto de memória. Com a opção -server se pode obter execuções mais rápidas as custas de um tempo maior na inicialização do sistema. E o que você falou está correto.
[]s
Luca
Luca, a parte fundo-de-quintal do teste do Daniel foi que a performance demonstrada ali nao reflete o que acontece de verdade em um sistema (ja que, em um sistema minimamente util, a VM tem que se preocupar com mais classes, IO, metodos maiores que nao sao tao hostpoteaveis assim, e por ai vai).
Mas foi legal pra demonstrar essas caracteristicas da VM Client e Server, e as diferencas entre as duas, nisso eu concordo com vc
Concordo e também discordo.
Assembly não é linguagem de programação - OK
Eu acho que em aula de SW básico ninguém consegue montar um compilador, consegue??? Vai falar em Lex e Yacc no início… espanta todo mundo. Eu vi isso no quarto ano, nas aulas de Compiladores (lex e yacc pra não sacrificar e fazer tudo na mão)
Assembly não é produtivo = OK
Impossível implementar um simulador de um onibus espacial usando só assembly! [o nível de abstração é muito baixo]; Não concordo.
A NASA tem grana :$: e assim pode pagar qq programador que entenda bem de assembly pra fazer o que quiser, inclusive levitar. 8)
Pelo fato de ser baixissimo nivel tudo bem, mas que consegue consegue.
(não estou avaliando aqui se gasta tempo ou não)
Se construir em assembly fica confiável, não fica?
iv) Logo, a NASA usa várias tecnologias e desenvolve tecnologias também; == Penso logo existo
Legal esse assunto. Particularmente também não acho que seja utilizado só assembly lá, mas pq não né? Não podemos afirmar com tanta certeza sobre algo que não conhecemos.
[]'s
Luca, a parte fundo-de-quintal do teste do Daniel foi que a performance demonstrada ali nao reflete o que acontece de verdade em um sistema (ja que, em um sistema minimamente util, a VM tem que se preocupar com mais classes, IO, metodos maiores que nao sao tao hostpoteaveis assim, e por ai vai).Mas foi legal pra demonstrar essas caracteristicas da VM Client e Server, e as diferencas entre as duas, nisso eu concordo com vc :)
Exato. Eis um bom passatempo para benchmark “nem-tão-fundo-de-quintal-assim”: testes de performance de serialização de objetos, IO, Threading, método numéricos… Vamos nos tornar o próximo Gartner
Não, não acho que seria vantajoso. Ok, poderia ser legal virar para o mundo e dizer “Hey, Java também serve para instalador de sistema operacional. Hip Hip Hurra!”. Mas, ponto final.Primeiro, porque reescrever algo que já funciona muito bem sem adicionar novo valor ao produto é como jogar dinheiro pela janela (se quiser, pode jogar na janela de casa).
Segundo, porque scripts se encaixam muito bem neste tipo de aplicação de automatização de tarefas. E, acredite, se uma rotina bem escrita em Ruby já estiver razoavelmente grande, é possível que esta mesma rotina fique monstruosa em Java. Groovy talvez ficasse legal, mas aí é preciso ver se a nova versão vai adicionar algum valor à versão antiga.
Terceiro, deixa a galerinha dos scripts se divertirem com alguma coisa útil
Eu já tenho um certo tempo de uso de certas ferramentas para instalar pacotes (tipicamente, APT e Portage). Uma situação que eu vivo sempre e que, na qual, nenhuma destas ferramentas me deixa contente, é quando eu vou instalar vários pacotes de uma só vez.
O apt-get (APT) primeiramente faz o download de todos os pacotes para só depois começar a instalação. O emerge (Portage), diferentemente, baixa e instala um pacote por vez e só procede ao download do próximo pacote quando a instalação do pacote atual for concluída. Ambas as ferramentas, a meu ver, acabam levando um tempo excessivamente longo para instalar todos os pacotes, sendo que o Portage, além disso, acaba disperdiçando meu tempo de conexão com a Internet (o que, para um usuário de accesso discado à Internet como eu, é muito ruim).
Imaginemos agora que eu estou tentando instalar dois ou mais pacotes, sendo que um não dependa dos outros. O meu maior sonho é encontrar uma ferramenta para instalação de pacotes que me permita, neste caso, proceder ao download dos próximos pacotes enquanto faz a instalação do pacote atual. Sem dúvida, isto me economizaria tempo, tanto de instalação, quanto de conexão com a Internet.
Com algum esforço, eu consigo fazer isto hoje, mais ou menos, com o Portage. Na sua versão atual, o Portage utiliza arquivos de bloqueio para previnir que, por exemplo, duas execuções do emerge tentem fazer o download do mesmo arquivo ou desinstalar o mesmo pacote (até o presente momento, não há nada que as previna de tentar compilar o mesmo programa). Eu posso, por exemplo, abrir dois terminais e executar emerge --fetchonly <pacote1> <pacote2> …, no terminal 1, e emerge <pacote1> <pacote2> …, no terminal 2 (com o APT, isto não seria possível, mesmo porque ele não permite a execução do apt-get em múltiplos processos). Assim, o processo rodando no terminal 2 (instalação do pacote atual) vai aguardar pela liberação dos bloqueios criados pelo processo rodando no terminal 1 (download do pacote atual). Em suma, o processo no terminal 2 vai instalando os pacotes enquanto o processo no terminal 1 vai fazendo o download dos pacotes restantes.
Bom seria se eu pudesse fazer tudo isso sem precisar abrir vários terminais… Além disso, quem possui uma máquina mais potente pode querer compilar mais de um programa simultaneamente, usuários de banda larga podem querer fazer o download de vários pacotes simultaneamente (coisa que, altualmente, o Portage não permite), e por aí vai.
Pois bem. Eu imagino que uma ferramenta para instalação de pacotes poderia prover soluções para estes casos utilizando processamento concorrente (multi-threading). Então eu pergunto novamente: Isto seria possível? Viável? Vantajoso? E, se for vantajoso, seria mais vantajoso utilizando Java ou alguma outra linguagem que suporte multi-threading?
Desculpem-me se eu estiver falando bobagem, pois eu conheço muito pouco sobre processamento concorrente e sobre quais linguagens suportam-no atualmente.
Olá
Há uma restrição adicional que é a interdependência dos pacotes. Quando um pacotes depende de vários outros, o instalador precisaria ser inteligente o bastante para perceber isto e ir baixando e instalando na ordem certa. Não tenho a menor idéia sobre como esta informação poderia chegar ao instalador.
[]s
Luca
Daniel.
Uma JVM moderna, como a Jikes RVM ou a HotSpot 1.5, funciona de forma adaptativa visando maximizar a performance do programa sendo executado. Isso pode ter significados diferentes dependendo do tempo total da aplicação.
Podemos dizer que uma JVM quer minimizar a seguinte fórmula:
Hoje o tr não afeta muito as decisões da JVM então podemos pensar nele como constante.
A client jvm assume que te não vai ser grande, então não é bom perder muito tempo compilando. Se o código ficar duas vezes mais lento mas você tiver salvo 100x em tempo de compilação (sim, pode chegar a proporções dessa grandesa) a client jvm vai estar contribuindo em diminuir o tempo total de execução.
Já a server jvm imagina que o programa vai rodar por um longo período de tempo, então gastar mais tempo fazendo profiling, especulando e compilando vai resultar em um total menor de tempo de compilação.
Moral da historia, jvms adaptativas são uma droga para se fazer benchmark por que os resultados vão ser sempre questionaveis e meio duvidosos.
A forma mais usual de se resolver isso é primeiro fazer algumas rodadas de aquecimento com a JVM antes de rodar o teste para valer. Isso com -Xbatch, para desligar background compilation.
A explicação mais obvia da performance ruim da server JVM é que ela se propos a fazer otimizações mais agressivas no código e isso resultou em um tempo total pior que o da client JVM.
Quando ao teste em C postado no outro forum, falho, inocente. Não fala dos parâmetros usados com a jvm e o compilador C, tão pouco das versões. O gcc em modo normal (para debug) gera código muito lerdo.
OláHá uma restrição adicional que é a interdependência dos pacotes. Quando um pacotes depende de vários outros, o instalador precisaria ser inteligente o bastante para perceber isto e ir baixando e instalando na ordem certa. Não tenho a menor idéia sobre como esta informação poderia chegar ao instalador.
[]s
Luca
Não queria chegar nas dependências ainda (mesmo porque acho que esta minha discussão dentro deste tópico não vai se estender muito), mas já que você tocou no assunto…
Acho que faltou dizer que eu estou pensando no modelo utilizado por alguns novos sistemas de instalação de pacotes, sobretudo os baseados em instalação a partir do código-fonte: um conjunto de shell scripts individuais com informações específicas para cada pacote (suas dependências, endereços para download dos arquivos, comandos necessários para a instalação/desinstalação, etc.) e um programa central que faça o trabalho duro (resolução de dependências, gerenciamento dos downloads, etc.). O programa central obteria as informações necessárias a partir dos scripts, calcularia as dependências, faria o download dos arquivos e, ao proceder com a instalação, invocaria os scripts, deixando que estes se encarreguem de executar os comandos necessários junto ao SO.
Quando eu questiono a viabilidade/vantagem (na verdade, estou mais preocupado com a viabilidade do que com as vantagens) de se implementar um instalador em Java, é a este programa central que eu me refiro.
Está mais claro, agora?
Todo sistema de instalação de software supoe que exista um DAG de dependencia entre os pacotes. Este grafo todos os vértices possuem cores, uma para instalado e outra para não instalado.
Para saber quais pacotes, e qual ordem seguir, ao instalar o pacote P, o sw deve calcular no grafo a árvore com raiz em P com os pacotes não instalados. O passo seguinte é o de instalação, que funciona da seguinte forma:
Simples assim.
Eu nunca vi uma descricao tao complicada pra algo tao simples… talvez eu nao esteja lendo livros teoricos o suficiente :mrgreen:
Pessoal, vocês já repararam como cada vez mais estão levando o Java para o lado WEB ao invés de desktop?
Pode perceber, nas 3 últimas Java Magazine os assuntos de capas foram algo relacionado a WEB.
Para todas as pessoas que não conhecem Java, logo dizem: "Java é igual PHP (credo :x ) pra faze coisas para WEB né???Precisamos mudar isso galera… Como podemos começar???
Forte Abraço a todos
Começando a tirar estes .java ridiculos das URLs do forum que todo mundo sabe que é em PHP. Ou admite que é PHP ou muda pra java.
Que tal JavaBB ?
http://info.abril.com.br/professional/desenvolvimento/uol-troca-phpbb-pelo-javabb.shtml
Desculpem o mau jeito, mas esses .java estavam me irritando, e agora eu explodi… Não consigo imaginar um forum serio e respeitado de java como este renomeando .php por .java pra nao ser zuado.
abraços a todos e mais uma vez perdoe a franqueza
Cara, esse papo de que java é lento é coisa antiga…
Hoje em dia existem diversos produtos desktop em java que rodam muito bem e apresentam boa performance
Era lento sim, o netbeans por exemplo
quando eu rodava no meu k6-II 500 em 2002
Cara, esse papo de que java é lento é coisa antiga…
Hoje em dia existem diversos produtos desktop em java que rodam muito bem e apresentam boa performanceEra lento sim, o netbeans por exemplo
quando eu rodava no meu k6-II 500 em 2002
Até mesmo em máquinas menos parrudas. experimenta remover uma pá de plugins desnecessarios que ele fica levin levin.
Sobre a lentidão de Java, tem esse artigo pra ler.
O melhor toolkit gráfico que eu conheço é o Swing. Sinceramente, é a melhor plataforma que conheço para se programar aplicações desktop (tente programar usando MFC que você vai entender nítidamente o que estou dizendo).
As queixas que já vi relacionadas à lentidão normalmente se devia ou a má programação ou a códigos que realmente eram pesados. No entanto, há outras alternativas também, como por exemplo o SWT, que é nativo.
No caso do SWT, no entanto, ele só iria comprovar a própria incompetência do reclamante, pois seria código nativo, sendo executado como interface para código java,que geraria código igualmente lento.
Cara pra falar para VBzeros é cruél pois eles estão acostumados com Wizards e tudo mais.
Tenho um colega VBzero que foi usar o Netbeans e achou “java ruim” pois ele “foi colocar um botão na janela e ele tomou o a janela inteira”…Eu mereço mesmo… :lol:
A Paz!!
Já trabalhei com pessoas fanáticas pela M$ e é muito complicado convercê-las de que Java é uma ótima linguagem
Alegam que o “arrastar e soltar” é fantástico… :lol:
As pessoas ficam tão mal acostumadas que quando eu perguntava sobre o código
falavam : “Ahh, nem sei, eu arrastei e ficou assim”…
Deve ser maravilhoso quando dá um bug, se mal entendem o código, imagina como iriam achar o erro ? :lol:
Não abro mão, Java é Java…Java é a melhor linguagem na minha opinião…
Abraços
Eu acho Java pra desktop razoável. Não acho “The Best”.
Pessoal, vocês já repararam como cada vez mais estão levando o Java para o lado WEB ao invés de desktop?
Pode perceber, nas 3 últimas Java Magazine os assuntos de capas foram algo relacionado a WEB.
Para todas as pessoas que não conhecem Java, logo dizem: "Java é igual PHP (credo :x ) pra faze coisas para WEB né???Precisamos mudar isso galera… Como podemos começar???
Forte Abraço a todos
Começando a tirar estes .java ridiculos das URLs do forum que todo mundo sabe que é em PHP. Ou admite que é PHP ou muda pra java.
Que tal JavaBB ?
http://info.abril.com.br/professional/desenvolvimento/uol-troca-phpbb-pelo-javabb.shtml
Desculpem o mau jeito, mas esses .java estavam me irritando, e agora eu explodi… Não consigo imaginar um forum serio e respeitado de java como este renomeando .php por .java pra nao ser zuado.
abraços a todos e mais uma vez perdoe a franqueza
PHP? GUJ em PHP? :shock:
Desculpe-me mas desta vez não da pra deixar passar batido. Da uma olhada no rodapé da página e leia a parte onde diz Powered by JForum. Acho melhor você se informar amigo.
"
o_O
"
Começando a tirar estes .java ridiculos das URLs do forum que todo mundo sabe que é em PHP. Ou admite que é PHP ou muda pra java.Que tal JavaBB ?
http://info.abril.com.br/professional/desenvolvimento/uol-troca-phpbb-pelo-javabb.shtml
http://info.abril.com.br/professional/desenvolvimento/forum-do-uol-games-escorrega-c.shtml
Essa foi a coisa mais engraçada que eu já vi na vida. Não sei exatamente o que aconteceu, porque ambas as partes, o UOL e o desenvolvedor do JavaBB, não explicaram. Mas tudo deu errado. Em primeiro lugar o JavaBB não agüentou o tranco, e isso pode ser por várias razões além do código em si. Em segundo lugar é bem pobre de recursos. E por último o negócio é bugado!
A seqüência de acontecimentos foi realmente cômica. O UOL trocou o PHPBB pelo JavaBB e deram uma reportagem à Info dizendo que era um sucesso e o pior, o criador apareceu em uma foto dizendo que “Java é seguro, estável e de fácil manutenção”. O problema é o fórum tem vários problemas, como por exemplo você conseguir logar com a conta de outra pessoa. Depois alguém encontrou ele em um blog se gabando do seu trabalho… Pronto, era o que faltava para transformá-lo em Judas.
Nossa cara, pegaram a foto do cara e zoaram muito. Fizeram várias montagens com ele dizendo “Java é seguro, estável e de fácil manutenção”. Dá uma olhada lá nas threads, ele já é lenda na internet.
Coitado do cara, nem sei se a culpa é dele e provavelmente ele não foi o único desenvolvedor a trabalhar nisso, mas nunca ri tanto na minha vida sobre posts em um forum da internet. Existe uma thread lá só com montagens de fotos com ele (pegaram até foto do Orkut dele) e da última vez que eu vi estava com 20 e poucas páginas.
O pessoal da equipe do UOL também deve estar desejando o mal do cara, porque não tiraram nenhuma das fotos e nem sequer editaram nada. Acho que eles querem jogar a culpa no profissional e tirar o c* da chefia do UOL da reta.
EDIT: a julgar pela quantidade de reclamações dos usuários de lá sobre recursos que estão faltando, o PHPBB tem muitos fãs na internet.