Aplicações Java pra Desktop

Pessoal, preciso de desenvolver aplicações Java pra Desktop.
Várias aplicações (tipo, gerencimaneto de estoque, cadastro de clientes) serão vendidas para vários clientes.

Então pra isso eu precisaria criar um esqueleto para reusabilidade, a melhor opção é swing né?
Pra banco de dados eu usaria o hibernate?

E tipo, por onde eu começaria e eu obteria resultados bons?

As aplicações seriam desenvolvidas apenas pra windows? Seria melhor eu partir para o Delphi?

.

É isso aí… você já tem a resposta. Vai fundo.

Abraços

A velha polêmica… Delphi (Object Pascal) ou IDE-X (Java), acho que o link da INFO Online é meio antigo e não pode ser levado muito em consideração atualmente, a única IDE para Java que foi mencionada naquele artigo foi o JBuilder da Borland, eu tentei utilizar uma vez, mas é muito pesado e o código gerado não dá pra acreditar…, agora existem várias boas IDE’s para programação em Java e praticamente todas gratuítas.

Cara, eu uso Delphi desde a versão 2 (atualmente utilizo a 7) e para programar em Java utilizo o Netbeans desde a versão 4.5 (atualmente utilizo a 6.0.1), te digo o seguinte, dá pra ser produtivo com as 2 linguagens, depende muito do que você quer fazer… tente programar para web em Delphi, lixo total…

Antigamente dava até pra dizer que Java não era produtivo para desenvolvimento para desktop, mas desde a versão 6.0 do Netbeans vieram incorporados vários beans que fazem a “mágica” como o Delphi faz com os seus componentes de acesso aos dados no banco de dados, não sei como funciona no Eclipse, mas a comunidade que usa essa ferramenta acredito que seja até maior do que quem utiliza o Netbeans e provavelmente também deve ter no meio dos seus inúmeros plugins algum que facilite a vida de quem quer desenvolver para desktop.

Eu vejo apenas 1 problema em desenvolver aplicações desktop em java (independente da IDE), que é deixar o teu código fonte praticamente aberto, basta um usuário mais “esperto” resolver decompilar o teu jar que ele vai conseguir ver o código fonte, login/senha de acesso ao banco de dados, rotinas de criptografia, etc…etc… mas como a filosofia do java é desenvolver aplicativos open source fica ao critério de quem distribui o software… nada que um bom contrato com o seu cliente não resolva.

Com 8 anos de empresa, acabei precisando aprender java para apenas 2 projetos, 1 deles é o que mantém a empresa (captura e autorização de vendas TEF) e outro é um software desktop que necessita java porque o cliente utiliza em notebooks com linux e outros mac’s, mas no final acabei gostando da linguagem e atualmente estou numa fase de transição, acabei partindo para todo ambiente open source, instalei o Ubuntu no meu notebook novo (5 meses atrás) e deixei o antigo com Windows XP até eu conseguir migrar todas as aplicações que eu tenho em Delphi para Java, por enquanto não me arrependi em nada.

[]´s

Realmente essa discussão é bem velha, e acho que não tem fim.

O que posso te dizer é que o Java já foi bem ruinzinho, melhorou bastante e vai melhorar ainda mais em breve. É só dar uma olhada no artigo sobre Java Update N na última Java Magazine.

Uma vantagem do Java que foi uma mão-na-roda pra mim foi o Java Web Start. No começo dava uns erros bizarros, não se atualizava e tal… mas depois acabou com o inferno de cada usuário ter uma versão. Muito bom mesmo. Aconselho tb a usar o NetBeans.

Um último conselho é ter cuidado com o Hibernate. Na vez que usei ele (versão 2.x) tinha um tempo de inicialização de alguns segundos que prejudicava a inicialização do meu aplicativo.

Olá

  1. Comecei com Java em 1997, participei de projetos pioneiros com Java, já vi muito código burro escrito em Java mas até hoje nunca vi login/senha de acesso ao bando de dados sem criptografia dentro do código Java.

  2. As rotinas de criptografia que um desenvolvedor usa em Java fazem parte da própria API do Java, são bem documentadas e tem os fontes abertos. O que dá segurança não é esconder os fontes de criptografia e sim o uso de algoritmos corretos e senhas fortes.

  3. Em qualquer linguagem, usar algoritmos caseiros de criptografia é suicídio.

[]s
Luca

Esse artigo é antigo e é a maior basteira que eu jah li na vida!

“O site www.tiobe.com mostra claramente que o uso da linguagem Java vem caindo assustadoramente após a Sun firmar acordo de interoperabilidade com a Microsoft. Os mais experientes sabem o que isso significa, por isso o investimento nessa linguagem pode ser frustrante, porque a Microsoft fará de tudo para empurrar o .NET.”

