Aplicações Java pra Desktop

Thread.start() Membro desde: 16/02/2007 20:21:19 Mensagens: 29 Offline

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?

This message was edited 1 time. Last update was at 08/03/2008 19:28:56

.

Thread.start() Membro desde: 16/02/2007 20:21:19 Mensagens: 29 Offline

http://info.abril.com.br/forum/forum.php?topico=161302

This message was edited 1 time. Last update was at 08/03/2008 21:48:24

É 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á

jmozer wrote:, 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,

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

GUJ Master Membro desde: 30/07/2006 16:09:55 Mensagens: 1311 Offline

hugleo wrote:http://info.abril.com.br/forum/forum.php?topico=161302

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!!

Thread.start() Membro desde: 16/02/2007 20:21:19 Mensagens: 29 Offline

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.

Luca wrote:
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.

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á

jmozer wrote: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?

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

Luca wrote:
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.

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

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

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

Luca wrote:
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.

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 é?

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

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

This message was edited 1 time. Last update was at 09/03/2008 20:39:07

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:

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

É 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.

jmozer wrote:...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 é?

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.

Notícias, artigos e o maior fórum brasileiro sobre Java