Java para desktop é perda de tempo?

Assuntos Gerais
#61

[quote=sergiotaborda]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) .[/quote]

só quis mostrar q a informação não era o q vc tava dizendo q era.

mas, uma pergunta:

public class Teste { public static void main(String[] args) { System.out.println(System.getProperty( "user.dir")); } }

gerar o Teste.jar;

colocar o Teste.jar no c:\teste\

no prompt de comando:

>cd %public%\desktop
>java -jar c:\teste\teste.jar

pq imprimiu:
C:\Users\Public\Desktop

???

#62

o registry pra saber onde está o .exe? como assim?

pera ai! pra dizer, ou pra saber?

#63

[quote=GilsonNunes][quote=sergiotaborda]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) .[/quote]

só quis mostrar q a informação não era o q vc tava dizendo q era.

mas, uma pergunta:

public class Teste { public static void main(String[] args) { System.out.println(System.getProperty( "user.dir")); } }

gerar o Teste.jar;

colocar o Teste.jar no c:\teste\

no prompt de comando:

>cd %public%\desktop
>java -jar c:\teste\teste.jar

pq imprimiu:
C:\Users\Public\Desktop

???

[/quote]

Porque não é isso que ele vai imprimir. Ele vai imprimir a pasta de onde vc invocou o java (que foi C:\Users\Public\Desktop).
E como eu já disse , isso é util para ferramentas de linha de comandos. Para desktop vc simplesmente força chamar da pasta certa (usando o exe que o vini falou) ou simples usa o registro do OS que é a forma mais simples. Seja de onde for que vc chamar o registro sempre apontará o mesmo lugar.

Eu havia entendido que estava sendo dito que o java não tinha como saber de onde foi invocado. O user.dir dá essa informação.
Só que o argumento do Vini é que não havia como saber a pasta onde a aplicação está ( onde está o jar). Existem formar no java de fazer isso, mas como o foi dito não são “padrão”. Ou melhor, são usos da API que produzem o resultado certo que o Viny chamou de workarround. (Hoje em dia qualquer motor de injeção faz um workarround para pesquisar as classes que existem no path para depois pesquisar anotações e ninguém diz que o java não dá suporte). O ponto é que a API não tem um método simples e obriga vc a conhecer muito de java de como funciona o modelo de classloading.

O que eu argumentei então é que neste caso em que vc quer saber o caminho da pasta da aplicação, a única opção é usar o registro do OS via java.prefs e um instalador - da mesma forma que os jogos e outros aplicativos fazem. Este caminho realmente o java não lhe de mão beijada - embora possa ser descoberto como já disse - e o argumento é que outras plataformas oferecem essa informação de forma simples e que isso faz toda a diferença.

O que eu estou dizendo é que não faz diferença nenhuma. Vc pode usar as mesmas tecnicas em java que usa nos outros.

#64

Não? Em materia de tecnologia para Desktop, o Java não está atrás.

Começou com a AWT… que logo foi abandonada. Swing era o bambambam, ficou na geladeira por alguns meses (para não dizer alguns anos)… e agora temos que ir para o JavaFX.
O JavaFX Script era a solução, foi abandonado. Tinhamos o Java 3D também, que foi abandonado. Não podemos esquecer da comunicação serial, cujo suporte ao Windows foi silenciosamente retirado, e que foi abandonado. A java.sound, que começou bem, ficou uma API legal, mas o desenvolvimento foi abandonado, sem suporte a vários e vários arquivos comuns de áudio. Ah sim, faltou a JMF, que veio prometendo webcam, e foi abandonada.

E as APIs de USB, controles e outros devices, que nunca existiram…

Viajou Sérgio? O caminho da aplicação é o primeiro parâmetro do args das aplicações C++.
E existe uma função do Windows, do Metro e do Linux para pegar essa informação, sem recorrer ao registro.

Sim, mas a questão não é essa. Nos outros, vc não precisa dessa gambi toda. A informação está simplesmente lá.

#65

Faz mesmo. Mas existem empresas por trás desses motores, que estão garantindo isso para você. E garantindo seu funcionamento multiplataforma.
Se não me engano, eles também se baseiam na estrutura do .jar e de classes, coisas que são padronizadas e não devem mudar.

É bem diferente de você testar um método, sem quase critério nenhum, e inserir isso na sua aplicação. O próprio do classloader mesmo, não há nada na especificação que garanta minimamente o formato e o tipo de informação que o getPath() de um classloader vá te retornar.

A única coisa que ele garante é que será o mesmo path que o classloader padrão usará para saber onde está o recurso. E ali, pode ou não haver o caminho exato do .jar no SO.

De qualquer forma, essa é um dos vários problemas que citei.

#66