Isso o cara disse em 2005…hahahahaha

Fora que se o Java vai cair pq vez um acordo de interoperabilidade com o .NET, o que dirá do Delphi?

hehehehe

cara…desconsidere tudo o que vc leu nesse artigo!!

O pior problema do Java é sua lentidão, existem clientes que ainda possuem uma máquina antiga.
Um ponto, o Delphi é bom (Falo das versões 6 ou 7, que ainda dá pra desenvolver bons aplicativos), pois o código gerado por ele roda mais rápido que Java (Java é interpretado e Swing ainda é uma emulação de funções que deve ser feitas pelo SO).
Outro ponto posito é que o Delphi gera um aplicativo com o código fechado, pois é muito simples descompilar um código fonte em Java.
Mas o foco principal do Java é desenvolvimento de aplicativos que trabalham na Web, quanto a isso o Delphi não chega nem perto.

[quote=Luca]

  1. Comecei com Java em 1997, participei de projetos pioneiros com Java, já vi muito código burro escrito em Java mas até hoje nunca vi login/senha de acesso ao bando de dados sem criptografia dentro do código Java.[/quote]

Luca, desculpe a ignorância, acho que seria correto abrir um outro tópico, mas você poderia me dar um exemplo disso?
Pergunto isso porque mesmo que você utilize a senha criptografada (mesmo que não seja uma rotina de criptografia proprietária) dentro do código, ao decompilar o fonte o usuário que decompilou pode copiar e colar essa senha e criar um novo aplicativo java (que ele desenvolveu) utilizando a senha (mesmo que criptografada…), ou não?

Obrigado.

Olá

Sugiro que experimente descompilar um programinha Java. Comece com simples e pequeno que não passe de umas 50.000 instruções. Pelo que conheço de decompiladores, nem sempre se consegue recuperar todo o código fonte. E se o cara obfuscar algumas classes chaves, aí prepare-se para gastar muito tempo. Pior ainda será se o desenvolvedor não incluir nenhuma informação de senha no programinha. Todo seu trabalho será a toa.

Usando Java ou qualquer outra linguagem, é possível guardar as informações de acesso ao banco de dados em arquivo (criptografado ou não) armazenado no servidor protegido pelos recursos de segurança da empresa. Já participei do desenvolvimento de sistemas grandes do tipo desktop no qual em nenhum lugar do código do cliente havia informação sobre banco de dados.

PS: Sistema que o cliente acessa direto o bando de dados está obsoleto desde o milênio passado.

[]s
Luca

Já tentei fazer isso e depois de decompilar, mesmo que obfuscado o que está definido dentro de strings fica totalmente visível, por exemplo, se você definiu algo do tipo

String nomeCliente = "Joao da Silva";

Depois você gerou o jar, obfuscou o código, etc…etc… se você descompilar vai conseguir ver algo do tipo:

String x = "Joao da Silva";

Percebeu? O obfuscador troca apenas os nomes das variáveis que você cria originalmente, pelo menos foi isso que eu percebi.

Sim, essa é a ideia, mas digamos que você guarde esse arquivo num endereço por exemplo : //meu_servidor/acessos.txt, então você acessa esse arquivo e lê as informações que constam nele para acessar determinado banco de dados (lembre-se que estamos discutindo sobre desenvolvimento de aplicativos desktop), bom tendo isso como informação se eu decompilar o jar e ver de onde se busca os dados eu consigo baixar esse arquivo normalmente e ver os dados que estão no arquivo, mesmo que eles estejam criptografados, não é?

Qual IDE você utiliza? Se for Netbeans (principalmente a partir da versão 6) existem os Beans que fazem isso… Lembrando novamente que estamos falando de aplicativos para desktop que vão rodar numa rede interna da empresa, não vejo problema algum, além é claro dos citados acima (acesso ao banco por usuários não autorizados), a produtividade no desenvolvimento fica muiiiiito maior.

[]´s

Olá

Só para lembrar:

  1. Firefox é o aplicativo desktop mais usado na minha máquina

  2. Não vejo nenhuma diferença em um aplicativo que rode numa rede local de um que rode na Internet. Você desenvolveria um jogo da velha que não pudesse jogar com seu amigo que se mudou para as montanhas do Afganistão? Você desenvolveria um sistema de contas a pagar para o japonês da pastelaria da esquina que ele não pudesse acessar quando fosse visitar a vózinha no Japão? Lembre-se que estamos no século 21.

  3. Se o Netbeans tem isto é bobagem. Se alguém usa isto é absurdo.

  4. Nem consigo imaginar uma aplicação que gaste uma licença de banco de dados por cliente ao invés de usar um pool de conexões no servidor. Há forte cheiro de Clipper em uma solução anacrônica como esta.

