Java para desktop é perda de tempo?

Assuntos Gerais
#41

[quote=ViniGodoy]
Uma das coisas mais básicas em Desktop é também pegar o caminho onde a aplicação roda. Isso é trivial em várias linguagens, como C++ ou C#, mas é virtualmente impossível em Java.[/quote]

Impossivel ?

File file = new File(".");

isto é equivalente a

File file = new File( System.getProperties("user.dir") + ".");

O user.dir indica de onde o executável java foi invocado. ( não confundir com user.home)

SecurityManager ? Ora, nem no servidor o povo usa isso… mas mesmo que use, é para isso que servem os arquivos de permissões.

A verdade é que não existe nenhuma razão para não usar java. Todos os pontos que vcs falaram são circunstanciais. Por exemplo, o fato de cada applicação rodar a sua JVM, é algo que é verdade hoje, mas não será verdade no futuro (existe previsão para o java 9 se não me engano).

#42

[quote=luzales]
Concordo plenamente e reforço o argumento. Oras, por que não usar Java e JavaFx, por exemplo? Por que o preconceito contra o Java no desktop? Para a interface JavaFX está show de bola e representa uma evolução enorme em relação ao Swing. Além disso, estudando a plataforma Java vc abre caminho para desenvolver tanto em desktop, quanto mobile e web com qualidade e robustez.
Esse argumento que o desktop está morto pra mim é bobagem. A maioria dos sistemas comerciais vendidos prontos são para desktop. Verifique o software da sua loja preferida no comércio e veja se é em desktop ou web. Verifique o software dos caixas de supermercado, por exemplo, e veja. Com certeza a esmagadora maioria será um software desktop.[/quote]

é verdade! a maioria são desktop. mas são java?

#43

[quote=sergiotaborda][quote=ViniGodoy]
Uma das coisas mais básicas em Desktop é também pegar o caminho onde a aplicação roda. Isso é trivial em várias linguagens, como C++ ou C#, mas é virtualmente impossível em Java.[/quote]

Impossivel ?

File file = new File(".");

isto é equivalente a

File file = new File( System.getProperties("user.dir") + ".");

[/quote]

creio q o viny tava dizendo: “de onde foi executado o jar”;

e isso ai pode parecer ser, mas não é.

exemplo:

File file = new File(".");
System.out.println(file.getAbsolutePath());

System.setProperty( “user.dir”, “/teste/” );
System.out.println(file.getAbsolutePath());

saída:
D:\Java\Projetos\Testes.
\teste.

o jar será q mudou de lugar?
ou seja, ta se baseando no property “user.dir”, e não na localização do jar.

#44

esse aki parece q funciona:

ClassLoader.getSystemClassLoader().getResource(".").getPath();

teria q testar.

#45

Isso retorna o diretório de execução, que pode ser configurado no atalho do aplicativo, e que é diferente do diretório onde a aplicação está.

Isso retorna a User Folder, que é onde está a pasta “Meus documentos”.
E também é diferente do local onde o .jar está.

Algumas formas, como essa, quebram o galho, mas não tem formato de retorno consistente, nem funcionamento garantido em multiplataforma (o que é garantido é que irá retornar a raiz do seu class loader, não que isso necessariamente virá acompanhado do diretório onde o .jar está).

O que estou argumentando é que não existe um comando na plataforma que retorne essa informação. Se você vai fazer aplicações sérias, não pode se basear em comandos que “parece que funcionam”. Tem que ter um comando oficial, que a Oracle diga que tem faça o que você quer que faça.

Novamente, apela-se para a solução Eclipse. Cria-se um .exe que dispara sua aplicação com as opções certas da VM e, aproveitando o ensejo, já passe essa informação para o seu .jar. Entretanto, isso é um workaround para driblar uma deficiência que em outras plataformas você sequer teria.

#46

PS: Eu não estou falando que seja ruim fazer aplicações corporativas Desktop em Java. Boa parte das aplicações não precisam do que falei. Se você for fazer seu sistema de controle de pizzaria®, então, pode usar Java tranquilo.

