Eu tambem o Javão.

@GladsonReis,

Vocês estão em fase de decidir uma migração de um legado que foi programado em qual linguagem?

Essa informação será muito interessante.

Java foi a primeira linguagem que de fato criei minhas primeiras aplicações.

A comunidade gigante, material de estudo abundante, alguns dizem que ela é “verborrágica”, pode ser, mas é inegável o poder da ferramenta, possibilidades e facilidade de encontrar material de estudo.

llinguagem legado? Pra isso não importa, o que importa é resolver o problema do cliente.

Você consegue resolver o problema com o Delphi, otimo! consegue com Clipper? Excelente! Lembre-se: tecnologia não é fim, tecnologia é apenas meio.

Parabéns ao Java e comunidade!!!

Delphi Xe2

Qual seria a necessidade de migrar o que já funciona?

A mudança deve ocorrer pra atender melhor o cliente. Sempre pra atender melhor o cliente.

Bem vago essa justificativa. Como voce mesmo tinha citado, tecnologia é só o meio. Tendo uma necessidade mais concreta, claro que valeria a migração, não só por desejo técnico.

Se for o caso de uma migração de Delphi desktop para Java desktop é um investimento que não vale a pena…
Agora se for de Delphi desktop para Java web/cloud já se torna algo interessante em se fazer.

Sei um pouco de Java, tendo feito alguns cursos, o primeiro deles em 1996, onde Java ainda era muito lento e a proposta era o uso de applets em concorrência com a linguagem de backend que surgiu na época, o Perl, usando o protocolo cgi.

Depois fui parar nas ferramentas escolhidas pela minha empresa. Primeiramente o ASP, seguido do ASP.Net, o verdadeiro concorrente do Java.

De qualquer forma, sempre admirei a história e a proposta do Java. Uma linguagem multiplataforma, com uma camada independente do sistema operacional executando em cima de uma máquina virtual.

Apesar de ser verbosa ao extremo e contrariar um dos preceitos modernos, como o propalado DRY(don’t repeat yourself), me inscrevi em mais um curso, por considerar que Java é mais do que uma linguagem, mas um verdadeiro ambiente e com regras e disciplinas que ajudam o desenvolvedor a não sair da trilha.

Exatamente, se a necessidade continuar sendo desktop só vão jogar tempo fora brincando de tecnologia. Não vale mudar pra Java nem .NET desktop (a exemplo de outro post dele, por isso levantei a questao).

Discordo, de Delphi para Java Desktop, sim vale a pena o investimento.
As alternativas de Delphi fora do windows que já é oco, em outras plataformas é um verdadeiro desastre principalmente em termos de estabilidade.

Como diria o Vini Gogdoy: há mais compiladores C para diferentes finalidades que máquinas virtuais java. Quem é o verdadeiro multiplataforma? rsrs

O pessoal da Pivotal, que mantém o Spring discorda. Eles entendem que não tem problema você repetir um ou outro trecho de código para evitar acoplamento e relacionamentos cíclicos, muito comuns quando se exagera na aplicação de conceitos OO.