Eu acho que não estou viajando. O primeiro argumento do C++ é o caminho de invocação (equivalente ao user.dir)
Para pegar o caminho do executável (onde o exe está) não é trivial e não vem pronto. E segundo o link, nem o args[0] é confiável.

Não sei. Não uso C++. Mas não encontrei referencia a essa facilidade “out-of-the-box”.
Então talvez apenas o .net tenha isso “out-of-the-box”. Mas qual é a função ? Eu não encontrei a referencia.

#67

[quote=sergiotaborda]Eu acho que não estou viajando. O primeiro argumento do C++ é o caminho de invocação (equivalente ao user.dir)
Para pegar o caminho do executável (onde o exe está) não é trivial e não vem pronto. E segundo o link, nem o args[0] é confiável.

Não sei. Não uso C++. Mas não encontrei referencia a essa facilidade “out-of-the-box”.
Então talvez apenas o .net tenha isso “out-of-the-box”. Mas qual é a função ? Eu não encontrei a referencia. [/quote]

Tem razão, basta chamar duas funções:
For Linux: readlink /proc/self/exe
Windows: GetModuleFileName

E isso é trivialmente invocado do C++ (já que ele não te promete multiplataforma).

Anyway, pode ser que eu esteja errado nesse quesito. Em todo caso, esse é um dos pontos que citei, os outros, que são até mais relevantes, ainda continuam válidos.

#68

Como eu suspeitava, você está enganado, veja o que diz o standard:

A única coisa que o Standard ressalta é que esse caminho pode não existir caso o host não tenha essa informação. É o caso de você executar o C através de um terminal, por exemplo. Eu, particularmente, nunca vi o comando falhar. E, de qualquer forma, o padrão é claro ao dizer que ele retorna o program name - e é consenso nas implementações C que esse nome se refere ao “full qualified path”.

De qualquer forma, como ressaltei, é bem fácil para um programador C usar a função específica do SO.
Essa integração é uma das propostas da linguagem.

#69

Talvez não. Aliás, não é raro ainda vermos softwares comerciais escritos em Delphi ou Visual Basic. Grande parte dos desenvolvedores maduros de software desktop são órfãos do Delphi ou Visual Basic e migraram naturalmente para o C#/Visual Studio. É verdade também que o ambiente desktop nunca foi a prioridade do Java, basta ver os anos de descaso com o Swing. Felizmente o ressurgimento do JavaFX está buscando mudar essa realidade.
Mas de qualquer forma, eu estava me referindo a velha discussão se vale a pena aprender programar para desktop. Para mim acho que software desktop não vai morrer tão cedo e ainda há um nicho de mercado ativo.
Creio que grande parte dos problemas levantados em relação ao Java podem ser contornados ou não são significativos para grande parte das situações. Por exemplo, que mal tem utilizar um instalador para resolver questões de empacotamento e deploy? É claro que nenhuma tecnologia é mágica e haverá situações específicas em que talvez o Java não seja a melhor escolha. Isso não é demérito da plataforma.
Bom, se Java não fosse viável para desktop o Netbeans e Eclipse não seriam escritos nessa linguagem, as maiores referências de softwares desktop desenvolvidos em Java.
Particularmente também estou bastante otimista em relação ao JavaFX e aposto no seu amadurecimento para consolidar a viabilidade do Java em aplicações desktop, tanto melhorando questões de design de interface quanto performance e gerenciamento de memória.

Mas o melhor de tudo é ver o quanto de conhecimento foi difundido em decorrência da dúvida inicial. No final das contas a discussão virou uma “briga de cachorro grande”, um “duelo de titãs” entre o vini e o sergiotaborda, rsrs. Isso engrandece o fórum e gera conhecimento.

#70

Como eu suspeitava, você está enganado, veja o que diz o standard:

A única coisa que o Standard ressalta é que esse caminho pode não existir caso o host não tenha essa informação. É o caso de você executar o C através de um terminal, por exemplo. Eu, particularmente, nunca vi o comando falhar. E, de qualquer forma, o padrão é claro ao dizer que ele retorna o program name - e é consenso nas implementações C que esse nome se refere ao “full qualified path”.

De qualquer forma, como ressaltei, é bem fácil para um programador C usar a função específica do SO.
Essa integração é uma das propostas da linguagem.[/quote]

quem usa LCL/fpc mesmo, apenas faz assim:

s := Application.ExeName;

isso independente de ser nos win32, win64, linuxAll, winCe, macOS, solaris, OS2, etc.

#71

Eu mesmo fui programador de Delphi, VB5, VB6 e Visual C++ Builder (e antes disso de Clipper e Pascal, mas aí estamos indo longe demais o Tunel do Tempo).