Ah! Acabei de lembrar de outros recursos em que o Java é capenga. Ele tem péssima integração com periféricos: Scanners, portas USB, porta serial/paralela, webcams ou controladores de jogo.

#47

[quote=ViniGodoy]Não acho que afirmar que Java é ruim para desktop baseia em pré-conceito. Sem falar no Swing ser ou não fácil/produtivo, eu poderia citar os seguintes motivos:

Em primeiro lugar, é difícil fazer o deploy de uma aplicação Java desktop. Você tem que garantir que o sistema alvo tenha uma VM configurada corretamente. Na hora de rodar uma aplicação Java, você normalmente tem que passar parâmetros para a VM (tal como o -XMX ou -XMS) e isso não pode ser feito de forma conveniente, dentro do .jar, por exemplo. Finalmente, é complicado criar atalhos para o .jar (normalmente você vai ter que criar um arquivo de lote, e associar o atalho a ele, para ele disparar o .jar).

Você pode resolver isso com um instalador, duplicando a VM na máquina do usuário e, usando a estratégia do Eclipse, criando um executável para disparar sua aplicação Java (no lugar do arquivo de lote).

Uma das coisas mais básicas em Desktop é também pegar o caminho onde a aplicação está localizada. Isso é trivial em várias linguagens, como C++ ou C#, mas é virtualmente impossível em Java. Especialmente se levar em conta detalhes como as restrições do Security Manager.

O java não tem qualquer integração com o UAC ou qualquer outro recurso mais específico
do SO (Active Directory, OpenGL, DirectX, Direct2D, AviCap, etc). Só nas últimas versões foi possível marcar um arquivo criado como “executável” no Linux, por exemplo. Em C#, você pode solicitar o UAC por um arquivo manifesto. Em C++, isso é feito usando uma opção na compilação. Você até pode apelar para JNI e JNA, mas isso não é fácil e nem conveniente (bem diferente dos unsafe methods do C#).[/quote]

Dá uma olhada no JavaFX. esses problemas que você apontou são reais e o pessoal da equipe de JavaFX está tentando limpar tudo isso.

Olha o FAQ do JavaFX:

Então, em breve Java Desktop será JavaFX.

Sobre os problemas de instalação, isso acaba em breve:

https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx

Mas outras coisas nativas ainda continuam complicadas e acredito que isso não muda tão cedo.

#48

Gosto muito de java pra desktop, mas o meu preconceito com ele é a descompilação da aplicação final . O que tornar inviável o desenvolvimento desktop na minha concepção.[/quote]

esse é só um dos problemas… outros dois que também teriam são, primeiro que a api padrão de desktop, o swing é meio ruimzinho, os gerenciadores de layout são bem ruimzinhos de se trabalhar, em contrapartida também o mercado não usa muito, o investimento também não é tão alto quanto em outras partes como jee por exemplo…[/quote]

Não vejo isso como problema… basta compilar o Java para nativo… se realmente tiver essa necessidade.

Já usei este cara aqui, mas é pago:
http://www.excelsior-usa.com/jet.html

A diferença no carregamento da aplicação é a principal, entretanto não vi diferença de performance rodando os .jar e os executaveis em maquinas com mais de 1 nucleo…

Tem alguns casos que nem a diferença compensa… as vezes cai de 3 segundos para 1 segundo… 3 segundos para carregar a aplicação dependendo do tipo é irrelevante…

Tem alguns apps comerciais que usam esse cara…

[/quote]

O excelsior só vai otimizar o programa e não reduzir suas dependências. No final ele tem que embutir no executável a máquina virtual. Java é pesado porque tem muitas dependências. Quando digo “pesado” não quer dizer “lento”.

#49

Gosto muito de java pra desktop, mas o meu preconceito com ele é a descompilação da aplicação final . O que tornar inviável o desenvolvimento desktop na minha concepção.[/quote]

esse é só um dos problemas… outros dois que também teriam são, primeiro que a api padrão de desktop, o swing é meio ruimzinho, os gerenciadores de layout são bem ruimzinhos de se trabalhar, em contrapartida também o mercado não usa muito, o investimento também não é tão alto quanto em outras partes como jee por exemplo…[/quote]