Eu trabalho com java desde a versão 1.5, tendo iniciado nos idos de 2010.
Já cheguei numa época em que nem os servlets eram vistos com bons olhos e frameworks action based (struts e o próprio jstl + EL eram o padrão do mercado. JSF ainda engatinhava e já era odiado por quase todos.
Hoje eu tenho maturidade suficiente para entender que linguagem e plataforma são ferramentas. E que nunca devemos imaginar que tudo é prego e tentar resolver na base da martelada.

javaflex e demais colegas,

Concordo com você: “claro que valeria a migração, não só por desejo técnico.”

Toda vez que vamos falar de uma linguagem, geralmente enveredamos pelo caminho de cada um defender seu linguagem de “estimação”.

Creio que isso seja um erro. Veja: linguagem de programação é apenas uma ferramenta. Geralmente precisamos entender mais de uma pra podermos adequar de acordo com o cenário.

Alguém já disse: “Para quem só sabe usar martelo, todo o resto é apenas prego…”.

Tem as indicações tipo: “o NETFLIX utiliza tal tecnologia, portanto deve ser bom e vou implantar na minha empresa…” isso é bobagem, pois se um dia você tiver uma fração dos usuários do NETFLIX então pode ser que realmente faça sentido, caso contrario estude o seu cenário pra ver qual ferramenta implantar.

Entre Java ou Delphi ou outra, o que vai definir realmente é: A solução que melhor se adequá pra resolver o problema do cliente custo x beneficio.

Se vamos escolher uma ferramenta, mas não entendemos do nosso cliente e do negocio do nosso cliente, tipo: "o lado do negocio da sua empresa, eventualmente é o que faz gerar dinheiro. Ou ganhar dinheiro ou gastar menos dinheiro. Qual o produto da sua empresa responsável pela maior parte da receita? Qual o produto
ou serviço tem a melhor margem? Você sabe qual a margem liquida da sua empresa? Os 3 maiores custos? "

Se você não sabe disso como é que pensa de que modo vai fazer a real diferença nesses números?

Concluindo: Java é 10 e Delphi também! Mas sem fanatismo, por favor.

** Parte do que postei aqui foi retirado do vídeo do Felipe Deschamps:

Checklist do Programador Sênior: 10 itens para você ser um Programador MUITO acima da média

Hoje, estou bem satisfeito com o java (Spring, Spring Boot, Spring Cloud). Mas além do java, com a JVM, pois consigo usar groovy e kotlin também (essa segunda ainda estou bem no início).

Quero ver o mesmo codigo rodar nessas diferentes maquinas. Fala serio !!!

Será que eu realmente vou precisar colocar um aviso: “Este comentário contém ironia”?
De mais a mais, pode ser que o mesmo código, mesmo em C-ANSI, não rode. Porém, creio ser muito mais simples modificar trechos de um sistema do que construir ou adaptar uma máquina virtual inteira para interpretar o pseudocódigo.
Isso para não entrar em outros aspectos como processamento e memória, né?

Sem ironia. Programar em C / C++ multiplataforma é um verdadeiro inferno, sem falar na manutenção do codigo, Esse foi uns dos principais motivos do surgimento do Java e tambem do seu estrondoso sucesso.
Já a memoria, essa merece um capitulo a parte. Em C/C++, é possivel sobrescrever a memoria
do programa rodando, já em Java ísso é uma violação da segurança daVM.

Tendo surgido o C#(C++++ => C#).

C# tenta corrigir essa questão da segurança do C/C++ com uma VM.
Porem o problema do C# está no entorno do universo Windows, testei no linux, e sinceramente o lixo foi o lugar certo pra ele. Muitos erros, não por culpa da linguagem em sí, mas da plataforma que esta sendo implementada. Mono é terrível.

Para cada linguagem, incluindo as maravilhosas whitespace e o brainfuck possuem razões para existir (mesmo que seja a vontade do sujeito que as criou).
C surgiu para ser uma alternativa mais simples e didática que o B (cara, sempre me perguntei quão complexa é B. Pior, quão complexa é A, deve ser A de assembly).
Java veio para excomungar os ponteiros.
PHP veio para simplificar o desenvolvimento web.
Ruby veio para simplificar o desenvolvimento.
Javascript veio para f*** tudo.

Gostei dessa do JavaScript. (Essa foi a melhor de longe)

Porque valeria esse investimento?

Manutenção, segurança, portabilidade. Quem gosta de [Delphi] Access Violation! e erros dos mais diversos de endereçamento de memoria que ninguem sabe de onde vem deve mesmo continuar indo no cliente de vez e sempre e tacando a culpa em virus, desatualização do windows, deve mesmo continuar com ele. Em Java você vê a Exception e vai cavando e chega no Erro e sabe como resolver. E os mesmo erros quando ocorrem são os mesmos em todas as plataformas. Manutenção não é um detalhe qualquer.

Deixa eu ver se entendi, dizer se é viável ou não sem entender o cenário?

É a mesma coisa de dizer um valor em dinheiro pra fazer uma viagem sem saber qual o destino. Eu acho confuso isso.

Conhecer o cenário é sim importante. Digamos que seu Cliente queira um sistema comercial multi plataforma. Você correria o risco de programar em Delphi e ficar usando tudo que é solução de terceiros para rodar nas ditas plataformas, sabendo que cada solução foi implementada de uma forma ? Independentemente da sua resposta ou de qualquer outro, tem coisas que a gente já sabe do que a linguagem ou linguagem/plataforma é capas.

Comecei a trabalhar com Java em 2002, trabalhava em uma solução de automação de força de vendas para Desktop, Web e Mobile (Pocket PC, celular e Palm Top).
Na versão mobile para Pocket PC utilzávamos uma versão da IBM J9 para Windows CE 4.0 em conjunto de J2ME CDC com Personal Profile e SWT.
Na versão mobile para Celular utilizávamos J2ME CLDC com MIDP.
Na versão para Palm Top era inviável usar Java, então desenvolvemos utilizando HB++.
Para desktop utilizávamos Java 1.3 com SWT.
Para a versão WEB utilizávamos Servlets com um servidor TomCat e Struts.

Para fazer os Pocket PCs conectarem à internet foi necessario desenvolver classes nativas com JNI de forma a conseguir acessar a portas IR que comunicavam com o modem.
O grande desafio sempre era a otimização no tráfego de dados pois os planos de telefone na época eram caros e o cliente pagava pela quantidade de bytes trafegados.
Todas as versões trocavam mensagens entre si através de um protocolo próprio baseado em RMI mas utilizando HTTP e compressão de dados.
Também desenvolvemos uma ferramenta que parseava as interfaces Java e gerava os Stubs na linguagem HB++ pro PalmTop.
Nos Pocket PCs o desafio era o espaço, os equipamentos tinham somente 32MB de memória, 16MB eram consumidos pelo sistema operacional e a máquina virtual Java ocupava cerca de 10MB, sobrava quase nada para a aplicação.
Portanto foi desenvolvido um SGBD próprio, otimizado para Pocket PC, pois os SGBDS que existiam para Pocket PC eram enormes, ou você instalava o banco de dados, ou a aplicação, não havia espacço para ambos.

Depois fui para outras empresas, mas sempre com foco em desenvolvimento Java, tanto que já utilizei muitas tecnologias com Java ao longo desses anos: JNI, JNA, CDS, RMI, JSP, JSF, GWT, JPA, SOAP, Bluetooth…

A primeira IDE que utilizei foi o IBM VisualAge for Java, mas ele foi descontinuado em 2003 ou 2004.
Tentei me adaptar ao Borland JBuilder, mas era horrível, parecia um Delphi que gerava código mal feito em Java.
Tentei me adaptar ao NetBeans, mas era horrível, muito engessado e lento.
Tentei me adaptar ao Forté for Java, mas também era horrível (era baseado no NetBeans).
Tentei me adaptar ao Sun One Studio, mas também era horrível (também era baseado no NetBeans).
Então parti para o IBM WebSphere Application Development Studio, que era leve, mas não tinha editor visual para SWT, JFaces, AWT ou Swing.
Meses depois surgia o “The eclipse Project”, que era um IBM WebSphere Application Development Studio com menos plugins e gratuito.
Hoje continuo utilizando o eclipse como principal ambiente de desenvolvimento.

Claro, manter em Delphi se o cenário continua o mesmo no Windows onde a aplicação já roda.

Acredito que independente de linguagem, se a aplicação é mal construída tudo fica dificil de se fazer, manutenção, encontrar erros aleatórios como você citou, qualquer coisa fica complexa…
O único contato que tive com aplicações Delphi, foi logo quando comecei a trabalhar na área, dava manutenção em um sistema Delphi, e cara, não sofri com os problemas que você relatou, tive uma experiência bem tranquila.

Entender o cenário com certeza é necessário, mas com as informações que foram fornecidas no tópico, o que me leva a entender é simplesmente que existe um sistema em Delphi atualmente, logo se é Delphi devem estar usando windows, e querem agora migrar pra Java, mas até então não citou a necessidade de se fazer isso, na minha concepção seria uma troca de 6 por meia dúzia.
Agora se ele explicar melhor o cenário, qual a motivação real que levou ao pensamento de migrar o produto de tecnologia aí eu avaliaria a minha resposta com base nisso, caso contrário contunuo pensando que é um esforço desnecessário.

Na real, não.
Embora o mercado pague relativamente mal a profissionais delphi, ainda assim é muito mais difícil você encontrar um (quem dirá 5, 10) para manter.
É o caso? Não sei.
Porém, em java, você consegue encontrar vários com muita facilidade.
Eu sei que depende muito de região para região, mas, é fato. Assim como você vai encontrar muito mais profissionais php que java e javascript muito mais que php e assim por diante.
Sem falar no próprio ciclo de vida do sistema. Será que realmente vale a pena manter um sistema legado? Não necessariamente migrar para java, mas, já pensou na quantidade de coisas que já pipocaram e ainda pipocam como novidade?

Óbvio: sem conhecer o real cenário, tudo o que falamos é especulação baseada em experiências próprias.

Vendo o cenário por este lado, pensando em mão de obra de profissionais, realmente é um ponto relevante a se considerar em um processo de migração.

Concordo com esse seu ponto de vista!

Verdade, mas olha o verbo “era” muito lento. As jvms evoluiram pacas. Somente pra citar, tenho aqui um programa consagrado no mercado forex e bolsa, chamado mt4, feito em c++, desenvolvi um similar em javaFX para opcoes binarias, mas serve para forex e bolsa tambem.
Tem coisas aqui que o em javaFX tá dando um pau no mt4 de deixa-lo descadeirado.
E a memoria tá similar, pouca coisa maior que no mt4.
Agora tenta comparar a segurança do em javaFX com o em C++, primeiro que até agora o em javaFX não tá dando aquelas travadinhas de vez em quando comuns em programas escritos em C++, claro por varios fatores, nem sempre por causa da linguagem.

Se eu perguntar para um professor universitário de programação se vale a pena migrar de Delphi Desktop para Java Desktop, o que ele me responderá?

Se tu quer saber a opinião dele tem que perguntar diretamente para ele, não tem como eu ou qualquer outra pessoa responder!

Não existe nenhum professor universitário de programação que está inscrito no GUJ?