[]s
Luca (que desde 1996 não desenvolve mais em Clipper e muito menos tenta desenvolver em Java igual ao Clipper)

Olá

Mais 2 considerações:

É como eu disse, faça isto com caso real. Por exemplo, abra o jar do Lucene ou até mesmo um outro menor como o cglib com um decompilador e tente entender o código. Não experimente com o Hibernate porque tem cerca de 100 mil linhas.

Se você conseguir invadir o servidor e pegar o arquivo, demita seu administrador de rede.

[]s
Luca

iiii, agora virou desktop x web.

Os aplicativos que fiz com Swing precisavam de acaleração 3D e interatividade diferente. Sei que é específico, mas aconteceu comigo mais de uma vez. Até o google tem o Earth e o Picassa. E tudo podia ser acessado remotamente via JWS.

Mas se vc for fazer um CRUD, e o teu cliente tem uma conexão confiável (fora das montanhas do Afeganistão)… é melhor web mesmo com certeza.

Olá

Obrigado pela lembrança dos exemplos: 2 excelentes aplicações desktop que acessam a Internet.

Na verdade só consigo imaginar 2 tipos de aplicação: com interface web uando HTML, CSS, AJAX, etc. ou com Interface de janelas do tipo do Picasa, GoogleEarth, Eclipse, etc.

O que se fazia no século passado em Clipper com acesso a base de dados diretamente na camada cliente tem sua serventia se for um sistema legado mas é muito limitada para que alguém desenvolva algo assim neste século 21.

[]s
Luca

Lucas, beleza, consegui entender o esquema do arquivo guardando as senhas no servidor, vai da segurança da rede. OK.

Realmente, Clipper eu parei de usar assim que conheci o Delphi, em 1992.
E desde essa época se desenvolvia produtos client/server em Delphi, com 2 ou 3 camadas por exemplo, e sim, eram acessados dentro da rede da empresa ou de fora dela.

Então, se alguém usa/usou Delphi, eu gostaria de um exemplo nesse sentido, vamos imaginar o desenvolvimento de um ERP no Delphi 7 (utilizando os componentes DBExpress), eu teria algo assim no desenvolvimento n-tier:

Camada Client:
Meus componentes de exibição dos dados nas telas (TDBEdit, TDBCombobox, etc…)
Meus componentes de acesso aos dados (TSqlConnection, TClientDataSet, TDataSetProvider, TSQLDataSet, TDataSouce)

Camada Database:
Meu banco de dados qualquer

Nas versões anteriores do Delphi, se utilizava uma camada middleware (Server) para fazer a conexão do banco com as telas dos clientes, mas isso ficou desnecessário com a incorporação dos componentes DBExpress.

Então tenho 2 perguntas:

  1. Principalmente para alguém que está utilizando Netbeans 6 e usa o bean binding, se esse acesso ao banco de dados que ele faz é semelhante ao que o Delphi faz utilizando os componentes DBExpress?

  2. Como seria um exemplo do desenvolvimento do um aplicativo desktop n-tier em Java, caso a resposta a primeira pergunta seja NÃO.

ATENÇÃO: Não estou aqui tentando criar polêmica alguma na forma de desenvolvimento, nem de linguagens, nem estou tentando provar que uma ou outra forma é correta, quero apenas com a ajuda de quem tem experiência tentar deixar mais claro o que se deve/pode fazer ou não, assim todos vamos ganhar em conhecimento.

Felizmente, ou infelizmente, tenho muito mais experiência em Delphi do que em Java e por isso utilizei o exemplo em Delphi para me basear.
Segue um link pra alguém que não viu esse Bean Binding dos Netbeans em ação ainda: http://blogs.sun.com/alexismp/resource/app-framework.html

[]´s

Olá

Jota, insisto. Não escreva Java igual a a Delphi, Clipper, VB, FoxPro, etc. Mesmo que o Netbeans tenha um negócio deste parecido com Delphi, não use. Acesse sua base de dados no servidor via um servlet e no servlet use JDBC, Hibernate, EJB 3.0, etc.

Lembra como no século passado era difícil escrever ERPs multi filial e multi empresa? Com Java isto é facílimo justamente porque a base de dados pode estar em qualquer parte do mundo, inclusive em uma rede local ou na mesma máquina do cliente.

[]s
Luca

é possivel misturar servlets com swing? tipo… acessar um servidor de aplicações atraves de swing?

Olá

Sim, usando diretamente URLConnection ou com ajuda de HttpClient.

[]s
Luca