Não vejo isso como problema… basta compilar o Java para nativo… se realmente tiver essa necessidade.

Já usei este cara aqui, mas é pago:
http://www.excelsior-usa.com/jet.html

A diferença no carregamento da aplicação é a principal, entretanto não vi diferença de performance rodando os .jar e os executaveis em maquinas com mais de 1 nucleo…

Tem alguns casos que nem a diferença compensa… as vezes cai de 3 segundos para 1 segundo… 3 segundos para carregar a aplicação dependendo do tipo é irrelevante…

Tem alguns apps comerciais que usam esse cara…

[/quote]

O excelsior só vai otimizar o programa e não reduzir suas dependências. No final ele tem que embutir no executável a máquina virtual. Java é pesado porque tem muitas dependências. Quando digo “pesado” não quer dizer “lento”.[/quote]

ah sim… mas pesado em tamanho… agora nos dias de hoje… algo em torno de 50mb é realmente pesado ???

Volto na questão… tudo depende do que você vai fazer… tem casos que Java realmente não é uma boa escolha… mas tem muitos casos onde Java Desktop é sim uma ótima pedida!

#50

Será que vc sabe o que está fazendo ? Quem de posse das sua faculdades mentais iria querer mudar um system property ?
É pedir para ter problemas, e é isso exactamente que vc tem se tentar. Agora, vamos voltar ao assunto. Ele retornou “D:\Java\Projetos\Testes” quando vc leu a propriedade. Isso significa que ele sabe de onde foi iniciado e não, não é Meus Documentos (isso é o user.home)

do javadoc de File

Isto é muito util em programas de linha de comandos como o mvn do maven.
Sim, não diz onde está instalado o maven para é para isso que servem as configurações. No caso do maven e do ant e outros é preciso configurar o home. Isto porque eu posso querer mudar de versão conforme o projeto. Seria melhor que o java tivesse um caminho da instalação ? seria, mas ninguem tem isso. O caminho da instalação , como o nome indica, é criado durante a instalação. A instalação de um sistema desktop - quando bem feita - ou usa un instalador igual aos usados pelas outras plataformas, ou usa jws. Ou seja, alguem tém que escreve no maldito do registro do OS. E feito isso vc simplesmente usa o java.prefs para ler a pasta.

Dá para fazer com java o mesmo que se faz com os outros. É tudo uma questão de saber como e realmente explorar o desktop em java. As ferramentas estão todas lá.
A deficiencia não está na plataforma mas sim nos seus usuários que não a conhecem. Poderiamos argumentar que o java deveria vir com isso de fábrica ? podemos. Mas é impeditivo ? não. Porque qualquer programador consegue fazer direito com as ferramentas que ha.

#51

[quote=Jesuino Master][quote=ViniGodoy]Não acho que afirmar que Java é ruim para desktop baseia em pré-conceito. Sem falar no Swing ser ou não fácil/produtivo, eu poderia citar os seguintes motivos:

Em primeiro lugar, é difícil fazer o deploy de uma aplicação Java desktop. Você tem que garantir que o sistema alvo tenha uma VM configurada corretamente. Na hora de rodar uma aplicação Java, você normalmente tem que passar parâmetros para a VM (tal como o -XMX ou -XMS) e isso não pode ser feito de forma conveniente, dentro do .jar, por exemplo. Finalmente, é complicado criar atalhos para o .jar (normalmente você vai ter que criar um arquivo de lote, e associar o atalho a ele, para ele disparar o .jar).

Você pode resolver isso com um instalador, duplicando a VM na máquina do usuário e, usando a estratégia do Eclipse, criando um executável para disparar sua aplicação Java (no lugar do arquivo de lote).

Uma das coisas mais básicas em Desktop é também pegar o caminho onde a aplicação está localizada. Isso é trivial em várias linguagens, como C++ ou C#, mas é virtualmente impossível em Java. Especialmente se levar em conta detalhes como as restrições do Security Manager.