[quote]Mas de qualquer forma, eu estava me referindo a velha discussão se vale a pena aprender programar para desktop. Para mim acho que software desktop não vai morrer tão cedo e ainda há um nicho de mercado ativo.
[/quote]

Com certeza. Eu mesmo estou no mercado desktop há muitos anos (se vcs não notaram, eu raramente apareço nos tópicos de desenvolvimento web), e não vejo ele desacelerar.
Aliás, até pelo contrário. A introdução do Metro e dos dispositivos móveis deu foi um boom no mercado (apps. para dispositivos móveis são aplicações desktop).
A web também abriu portas para a distribuição de aplicações, coisa que na época em que só havia apps desktop por aí, não tinhamos (você até podia fazer o software, mas muitas vezes jamais conseguiria distribui-lo para um grande mercado sem um publisher).

Há certas indústrias, como as de engenharia, onde sequer faz sentido falar em aplicações web. Aplicativos que são usados para controlar dispositivos ou tomar decisões em tempo real.
Sem falar nos aplicativos “de prateleira”, para o usuário de PC.

A grande vantagem é que as tecnologias Desktop e web estão se aproximando. No Windows 8, por exemplo, já vai ser possível programar usando HTML 5 e Javascript para criar suas telas. No caso do QT e do próprio JavaFX, linguagens como a QML e o Groovy tornam o código bastante declarativo, bem similar ao que um desenvolvedor web já encontra. Do outro lado, a web também torna-se cada vez mais responsiva, o javascript cada vez mais poderoso e mais e mais idiomas de desktop vão sendo incorporados as páginas.

[quote]Creio que grande parte dos problemas levantados em relação ao Java podem ser contornados ou não são significativos para grande parte das situações. Por exemplo, que mal tem utilizar um instalador para resolver questões de empacotamento e deploy?

É claro que nenhuma tecnologia é mágica e haverá situações específicas em que talvez o Java não seja a melhor escolha. Isso não é demérito da plataforma.
Bom, se Java não fosse viável para desktop o Netbeans e Eclipse não seriam escritos nessa linguagem, as maiores referências de softwares desktop desenvolvidos em Java.[/quote]

O Eclipse não é feito inteiramente na plataforma Java. Ele depende da SWT, que usa JNI. É claro que o SWT é confiável e maduro, mas não é Java padrão (não dá para usa-lo para defender a plataforma, pois roda fora da VM).
No caso, podemos citar como apps desktop o Netbeans, o MySQL Workbench e o Vuze. Ainda assim, dois deles são apps para desenvolvedores. Dá para contar no dedos quantos aplicativos desktop de mercado famosos usando somente a plataforma Java temos por aí (além do Vuze, alguém conhece mais algum?). Agora, não significa que seja impossível, ou mesmo inviável, desenvolver aplicações corporativas em Java desktop. Note que eu fui cuidadoso, desde o primeiro post, ao falar que estava falando do mercado de aplicações para consumidores, e não empresas.

Basta ver como exemplo softwares de SAP, que são em Java. Na Siemens mesmo, utilizei Java por vários anos com muito sucesso (embora tenha sofrido um pouco com a descontinuação repentina da javax.comm). Eu gosto de usar o Java para desktop em meus estudos também, como é o caso desse editor de imagens, que fiz para o mestrado.

Vale lembrar que, mesmo fora da plataforma Java, temos frameworks maduros e garantidos, como a SWT, RXTX, DirectShowJava, Javacv e a LWJGL. É através deles que surgiram não só o Eclipse, mas o Minecraft, Taikodom e outros aplicativos conhecidos. Não vejo problema em usa-los, pois são muito bons. Só estou gostaria de fazer aqui a diferenciação entre “conseguir fazer aplicações usando linguagens Java” e “defender o Java como plataforma para desktop”. Usando a linguagem Java, você consegue fazer muita coisa, pois pode recorrer a bindings como esses que rodam fora da plataforma e resolvem o problema. Já na plataforma java, mantida pela Oracle, e garantida em todas as VMs java padrão, a coisa aperta.

O fato é que, na minha opinião, os problemas, são sim, demérito para a plataforma (no quesito desktop). Eu acho engraçado que nós vivemos ouvindo no GUJ que “linguagens são ferramentas e o programador tem que se adaptar a cada caso”. Essa frase rola por aqui pelo menos uma vez por semana. Mas chega um tópico desses, onde o Java claramente não é a melhor ferramenta, e o pessoal defende a plataforma com unhas e dentes. É a mesma coisa em tópicos sobre games.

Se falarmos em defender a plataforma como um todo, as coisas são bem diferentes, por exemplo, ao fazer apps usando a plataforma Android, mesmo que usando linguagem Java.
Ele não só nasceu para isso, como a Google tomou bastante cuidado, associando poder, facilidade de implementação e conceitos modernos de programação desktop.