O java não tem qualquer integração com o UAC ou qualquer outro recurso mais específico
do SO (Active Directory, OpenGL, DirectX, Direct2D, AviCap, etc). Só nas últimas versões foi possível marcar um arquivo criado como “executável” no Linux, por exemplo. Em C#, você pode solicitar o UAC por um arquivo manifesto. Em C++, isso é feito usando uma opção na compilação. Você até pode apelar para JNI e JNA, mas isso não é fácil e nem conveniente (bem diferente dos unsafe methods do C#).[/quote]

Dá uma olhada no JavaFX. esses problemas que você apontou são reais e o pessoal da equipe de JavaFX está tentando limpar tudo isso.

Olha o FAQ do JavaFX:

Então, em breve Java Desktop será JavaFX.

Sobre os problemas de instalação, isso acaba em breve:

https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx

Mas outras coisas nativas ainda continuam complicadas e acredito que isso não muda tão cedo.[/quote]

Isso vai quebrar um galhão para os desenvolvedores. O swing e swt são bons para criar sistemas solitários. Você usa só aquilo na máquina x. Não dá para fazer aplicativos que interagem com o sistema operacional e outras soluções, como criar menus de contexto e etc, Fora o peso que é completamente inviável para esse tipo de software. Com o javafx os desenvolvedores terão suporte a periféricos e sensores, api de desenho robusta, áudio e vídeo, tollkit de janelas leve(porque é nativo). Aí sim a coisa melhora bem.

#52

Com certeza. Creio que no futuro ele se torne uma opção bem mais viável para desktop.

Mas achei que eles demoraram demais a priorizar isso, e estão entrando num mercado com anos luz de atraso. Para a tecnologia colar, vão ter muito trabalho, e precisarão de recursos realmente espetaculares.

Além disso, o inicio do JavaFX já queimou bastante o filme da tecnologia. Primeiro, a descrença pelas próprias demonstrações, na época da Sun, que eram penosamente lentas, mesmo em computadores relativamente top para a época. Depois, a demora em prover controles de UI, a indefinição do JavaFX Script (que acabou cortado).

Sei que muito disso está solucionado agora, mas creio que vão ter o mesmo trabalho que a MS está tendo com o SilverLight para limpar a bagunça que fizeram.

Além disso, boa parte dos recursos que o JavaFX oferece já está presente no QT na forma da QML há um bom tempo. A concorrência do Java já está fornecendo APIs assíncronas de alta qualidade (como as presentes no .Net 4.0 e no Flex), já tem frameworks maduros, fáceis de usar e consistentes e já não tinha todas essas deficiências. Por isso, é difícil alguém que trabalhe muito com desktop (como eu) considerar o Java hoje uma boa plataforma para esse tipo de ambiente.

Não que seja impossível fazer as coisas em Java, mas é que existem muitas alternativas onde você terá os mesmos recursos que Java oferece, sem os problemas.
Eu particularmente torço pelo Java. Gosto muito da linguagem, e seria legal ter a opção de usa-la em mais aplicações desktop ou em games.

#53

[quote=sergiotaborda]Isto é muito util em programas de linha de comandos como o mvn do maven.
Sim, não diz onde está instalado o maven para é para isso que servem as configurações. No caso do maven e do ant e outros é preciso configurar o home. Isto porque eu posso querer mudar de versão conforme o projeto. Seria melhor que o java tivesse um caminho da instalação ? seria, mas ninguem tem isso. O caminho da instalação , como o nome indica, é criado durante a instalação. A instalação de um sistema desktop - quando bem feita - ou usa un instalador igual aos usados pelas outras plataformas, ou usa jws. Ou seja, alguem tém que escreve no maldito do registro do OS. E feito isso vc simplesmente usa o java.prefs para ler a pasta.

Dá para fazer com java o mesmo que se faz com os outros. É tudo uma questão de saber como e realmente explorar o desktop em java. As ferramentas estão todas lá.
A deficiencia não está na plataforma mas sim nos seus usuários que não a conhecem. Poderiamos argumentar que o java deveria vir com isso de fábrica ? podemos. Mas é impeditivo ? não. Porque qualquer programador consegue fazer direito com as ferramentas que ha.[/quote]

Quando se fala em aplicações desktop o diretório da aplicação é um diretório extremamente importante. Fico impressionado de no Java não ter como obter esse diretório.
E ele é diferente do diretório de execução da aplicação. No Java, as únicas opções são configurarem variáveis de ambiente, que são práticas para desenvolvedores, mas não para usuários, ou fazer o .exe mágico.

Em muitos sistemas operacionais, inclusive no Windows 8, o diretório da aplicação é um dos poucos onde a aplicação pode ler ou escrever. É também onde você pode colocar recursos que você gostaria que estivessem fora do .jar, tais como os plugins que o Eclipse tem, mods dos jogos ou scripts de seu usuário.

É claro que “dá para fazer” o que os outros fazem. Mas você sempre toma algum caminho tortuoso. Isso é o que chamamos de “workaround”, “jeitinho brasileiro” ou “xunxo”. É sempre melhor ter o recurso oficial, do que recorrer ao seu instalador gerar um arquivo em algum lugar que você conheça, gravar um variável de ambiente ou apelar para o JNI. Se estamos falando de uma plataforma ser ou não adequada a um tipo de solução, creio que estamos falando dela ser completa, não de termos que solicitar a outros programas, ou recorrer a bindings. Não estamos falando de ser “possível ou impossível”.

#54

Gosto muito de java pra desktop, mas o meu preconceito com ele é a descompilação da aplicação final . O que tornar inviável o desenvolvimento desktop na minha concepção.[/quote]

esse é só um dos problemas… outros dois que também teriam são, primeiro que a api padrão de desktop, o swing é meio ruimzinho, os gerenciadores de layout são bem ruimzinhos de se trabalhar, em contrapartida também o mercado não usa muito, o investimento também não é tão alto quanto em outras partes como jee por exemplo…[/quote]

Não vejo isso como problema… basta compilar o Java para nativo… se realmente tiver essa necessidade.

Já usei este cara aqui, mas é pago:
http://www.excelsior-usa.com/jet.html

A diferença no carregamento da aplicação é a principal, entretanto não vi diferença de performance rodando os .jar e os executaveis em maquinas com mais de 1 nucleo…

Tem alguns casos que nem a diferença compensa… as vezes cai de 3 segundos para 1 segundo… 3 segundos para carregar a aplicação dependendo do tipo é irrelevante…

Tem alguns apps comerciais que usam esse cara…

[/quote]

O excelsior só vai otimizar o programa e não reduzir suas dependências. No final ele tem que embutir no executável a máquina virtual. Java é pesado porque tem muitas dependências. Quando digo “pesado” não quer dizer “lento”.[/quote]

ah sim… mas pesado em tamanho… agora nos dias de hoje… algo em torno de 50mb é realmente pesado ???

Volto na questão… tudo depende do que você vai fazer… tem casos que Java realmente não é uma boa escolha… mas tem muitos casos onde Java Desktop é sim uma ótima pedida!

[/quote]

Concordo com você. Eu me refiro a “aplicativos” e não a programas específicos como erps, etc… Para isso acho o swing e o swt ótimos. O problema é o maldito peso da aplicação. Para você ter uma idéia, 50mb é o peso sozinho da classe principal do programa:

Um programa grande vai ocupar na faixa de 1gb ou mais de memória.

Por isso é difícil um desktop possuir mais de duas aplicações java rodando ao mesmo tempo. Um típico caso de desktop seria o seguinte:

Adobe Photoshop editando imagens e passando recursos pela área de transferência para o microsoft word, enquanto você escuta música com mediaplayer e surfa na internet.

Isso é impossível com o java que temos hoje, entendeu?

#55

[quote=ViniGodoy]PS: Eu não estou falando que seja ruim fazer aplicações corporativas Desktop em Java. Boa parte das aplicações não precisam do que falei. Se você for fazer seu sistema de controle de pizzaria®, então, pode usar Java tranquilo.

Ah! Acabei de lembrar de outros recursos em que o Java é capenga. Ele tem péssima integração com periféricos: Scanners, portas USB, porta serial/paralela, webcams ou controladores de jogo.[/quote]