Como fã da linguagem, e da plataforma Java como um todo, é o que eu torço também. :slight_smile:

1 curtida
#72

Exatamente! Argumento imbatível contra os céticos do mercado desktop.

Show de bola o DirectShowJava. Eu ainda não tinha conhecido esse framework. No site do projeto inclusive é uma demo demonstrando a integração do framework com JavaFX.

É verdade, às vezes o entusiasmo pela linguagem impede de enxergamos as deficiências técnicas da plataforma. Reconheço que é temerário defender uma linguagem/plataforma com unas e dentes, rs.

Fruto de um planejamento meticuloso, focado e com objetivos bem definidos. Algo que não esteve presente no tradicional Java Desktop, basta vermos a evolução “tartaruga” do Swing.

Somos dois.
[/quote]

Resumiu tudo com chave de ouro, rsrs.
PS: Muito interessante seu editor de imagens.

#73

Todas essas APIs estão nas versões superiores do Java, inclusive no beta da JDK8. Sem mais.

#74

Acontece que no seu post original você não estava falando de estar ou não presente no JDK, ou em retrocompatibilidade.
Mas no fato do pessoal falar que a tecnologia anterior é horrível, pedir para ela morrer e usar outra no lugar.

No caso da Sun, algumas pediram para morrer e nem sequer colocaram outras no lugar (Java3D, javax.comm).
Na minha opinião, o posicionamento foi até pior, pois foram silenciosamente abandonadas, sem maiores satisfações a comunidade, ou sem aviso.

E, no caso do ambiente de janelas, ocorreu a mesma coisa que ocorre com a MS (AWT->Swing->JavaFX).
Mas daí com anuncio oficial.

Quanto a retrocompatibilidade, aí até concordo com você. A MS tem mania mesmo de não garantir isso direito.
No .Net até tem feito um bom trabalho, mas não ponho minha mão no fogo por eles (aliás, o WinForms vai mesmo ser substituido pelas APIs metro).

#75

Vini, só uma correção. Até onde eu sei, atualmente o MySQL Workbench é escrito usando alguma linguagem da plataforma .Net (provavelmente C#) e usa Python internamente. Não sei se você comentou sobre alguma versão antiga ou se estou desatualizado e mudaram isso recentemente.

[]'s

#76

[quote=davidbuzatto]Vini, só uma correção. Até onde eu sei, atualmente o MySQL Workbench é escrito usando alguma linguagem da plataforma .Net (provavelmente C#) e usa Python internamente. Não sei se você comentou sobre alguma versão antiga ou se estou desatualizado e mudaram isso recentemente.
[/quote]

Acho que me confundi mesmo.

#77

Acontece que no seu post original você não estava falando de estar ou não presente no JDK, ou em retrocompatibilidade.
Mas no fato do pessoal falar que a tecnologia anterior é horrível, pedir para ela morrer e usar outra no lugar.

No caso da Sun, algumas pediram para morrer e nem sequer colocaram outras no lugar (Java3D, javax.comm).
Na minha opinião, o posicionamento foi até pior, pois foram silenciosamente abandonadas, sem maiores satisfações a comunidade, ou sem aviso.

E, no caso do ambiente de janelas, ocorreu a mesma coisa que ocorre com a MS (AWT->Swing->JavaFX).
Mas daí com anuncio oficial.

Quanto a retrocompatibilidade, aí até concordo com você. A MS tem mania mesmo de não garantir isso direito.
No .Net até tem feito um bom trabalho, mas não ponho minha mão no fogo por eles (aliás, o WinForms vai mesmo ser substituido pelas APIs metro).[/quote]

Grande vini e marcão, a MS tah amarrada e desde o Vista prometeram um monte mas, uma apostinha mudança soh perfumaria.

#78

Eu trabalho com Java para Desktop e simplesmente não acho perca de tempo, pois é uma linguagem muito flexivel.
Sabemos Java para Web é muito mais utilizada, mas Java para desktop te dá uma boa base para entender a linguagem, se você é iniciante.

Java pra mim continua sendo a melhor.

#79

[quote=Aldeir]Eu trabalho com Java para Desktop e simplesmente não acho perca de tempo, pois é uma linguagem muito flexivel.
Sabemos Java para Web é muito mais utilizada, mas Java para desktop te dá uma boa base para entender a linguagem, se você é iniciante.

Java pra mim continua sendo a melhor.[/quote]
Você usa Java Desktop em que tipos de projeto?

#80

Não podemos esquecer dos velhos aplicativos para frente de caixa, controle de estoque, etc
que dificilmente sairão do mercado.
Sistemas ERP’s, enfim varias aplicações ainda poderão continuar sendo desenvolvidas com Java para desktop.