no guj só faltou um botão LIKE.
brincadeira , mas concordo com o que viny disse.

#56

Gosto muito de java pra desktop, mas o meu preconceito com ele é a descompilação da aplicação final . O que tornar inviável o desenvolvimento desktop na minha concepção.[/quote]

esse é só um dos problemas… outros dois que também teriam são, primeiro que a api padrão de desktop, o swing é meio ruimzinho, os gerenciadores de layout são bem ruimzinhos de se trabalhar, em contrapartida também o mercado não usa muito, o investimento também não é tão alto quanto em outras partes como jee por exemplo…[/quote]

Não vejo isso como problema… basta compilar o Java para nativo… se realmente tiver essa necessidade.

Já usei este cara aqui, mas é pago:
http://www.excelsior-usa.com/jet.html

A diferença no carregamento da aplicação é a principal, entretanto não vi diferença de performance rodando os .jar e os executaveis em maquinas com mais de 1 nucleo…

Tem alguns casos que nem a diferença compensa… as vezes cai de 3 segundos para 1 segundo… 3 segundos para carregar a aplicação dependendo do tipo é irrelevante…

Tem alguns apps comerciais que usam esse cara…

[/quote]

O excelsior só vai otimizar o programa e não reduzir suas dependências. No final ele tem que embutir no executável a máquina virtual. Java é pesado porque tem muitas dependências. Quando digo “pesado” não quer dizer “lento”.[/quote]

ah sim… mas pesado em tamanho… agora nos dias de hoje… algo em torno de 50mb é realmente pesado ???

Volto na questão… tudo depende do que você vai fazer… tem casos que Java realmente não é uma boa escolha… mas tem muitos casos onde Java Desktop é sim uma ótima pedida!

[/quote]

Concordo com você. Eu me refiro a “aplicativos” e não a programas específicos como erps, etc… Para isso acho o swing e o swt ótimos. O problema é o maldito peso da aplicação. Para você ter uma idéia, 50mb é o peso sozinho da classe principal do programa:

Um programa grande vai ocupar na faixa de 1gb ou mais de memória.

Por isso é difícil um desktop possuir mais de duas aplicações java rodando ao mesmo tempo. Um típico caso de desktop seria o seguinte:

Adobe Photoshop editando imagens e passando recursos pela área de transferência para o microsoft word, enquanto você escuta música com mediaplayer e surfa na internet.

Isso é impossível com o java que temos hoje, entendeu?
[/quote]

Sim… já tinha entendido… e Repito… eu dificilmente usaria Java para software de prateleira (entenda-se office, photoshop, games e coisas assim)…

No caso do corporativo, só não concordo em ser tão pesado assim… estou trabalhando atualmente em um sistema em SWT que possui 4000 classes java… e consultas muito pesadas que montam tabelas com mais de 100 mil registros numa unica tela… e dificilmente o consumo de memória deste programa passa de 100MB.
Não sei até que ponto conseguiria fazer tão melhor em .NET…
E os outros programadores da equipe nunca trabalharam em C++…

Sem dizer que 50% dos fontes são compartilhados com um módulo Web… aumentando a produtividade… e este que roda em linux (esse foi o principal motivo de descartarmos o .NET no inicio do projeto… a prova de conceito com o mono não foi satisfatória…

mas cada caso é um caso…

#57

A maioria do que o Vini relatou, foi solucionada no JavaFX e no JDK 7, que consegue até usar directX 2D pra acelerar via hardware. Outros problemas já se resolvem com instaladores de forma automática pro desenvolvedor.

Pode até não ser a melhor solução para desenvolver um aplicativo desktop que suporte exclusivamente Windows, mas também não é um bixo de sete cabeças. E não corre o risco que as tecnologias MS correm: MFC era divulgado como o bambambam, agora todo mundo quer que morre porque era horrível. Antes disso já falaram o mesmo do Silverlight, COM/DCOM, COM+, Activex, … O que impede de um dia pro outro a Microsoft dizer que .NET não presta e que a melhor solulção é a .METRO, que vai revolucionar o mundo e fazer todos saírem de mãos dadas cantando “We are de world”? (não estou brincanco, assisti um evento da Microsoft nos Estados Unidos onde os desenvolvedores fizeram isso pra divulgar o .NET 1.0) :oops:

#58

[quote=marcosalex]A maioria do que o Vini relatou, foi solucionada no JavaFX e no JDK 7, que consegue até usar directX 2D pra acelerar via hardware. Outros problemas já se resolvem com instaladores de forma automática pro desenvolvedor.

Pode até não ser a melhor solução para desenvolver um aplicativo desktop que suporte exclusivamente Windows, mas também não é um bixo de sete cabeças. E não corre o risco que as tecnologias MS correm: MFC era divulgado como o bambambam, agora todo mundo quer que morre porque era horrível. Antes disso já falaram o mesmo do Silverlight, COM/DCOM, COM+, Activex, … O que impede de um dia pro outro a Microsoft dizer que .NET não presta e que a melhor solulção é a .METRO, que vai revolucionar o mundo e fazer todos saírem de mãos dadas cantando “We are de world”? (não estou brincanco, assisti um evento da Microsoft nos Estados Unidos onde os desenvolvedores fizeram isso pra divulgar o .NET 1.0) :oops: [/quote]

Nesse ponto tenho de concordar… Java pode não ser “totalmente” software livre… mas não é vendor lockin! Não funciona só no windows! E é facil e barato ter multiplataforma com ele! (IMHO)

#59

[quote=ViniGodoy]
É claro que “dá para fazer” o que os outros fazem. Mas você sempre toma algum caminho tortuoso. Isso é o que chamamos de “workaround”, “jeitinho brasileiro” ou “xunxo”. É sempre melhor ter o recurso oficial, do que recorrer ao seu instalador gerar um arquivo em algum lugar que você conheça, gravar um variável de ambiente ou apelar para o JNI. Se estamos falando de uma plataforma ser ou não adequada a um tipo de solução, creio que estamos falando dela ser completa, não de termos que solicitar a outros programas, ou recorrer a bindings. Não estamos falando de ser “possível ou impossível”.[/quote]

Pera aí. Todas as aplicações windows usam o registry para dizer onde é a pasta da aplicação. Porque vc não quer fazer isso com java ?
O uso de exe não é para passar variáveis, isso vc pode fazer sem o exe. É para controlar a VM ( é um decorator da VM, não da aplicação).
Ok que passar -Xmx tem que ser feito por fora, mas isso é porque não é um comando padrão de todas as VM. É por isso que não está mais integrado. Ha que lembrar que o java é multiplataforma e existem várias VM. Ao contrario do .net ou do C++.

Usar o registry não é um workarround é o que todos fazem. É o padrão certo ( padrão Registry). É o mesmo que o uso de JNDI no EE. Sem JNI.
Se o cara desenvolve desktop e precisa de configruar o OS mas não distribui usando um instalador é o cara que se está auto sabotando.
O java.prefs serve exactamente para isto. Para vc guarda informações da aplicação e deixar a JVM se preocupar onde guardar os dados. Qualquer coisa fora disso não é uso padrão e como tal, não tem regra padrão ( por exemplo, guarda logs)

Agora eu fiquei curiso para saber como o .net , o C, etc sabem onde a aplicação está. Até onde eu sei C envia o caminho de execução no primeiro argumento do args e o .net faz o mesmo que o java dando acesso apenas a onde foi executado o exe (Application.executablePath) e todas as pastas de dados ele cria dentro do home do usuario (que é onde o usuário tem permissão). É o mesmo processo.
Aqui também é necessário o Registry se quiser saber onde está o exe. Não ?

O ponto é, se todos fazer assim, porque criticar o java por fazer igual ?

#60

O swt já é um toolkit nativo, então o programa já carrega menos dependências que no swing. Para software corporativo java na minha opinião é uma alternativa até mais adequada que dotnet. Pela portabilidade e flexibilidade como citaram acima. O problema do dotnet é ser fechado no windows, mesmo tendo alternativas como o mono, que você teria que se ater ao c# 3 e winforms 2.