Java está à beira de um colapso?

Existem milhares de frameworks sim, mas cada um escolhe o que quer.

Isso que voce citou é só um exemplo de má-gerencia de projeto. O cara fica mudando, mudando, e se ferra no final.

Java na beira do colapso? Nunca meu amigo. Não mesmo. A unica coisa ruim é a curva de aprendizado java.

Tem profissional meia boca? tem. Mas quem contrata eles normalmente? Consultorias meia boca.

djDufu:

1 - Há muito profissional meia boca.

djDufu:

3 - Nunca se chega a um consenso de qual é o melhor e que caminho seguir.

djDufu:

4 - Muito profissionais são early adopter…

djDufu:

Tive uma experiência, onde o projeto inicio com uma equipe, alavancou com outro e acabou no meio com outra, resultado disso um aplicativo impossível de se dar manutenção.

Nunca

Sim, entendo a opnão de vocês mas já vi muitos caso em quem um determinado profissional, se aperfeiçoou em um determinado framework e vai para uma outra empresa onde nesta se utiliza outro o profissional tem que se adptar a este novo cenário, isso vc disse quanto a curva de aprendizado.

Porém não seria melhor se tivessemos apenas um e que estivesse em constante melhoramento pela cominidade desenvolvedora ? tipo o JSF por exemplo. Assim teriamos somente ele e não os diversos MVC´s que há por ai.

Quero dizer um framework unico, que tivesse o melhor de vários frameworks, será que isso seria possivel ? Estamos maduros para isso?

abs,

Acho que há espaço para todas linguagens e todos tipos de programadores.

djDufu:

Sim, entendo a opnão de vocês mas já vi muitos caso em quem um determinado profissional, se aperfeiçoou em um determinado framework e vai para uma outra empresa onde nesta se utiliza outro o profissional tem que se adptar a este novo cenário, isso vc disse quanto a curva de aprendizado.

Porém não seria melhor se tivessemos apenas um e que estivesse em constante melhoramento pela cominidade desenvolvedora ? tipo o JSF por exemplo. Assim teriamos somente ele e não os diversos MVC´s que há por ai.

Quero dizer um framework unico, que tivesse o melhor de vários frameworks, será que isso seria possivel ? Estamos maduros para isso?

abs,

Isso, eticamente, é errado. Qualquer um cria o MVC que se adequa ou que quiser, com os propositos que quiser. Agora existe tendencia de mercado e profissional - na qual alguns frameworks nao fazem parte. E sem contar que é como uma competição entre cada framework desses.

Sempre que há maior competição é maior evolução, também.

O facto do projeto não ser entendido porque entre nele a meio caminho nada tem a haver com o java. O projeto pode ter sido mal desenhado para começo de conversa - um frankeinstien - ou o cara que entra pode perceber muito pouco de OO para entender o modelo.

Frameworks não são um problema, são um solução. Se vc aprendeu a usar um , aprende a usar outro. O Java é proeficiente em frameworks porque o Java é uma plataforma tecnologia e não uma plataforma comercial. Ele dá as ferramentas básicas para vc criar o que quiser. Em .NET a microsoft cria as ferramentas que ela quer e amarra o framework a isso ( para começo de converça amarra ao Visual Studio). Não é justo comparar as duas. E se fossemos comparar então o fato de existirem menos frameworks em .NET é um ponto contra e não um ponto a favor do .NET.

.NET não tem servlets, então um banco de coisas que vc faz com servlets e filtros em NET vc não faz ( ou já existe pronto o que é o mesmo que dizer que vc não faz). Em cima disso temos taglibs e tagfiles. Só ai temos uma miriade de frameworks. Junte ainda o JSF e aumenta ainda mais. O .NET tem algo semelhante ao JSF. Tudo bem que é evoluido, mas não facilita as operações básicas que em Java são triviais com servlets , filtros, etc… É só um exemplo, mas mostrar que existem muitos frameworks em Java porque o Java os permite.

-Java, porque vc tem tantos frameworks ?
-Porque eu posso.

Framewroks são muitos mas OO é só uma. Qualquer um que saiba OO sabe usar qualquer framework em qualquer plataforma java.
Pode não ser muito proeficiente, mas se sabe OO vai aprender depressa.

Então acho que o problema está no design do projeto e nas capacidades dos profissionais mais do que na linguagem ou nos frameworks.

Boa Sergio, compartilho com sua opnião…

Mas por que as empresas ainda são meios desconfiadas com o Java, serão os profissionais ??? o que poderia ser ???

Em são paulo, principalmente na área em que trabalho, são poucas as empresas que inicam novos projetos em Java, graças a Deus que aqui na Marítima estou conseguindo espaço e pouco a pouco quebrando paradigmas com a linguagem.

abs,

djDufu:

Boa tarde a todos!
1 - Há muito profissional meia boca.
2 - Diversos especialista e diversos framework.
3 - Nunca se chega a um consenso de qual é o melhor e que caminho seguir.
4 - Muito profissionais são early adopter…

concordo com o Rubem: isso ocorre com outras tecnologias, não se restringe só a java.
a cada dia que passa, que mais tecnologias aparecem, novas idéias são lançadas
cada vez mais tenho certeza que ainda estamos na pré-história da informática e que
muitas outros frameworks, metodologias, conceitos ainda estão por vir.

na minha opnião, estamos apreendendo a desenvolver software, e enquanto
não encontramos a solução ideal… muitas ferramentas, tecnologias ainda vão ser testadas…

djDufu:

Boa Sergio, compartilho com sua opnião…

Mas por que as empresas ainda são meios desconfiadas com o Java, serão os profissionais ??? o que poderia ser ???

Em são paulo, principalmente na área em que trabalho, são poucas as empresas que inicam novos projetos em Java, graças a Deus que aqui na Marítima estou conseguindo espaço e pouco a pouco quebrando paradigmas com a linguagem.

abs,

Simples, existem soluções mais comodas para a maioria dos problemas. Desktop? Larga um delphi ou VB. Acha profissional mais barato.

Migração? Ah, pra que mexer no que já está funcionando?

Novos projetos? Vamos fazer do jeito mais “barato” possivel.

Mas eu tenho visto muita coisa nova em java surgindo, não acho que ás empresas sérias prefiram outras linguagens. As meia boca sim, elas querem usar ate clipper no lugar de java.

Isso é problema de programadores de framework. Que ao invés de conhecer o conceito (MVC por exemplo), vão direto usar framework e não sabem como as coisas funcionaram por baixo do pano. Quando você conhece o conceito, “aprender” um novo framework é algo relativamente simples.

Isso seria bom, mas é algo utópico. Seria perfeito usar as idéias boas de todos frameworks em um único, mas a realidade é completamente diferente, infelizmente.

Mas sobre Java estar a beira de um colapso, eu sinceramente acredito que não. Eu acho que a JVM vai ganhar força cada vez mais, principalmente com novas linguagens sendo encorporadas (como JRuby).
Problemas em projetos podem acontecer com qualquer linguagem. A culpa disso não é da linguagem, e sim das metodologias e das pessoas envolvidas no projeto.

A meu ver este problema não está diretamente relacionado à linguagem/tecnologia aplicada.

Na verdade, o problema está na Gerencia dos Projetos.

Como vc mesmo disse, ah muitos profissionais ‘meia boca’ no mercado, e porque não gerentes mal preparados também!?
Infelizmente no Brasil temos que conviver com isso diariamente.

Alocação de recursos, tecnologia e patterns, arquitetura de softwares, gestão, analise de riscos, planejamento, cronogramas, knowledge base… deveriam ser premissas em qualquer tipo de projeto, independente se o resultado final for um ‘Hello World’, ou grandes aplicações distribuídas…

Lógico que existem excelentes Coordenadores e Gerentes.
Mas a camaradagem profissional (conhecida popularmente como QI, ou ainda Indicação), pode ser a grande responsável por existir tantos profissionais regulares em cargos de maior peso dentro das empresas.

Partindo dessas afirmativas, concluo que não apenas Java pode estar a beira de um colápso. Mas todas as linguagens estão sujeitas a isso.
Tudo depende de planejamento…

Mas felizmente não me preocupo com isso.
Acho que a enorme concorrência que existe hoje consegue tomar conta desse problema.
Os profissionais estão mais ligados em qualificação, ou pelo menos deviam.
Com certeza estes serão os sobreviventes dessa nova 'Era da Informação"…

Abraços…

Tem quem aceite os custos de um projeto em linguagem meia boca com equipe meia boa
Tem quem tenha lucro usando linguagem MICRO$OFT e tem quem seja obrigado a usar JAVA ou C
Tem todo tipo de projeto pra todo tipo de profissional.

Hoje em dia nem posso dizer se amanha vou estar trabalhando com Java ou MS ou mesmo voltar pro Clipper ou Delphi as coisas mudam numa velocidade enorme e só posso dizer a bola que levantar ou eu chuto ou vai faltar a grana pro combustível da motoca

djDufu:

Boa Sergio, compartilho com sua opnião…

Mas por que as empresas ainda são meios desconfiadas com o Java, serão os profissionais ??? o que poderia ser ???

Em parte sim. A categoria de java-fajutos que fingem saber java puxa a qualidade para baixo. O cara que vê isso entende que é muito esforço para pouco resultado. Por outro lado as empresas não entendam a filosofia java e acham que todas as linguagens são iguais.
Java requer um esforço para vc construir as bases do seu programa, mesmo que use algum framework vc tem que “ligar as pontas”.
(connect the dots / plumbing). E isso feito em todos os projetos é um atrazo de vida. Java é muito poderoso, poderoso de mais se pensarmos assim. A ideia é que vc cosntrua uma base de objetos que vc irá reutilizar depois. Isso fara os projetos futuros terem - com o mesmo prazo - ter mais tempo para outros detalhes. Aos poucos vc vai desafogando o processo e no fim vc cria uma aplicação em muito pouco tempo tendo mais tempo para atender os gostos dos usuários. Ou seja, mais tempo para incluir valor no produto. E é io valor que o cliente paga. É isso que o fará volta para pedir outro software. Mas as empresas não enxergam este mecanismo e isso pesa na qualidade nos projetos da mesma forma pq o cara é obrigado a criar tudo do zero toda a hora e nunca tem tempo para fazer melhor , mais limpo, etc…
Dito isto, os profissionais têm culpa por não educar as empresas nesta estratégia, e as empresas têm culpa por não os querer ouvir.

No fim, todo o mundo pode ser culpado.

Rubem Azenha:

djDufu:

1 - Há muito profissional meia boca.

O mesmo ocorre com todas as outras tecnologias

djDufu:

3 - Nunca se chega a um consenso de qual é o melhor e que caminho seguir.

O mesmo ocorre com todas as outras tecnologias

djDufu:

4 - Muito profissionais são early adopter…

O mesmo ocorre com todas as outras tecnologias

djDufu:

Tive uma experiência, onde o projeto inicio com uma equipe, alavancou com outro e acabou no meio com outra, resultado disso um aplicativo impossível de se dar manutenção.

O problema aí pode não ser a tecnologia em si e sim como ela foi aplicada. Sem nenhum padrão de desenvolvimento, boas práticas, etc, qualquer aplicação fica impossível de se dar manutenção se for feito por equipes diferentes em épocas diferentes. Isso não é exclusivo da plataforma Java.

Nunca

Graças a Deus. Já imaginou se todos entrassem em consenso sobre o EJB2.1?

Essa pergunta não era para ser feita aqui… e sim na comunidade .NET.

djDufu:

… se aperfeiçoou em um determinado framework e vai para uma outra empresa onde nesta se utiliza outro o profissional tem que se adptar a este novo cenário…

Concordo com você… Java está cada vez mais confuso, cheio de API’s e interfaces (maior gambiarra inventada pra fazer de conta que existe herança múltipla e etc) que niguém entende…

O cara que sabe Java não sabe nada… O cara tem é que saber Hibernate e mais 500 mil siglas… Eu já usei frameworks para banco de dados, resolvi criar minha própria API que funciona muito melhor que Hibernate… Posso dizer isso para conseguir emprego??? Não!! Tem que saber Hibernate! Não Java!!! O cara que sabe Java é um coitado que sabe criar classes… Java não é nada, frameworks e API’s são tudo!!! Naõ adianta você fazer chover com Java para empresas… Tem que decorar siglas… Por isso nem penso em ser empregado como “programador/desenvolvedo/entendedor??” Java.
Vou ter que fazer mil cursinhos pra provar que tenho capacidade de fazer alguma coisa… .

Tu podes provar que tem capacidade de inumeras formas. Se não estás tendo o sucesso desejado pode ser por razões que ‘mil cursinhos’ não resolvam. Tenho colegas que passaram a ter mais sucesso quando mudaram o visual (cabelo, roupa), foram para o exterior por um tempo, participaram de algum projeto open-source ou mesmo escrevendo para um blog ou dando palestras em mini-eventos. Não digo que vc não toma banho, nada disso, mas “provar que tem capacidade” se faz depois q se começa a trabalhar, antes disso é a arte de vender o peixe, que é completamente diferente. Pense nisso.

Agora eu vejo que algumas reclamações são por problemas “no trabalho” com java. Eu posso dizer que java é ruim pq vivo trabalhando com java 1.3 ?

Ricna:

djDufu:

… se aperfeiçoou em um determinado framework e vai para uma outra empresa onde nesta se utiliza outro o profissional tem que se adptar a este novo cenário…

Concordo com você… Java está cada vez mais confuso, cheio de API’s e interfaces (maior gambiarra inventada pra fazer de conta que existe herança múltipla e etc) que niguém entende…

O cara que sabe Java não sabe nada… O cara tem é que saber Hibernate e mais 500 mil siglas… Eu já usei frameworks para banco de dados, resolvi criar minha própria API que funciona muito melhor que Hibernate… Posso dizer isso para conseguir emprego??? Não!! Tem que saber Hibernate! Não Java!!! O cara que sabe Java é um coitado que sabe criar classes… Java não é nada, frameworks e API’s são tudo!!! Naõ adianta você fazer chover com Java para empresas… Tem que decorar siglas… Por isso nem penso em ser empregado como “programador/desenvolvedo/entendedor??” Java.
Vou ter que fazer mil cursinhos pra provar que tenho capacidade de fazer alguma coisa… .

1 - Todas essas APIs do Java é que são o charme do Java. Justamente por permitir tanta diversidade ´que surguiram coisas como Hibernate, Struts, Spring, JSF e tudo mais de legal que o Java tem. Algumas pessoas preferem alguns grameworks e apis. Outras preferem usar outras. Alguém acha algo ruim e faz melhor. Qual o mal disso?

2 - A curva de aprendizado é mesmo grande. Dá trabalho, mas compensa.

3 - Eu trabalho como “programador/desenvolvedo/entendedor??” e me sinto feliz. Isso não é uma coisa ruim. Se você não está feliz, talvez seja melhor trocar de tecnologia. ou quem sabe de área. Já pensou no .Net ou Ruby on Rails?

4 - Cara, não me leve a mal. A critica é apenas construtiva. Cuidado ao dizer que seu trabalho é melhro que o hibernate. Você simplesmente está dizendo que fez um trabalho muito melhor que TODA A COMUNIDADE que cuida do Hibernate. Isso passa uma impressão de que você é arrogante, coisa que tenho certeza, VOCÊ NÂO É! O que você fez talvez seja o melhro PRA VOCÊ, mas será que é pra mim? Ou para o colega?

5 - Pra provar capacidade não precisa fazer mil cursinhos. Na verdade penso que curso é bom, mas mostra que você tem interesse, não quais seus resultados. Porque ao invés de fazer mil cursos, você não minsitra mil cursos? Por que não coloca seu framework de persistência pra comunidade? Quem sabe não emplaca como o hibernate? porque não fazer softwares, participar de projetos livres, dar palestras, escrever um blog, escrever um livro, uma apostila, ajudar seus colegas, fazer um bom trabalho na empresa onde você trabalha… Você mostra sua capacidade muito mais PRODUZINDO conhecimento que ABSORVENDO.

Abraço a todos

Olá pessoal!

Concordo com vocês (josenaldo e peczenyj) plenamente. Fui um exagerado justamente para botar lenha nessa questão que o autor do tópico levantou.

Exemplifiquei o caso do Hibernate para mostrar que Java é uma coisa… API e Framework é outra…
Dizer que alguém que não conhece determinado framework não pode resolver problemas em Java é errado. Isso é que tentei demontrar…

O nosso amigo levantou essa questão no tópico. Pois no ramo o que vemos são siglas, muito mais que a linguagem de programação. Obviamente isso acontece com todas tecnologias, mas geralmente essas coisas são "mais integradas por definição da plataforma, pelos criadores e se torna PARTE e não um “anexo que vc escolhe”…Quero dizer, Java é Java, Hibernate é Hibernate. Alguém falou que não gosto de Java… Nada disso! Adoro Java em muitos aspectos e nem essa depêndencias me fazem mudar meu gosto, afinal é só ignorá-las em último caso. Realemte prefiro C++ mas só pela linguagem, pois como um colwega falou aí… Essas API’s dão um charme também, eu não diria charme, diria oportunidades.

Quanto aos “cursinhos”, eu adoro aprender coisas novas e acho isso muito bom. Mas por favor… O que estava tentando discutir aqui é o que o tópico tenta tratar.

Desculpem se passei uma impressão errada, porém vocês não colocaram a opinião quanto ao assunto e somente tomaram um posição defensiva quanto a plataforma…Que não foi isso, foi uma crítica a maneira de conceberem ela por aí…

Mas e aí? Java é dependete de framework ou API? Java eu sei que é não é… Mas e quem trabalha com Java? Se JPA for pro buraco (sei que isso é praticamente impossível, mas para ilustrar o problema)…O que acontece? O que as empresas adeptas vão fazer? São capazes de mudarem de linguagem por causa do framework! Vcs não concordam com isso?

Valeu pessoal! Só para deixar claro…Concordo com vocês no que colocaram… Mas e quanto a essa dependência que gera esse “colapso” (que é o assunto do tópico) o que vocês tem a dizer?

Editei para acrescentar mais uma questão…Fora framework e API’s… Temos as IDE’s. Programador Java deve ser programador Java mesmo sem saber usar o Netbeans ou Eclipse.

Eu particularmente adoro o NetBeans e simplesmente nem dou chance para o Eclipse pois me sinto satisfeito com o Netbeans…Poderia usar VI ou Notepad também… Mas vejam que se alguém entende de NetBeans não quer dizer que entenda de Java , e se entende de Java não quer dizer que enteda de NetBeans.

A depêndencia é tão grande que vai até para a IDE.

E desde quando isso é ruim? :shock:

E desde quando isso é ruim? :shock:

Olá! Acho que ele não está falando que é ruim, está dizando que é dependente dessas coisas…

Cara java vai durar muito ainda…
haha, na empresa mesmo tem dezenas de projetos em java, jsf, migrando de linguaem pra outra…
nao tem motivos para ter um colapso…
eu acho que quanto mais frames, melhor… cada dia fica mais facil e flexivel pra programar, você tem opções, imagina se nao tivesse JSF ? ia ficar programando aquele lixo de Servlet o dia todo, haha, imagina senao tivesse o Hibernate, ia ter q ficar usando JDBC, eca… soh tem a melhorar… pode ter certeza… pode ser citado centenas de exemplos como eh bom ter todos esses frames no mercado… e quanto mais melhor…

E desde quando isso é ruim? :shock:

Olá! Acho que ele não está falando que é ruim, está dizando que é dependente dessas coisas…

Bom, não concordo muito. A plataforma Java padrão de hoje já contém a mairia das coisas pra se desenvolver aplicações básicas. O java já possui padrão para framework web, persistência, interfaces gráficas para desktop… e uma série de coisas mais. Não há necessidade de ser dependente de vários frameworks se a plataforma já especifica o padrão.

Exatamente o que acho! Mas não é o que o pessoal faz por aí…E contrariando o “default” as tecnologias desenvolvidas atualmente usam frameworks e não Java. O que vemos são especialistas em frameworks (isso não é ruim, antes que alguém entenda errado) e não programdores Java… Afinal de contas o programado Java, que trabalha com frameworks, entende mesmo é de framework, pois para usar a linguagem mesmo sobra só a declaração de classes e regras de negócios que podem ser feita em UML. Mais um wizzard que estava vendo por aí em nem precisa saber que existe GUI para ser programador Java.

Mas o que gostei do seu comentário é justamente que já existe um padrão, mas não é o “padrão” usado.

Sim, mas isso já mudou bastante. Geralmente, o que determina o uso de uma api padrão java é a sua eficiência. Como exemplo disso temos o JSF (que parece estar sendo muito bem aceito) e o JPA. Há também o spring, que é muito bom no que faz. E o j2ee está caminhando na direção dele. As coisas estão mudando pra melhor.

"

Você tá ficando é louco por falar isso, rsrsrs.

Frameworks deixam java 10000x mais dificil. Ao menos pra mim.

Nao basta saber java, voce tem que saber Hibernate, Struts, MVC em geral, JSF, JSP no minimo.

Agora vá aprender um delphi. Só precisa saber como funciona o Delphi e alguns componentes. (Que dá pra advinhar varios metodos).

Isso que nao gosto em Java, só isso.

PS: DUVIDO que a sua empresa só estava procurando alguém que soubesse hibernate. O principal deveria ser isso, mas aposto que tinha muita coisa por trás, rsrsrs.

"

marcosalex:

Sergio Figueras:

Agora vá aprender um delphi. Só precisa saber como funciona o Delphi e alguns componentes. (Que dá pra advinhar varios metodos).

Isso que nao gosto em Java, só isso.

PS: DUVIDO que a sua empresa só estava procurando alguém que soubesse hibernate. O principal deveria ser isso, mas aposto que tinha muita coisa por trás, rsrsrs.

Eu quis dizer que programar em cima de um framework é muito mais fácil do que progrmar “na unha” em Java. Bom, particularmente é opinião. Em Delphi a gente programa em VCL utilizando componentes de acesso a dados DBX ou BDE. Nada mais são do que frameworks. A diferença é que não existem tantas opções, é onde talvez o número de frameworks que confunde. Esses dias estava pensando como o Hibernate na verdade faz o acesso a dados muito parecido com o Delphi, já que os componentes de acesso a dados em Delphi nada mais são que classes para acesso a dados.

Sobre a empresa, precisávamos de recursos avançados do Hibernate para fazer um ajuste fino no nosso acesso a dados pra ganhar performance. Precisávamos de um especialista em Hibernate que não soubesse só o básico. CLARO que pra saber isso, o cara tinha de manjar de JDBC e ( :roll: ) Java, além de entender de servidores. Fluência em inglês também era necessária, já que a maioria do nosso suporte é nos EUA.

Poxa cara! então me contratam! rsrsrs. So nao conheço bem e Java pra WEB.

Mas concordo com voce em um ponto, tudo isso é muito bom, mas tem um problema simples - configuração. Acho que o maior problema em todos os frameworks java é a quantidade de configurações e para uni-los em uma aplicação.

Bom, isso se deve ao fato do java possuir um belo e extenso conjunto de bibliotecas desenvovidas pela comunidade.

Quanto à sua colocação, vamos lá:
1 - O java possui hoje padrão para ORM, e o hibenate é apenas uma das “implementações” existentes para JPA.
2 - Struts foi o pioneiro nos frames web MVC para java. Os mesmos foram um grande avanço ao que existia na época, devido à bagunça que era desenvolver com asp, php, etc. Como o struts foi o pioneiro, a maioria do pessoal por aí está usando um frame web mais novo, como JSF. Mexer com struts 1.x é mais para dar manutenção em sistemas legados.
3 - Se você não quer conhecer MVC, quer o que então? :shock:
4 - JSP é difícil?

Não sou um shiita defensor do java. Mas ultimamente parece que tudo é culpa dele. E graças à esse monte de frames pra java, é possível fazer muita coisa com ele hj em dia.

Bom, isso se deve ao fato do java possuir um belo e extenso conjunto de bibliotecas desenvovidas pela comunidade.

Quanto à sua colocação, vamos lá:
1 - O java possui hoje padrão para ORM, e o hibenate é apenas uma das “implementações” existentes para JPA.
2 - Struts foi o pioneiro nos frames web MVC para java. Os mesmos foram um grande avanço ao que existia na época, devido à bagunça que era desenvolver com asp, php, etc. Como o struts foi o pioneiro, a maioria do pessoal por aí está usando um frame web mais novo, como JSF. Mexer com struts 1.x é mais para dar manutenção em sistemas legados.
3 - Se você não quer conhecer MVC, quer o que então? :shock:
4 - JSP é difícil?

Não sou um shiita defensor do java. Mas ultimamente parece que tudo é culpa dele. E graças à esse monte de frames pra java, é possível fazer muita coisa com ele hj em dia.

Olá neófito,

Bem, eu noto que você não é nnehum xiita defensor do Java. Eu gosto do Java. O que eu questiono é só a quantidade de frameworks pra usar e a quantidade de configurações necessárias. Nem pra configurar um servidor slackware de um cluster robusto é assim, rsrsrs. Existe muita coisa para se fazer em Java que não tenha a ver com Web, eu basicamente, detesto programar pra BD e web, mas como é o caminho do mercado - temos que seguir.
JSP não é nem um pouco dificil. Mas eu não sei porque (embora eu conheça bem HTML) está sendo mais dificil pra mim do que ter aprendido Java, swing, e design patterns, rsrsrs. Talvez seja porque minha cabeça está cheia e minha SCJP é amanhã, rsrs.

Grato! =)

Sergio Figueras:

djDufu:

Boa Sergio, compartilho com sua opnião…

Mas por que as empresas ainda são meios desconfiadas com o Java, serão os profissionais ??? o que poderia ser ???

Em são paulo, principalmente na área em que trabalho, são poucas as empresas que inicam novos projetos em Java, graças a Deus que aqui na Marítima estou conseguindo espaço e pouco a pouco quebrando paradigmas com a linguagem.

abs,

Simples, existem soluções mais comodas para a maioria dos problemas. Desktop? Larga um delphi ou VB. Acha profissional mais barato.

Migração? Ah, pra que mexer no que já está funcionando?

Novos projetos? Vamos fazer do jeito mais “barato” possivel.

Mas eu tenho visto muita coisa nova em java surgindo, não acho que ás empresas sérias prefiram outras linguagens. As meia boca sim, elas querem usar ate clipper no lugar de java.

Java não é o supra sumo do desenvolvimento de software, e logo não é sinonimo de projeto caro, ou que tudo que é desenvolvido em Java é melhor. Ou seja, qualquer tecnologia pode gerar ótimos projetos e se ganhar muito bem com eles… tudo vai depender da análise e aplicação da tecnologia em cada projeto. Não me interessa se é Java, .Net, Delphi e o caramba… o que me importa é que ele atenda as expectativas do cliente e me faça ganhar dindin… que na realidade é o objetivo…

Té mais.

sergiotaborda:

djDufu:

Boa Sergio, compartilho com sua opnião…

Mas por que as empresas ainda são meios desconfiadas com o Java, serão os profissionais ??? o que poderia ser ???

Em parte sim. A categoria de java-fajutos que fingem saber java puxa a qualidade para baixo. O cara que vê isso entende que é muito esforço para pouco resultado. Por outro lado as empresas não entendam a filosofia java e acham que todas as linguagens são iguais.
Java requer um esforço para vc construir as bases do seu programa, mesmo que use algum framework vc tem que “ligar as pontas”.
(connect the dots / plumbing). E isso feito em todos os projetos é um atrazo de vida. Java é muito poderoso, poderoso de mais se pensarmos assim. A ideia é que vc cosntrua uma base de objetos que vc irá reutilizar depois. Isso fara os projetos futuros terem - com o mesmo prazo - ter mais tempo para outros detalhes. Aos poucos vc vai desafogando o processo e no fim vc cria uma aplicação em muito pouco tempo tendo mais tempo para atender os gostos dos usuários. Ou seja, mais tempo para incluir valor no produto. E é io valor que o cliente paga. É isso que o fará volta para pedir outro software. Mas as empresas não enxergam este mecanismo e isso pesa na qualidade nos projetos da mesma forma pq o cara é obrigado a criar tudo do zero toda a hora e nunca tem tempo para fazer melhor , mais limpo, etc…
Dito isto, os profissionais têm culpa por não educar as empresas nesta estratégia, e as empresas têm culpa por não os querer ouvir.

No fim, todo o mundo pode ser culpado.

É possível fazer isso com outras tecnologias, .Net por exemplo.

Té mais.

celsomarcos:

Sergio Figueras:

djDufu:

Boa Sergio, compartilho com sua opnião…

Mas por que as empresas ainda são meios desconfiadas com o Java, serão os profissionais ??? o que poderia ser ???

Em são paulo, principalmente na área em que trabalho, são poucas as empresas que inicam novos projetos em Java, graças a Deus que aqui na Marítima estou conseguindo espaço e pouco a pouco quebrando paradigmas com a linguagem.

abs,

Simples, existem soluções mais comodas para a maioria dos problemas. Desktop? Larga um delphi ou VB. Acha profissional mais barato.

Migração? Ah, pra que mexer no que já está funcionando?

Novos projetos? Vamos fazer do jeito mais “barato” possivel.

Mas eu tenho visto muita coisa nova em java surgindo, não acho que ás empresas sérias prefiram outras linguagens. As meia boca sim, elas querem usar ate clipper no lugar de java.

Java não é o supra sumo do desenvolvimento de software, e logo não é sinonimo de projeto caro, ou que tudo que é desenvolvido em Java é melhor. Ou seja, qualquer tecnologia pode gerar ótimos projetos e se ganhar muito bem com eles… tudo vai depender da análise e aplicação da tecnologia em cada projeto. Não me interessa se é Java, .Net, Delphi e o caramba… o que me importa é que ele atenda as expectativas do cliente e me faça ganhar dindin… que na realidade é o objetivo…

Té mais.

Olá,
Tambem acho que toda a tecnologia tem a sua aplicação e se for bem aplicada, vai tudo numa boa. (Só discordo disso com o clipper, rsrsrs). Java é sinonimo de projeto mais caro sim, se você quer ter um projeto X funcionando de uma forma boa em Java, você tem que contratar um bom programador. Agora vá ver quanto que custa um bom programador Java em relação a um bom programador PHP, por exemplo. Em termos de custo, programadores java são mais caros (tanto quanto os de .NET) e são mais dificeis de achar. Em certos projetos java se torna uma linguagem mais cara por causa do tempo, vá fazer uma aplicação que tenha que rodar um editor 3D muito rapidamente em Java e vá fazer em C++, o tempo de pesquisa a ser gasto em como fazer as coisas corretamente em Java é maior .Sem contar que pra achar um programador Java3D, é o Ò.

Agora se você está falando de programação comercial e só desse universo, concordo com isso.

Valeu!

Recentemente vi uma palestra do JavaOne sobre novas “features” do Java 7 e isso sim me deixou assustado!

Tive duas grandes impressões:

1. Parece que Java caminha ao aposto das novas linguagens e quer se tornar ainda mais verboso. Esse negócio de “modules” eu não engoli muito bem. Tudo bem que vem corrigir uma deficiência da linguagem, mas vai ser mais código ainda a ser feito.

2. Java tá virando sinonimo de “programação orientada a anotações”. Eu gosto pra caramba de anotações, mas ao meu ver estão exagerando nesse negócio. É claro que vem pra ajudar, mas algumas coisas eu achei exagero. Eu não me lembro em detalhes, mas eu lembro que tinha uma anotação relacionada ao “pool de Strings” que não entendi qual a utilidade daquilo…

Alguém mais viu essa palestra ou tem acompanhado o que vai rolar no Java 7 pra dar suas opiniões?

lavh:

Recentemente vi uma palestra do JavaOne sobre novas “features” do Java 7 e isso sim me deixou assustado!

Tive duas grandes impressões:

1. Parece que Java caminha ao aposto das novas linguagens e quer se tornar ainda mais verboso. Esse negócio de “modules” eu não engoli muito bem. Tudo bem que vem corrigir uma deficiência da linguagem, mas vai ser mais código ainda a ser feito.

2. Java tá virando sinonimo de “programação orientada a anotações”. Eu gosto pra caramba de anotações, mas ao meu ver estão exagerando nesse negócio. É claro que vem pra ajudar, mas algumas coisas eu achei exagero. Eu não me lembro em detalhes, mas eu lembro que tinha uma anotação relacionada ao “pool de Strings” que não entendi qual a utilidade daquilo…

Alguém mais viu essa palestra ou tem acompanhado o que vai rolar no Java 7 pra dar suas opiniões?

Olá lavh,

Com essa correria da SCJP nao to com tempo pra nada. Será que vc pode disponibilizar uns links (caso tenha e caso nao seja pedir demais) sobre as novas features do Java 7 com detalhes?

Grato!!!

Também estou muito preocupado com a linguagem Java. Essas novas features são realmente estranhas, já que a linguagem poderia ser simplificada.

Mas, recentemente, andei pesquisando sobre JRuby, e encontrei um ótimo post no blog do criador do mesmo, falando sobre o futuro da plataforma Java. É muito bom ver que o pessoal do Da Vinci Machine Project está fazendo um ótimo trabalho, com, por exemplo, o novo bytecode invokedynamic (o Ola Bini fez uma apresentação bem interessante sobre o assunto).

Resumindo: a linguagem java está indo para o caminho totalmente oposto do mercado, já a plataforma (jvm), está ficando muito, mas muito melhor mesmo!

Sergio Figueras:

lavh:

Recentemente vi uma palestra do JavaOne sobre novas “features” do Java 7 e isso sim me deixou assustado!

Tive duas grandes impressões:

1. Parece que Java caminha ao aposto das novas linguagens e quer se tornar ainda mais verboso. Esse negócio de “modules” eu não engoli muito bem. Tudo bem que vem corrigir uma deficiência da linguagem, mas vai ser mais código ainda a ser feito.

2. Java tá virando sinonimo de “programação orientada a anotações”. Eu gosto pra caramba de anotações, mas ao meu ver estão exagerando nesse negócio. É claro que vem pra ajudar, mas algumas coisas eu achei exagero. Eu não me lembro em detalhes, mas eu lembro que tinha uma anotação relacionada ao “pool de Strings” que não entendi qual a utilidade daquilo…

Alguém mais viu essa palestra ou tem acompanhado o que vai rolar no Java 7 pra dar suas opiniões?

Olá lavh,

Com essa correria da SCJP nao to com tempo pra nada. Será que vc pode disponibilizar uns links (caso tenha e caso nao seja pedir demais) sobre as novas features do Java 7 com detalhes?

Grato!!!

Ola Sérgio,

no site do JavaOne: http://developers.sun.com/learning/javaoneonline/index.jsp tem várias palestras que falam mais dessas novidades. Garimpando lá você acha muita coisa legal! Recomendo fortemente a palestra do Joshua Bloch

[]'s

neófito:

Resumindo: a linguagem java está indo para o caminho totalmente oposto do mercado, já a plataforma (jvm), está ficando muito, mas muito melhor mesmo!

Concordo 100% :lol:

Fala galera,

Quando abri esse tópico não tinha a em mente colocar em pauta a discução sobre qual é a melhor linguagem e sim discutir o futuro do Java, pois li diversos artigos onde grandes especialistas diziam que o problema do Java era exatamente o que retratei aqui, cada um atirando para um lado criando frameworks a torto e a direita.

Eles dizem também o seguinte, que ja é muito dificil formar um bom profissional em Java, ainda mais agora que o programador sai de uma escola com conhecimento de orientação a objetos e java, depois tem que escolher um framework para trabalhar e rezar para este sempre ter continuidade e aceitação, senão, dale nova curva de aprendizagem.

É claro que todo bom profissional que se preze está em constatnte aprendizado, mas este não é o foco da discussão.

É claro também, que este bom profissional não teria muita dificuldade em aprender novos frameworks já que tem como base muito escencia e conhecimento.

A questão basica é que no meu ponto de vista a grande dificuldade para um profissional é quando ele migra de empresa ou projeto, onde que neste novo projeto a estrutura do projeto é totalmente diferente a que ele havia aprendido, e quando digo estrutura quero dizer frameworks.

Seria muito mais simples, se a própria comunidade escolhe-se os melhores e estes seriam utilizados pelo restante, algo como um horizonte, vemos aqui no forum diversos tópicos de pessoas querendo aprender Java e frameworks e ficam perdidas com diversas opniões.

abraços…

Como falaram, se você souber o que o framework faz fica fácil aprender a usar outro quando necessário

Um dos problemas de java ter virado uma linguagem de frameworks se deve as consultorias que pedem planilhas com experiência específicas nesses frameworks, isso leva os profissionais a pensarem que java funciona assim

Eu acredito que existam os profissionais do como e os profissionais do porque li um artigo assim uma vez e aqui não posso acessar mais porque está bloqueado

Ou seja, tem espaço para os dois tipos de profissionais, se todos quiserem entender o porque do framework fazer tal coisa não tem produtividade, mas se todo mundo apenas aprender a usar vai acabar saindo um sistema que ninguem sabe direito o que foi feito e manutenção depois esqueçe…

Abs

Eu não acho ruim o fato de java ter milhões de frameworks não

Framework oficial pra web só existe um que é o JSF, oq acontece é que muita gente como eu não gosta dele. Felizmente temos diversas opções extras para escolher, já pensou q desgraça seria se só existisse o padrão JSF?

O problema do Java é q pelo menos na minha opinião, não existe nenhum framework web que seja tão bom quanto o Ruby on Rails, é por isso que ficam surgindo outros frameworks por ai, ninguem tá contente com o que já existe e quer algo melhor

O que não falta em Java é gente qualificada pra fazer um framework no nível do Rails, infelizmente isso não acontece, talvez Java esteja realmente ultrapassada para algo como desenvolvimento web ágil

Esperar que um desenvolvedor vá chegar sabendo quais são as políticas, frameworks, metodologias, ferramentas de build, de controle de versão, etc, utilizados em um projeto é uma ilusão.
Vejo por aí vagas exigindo um conjunto de conhecimentos muito específicos, o que acaba restringindo demais os candidatos. Aí o projeto corre o risco de ser suspenso ou é cancelado por falta tem mão de obra. No desespero, são contratados profissionais picaretas que cobram caro e não correspondem às expectativas.

É um problema de gerenciamento: um coordenador de projeto ou um arquiteto deve ter o mínimo de noção para ambientar os desenvolvedores que estão entrando no projeto.
É importante também ter gestores de RH qualificados para a área de TI.

O Java não seria capaz de evoluir, e não seria uma tecnologia tão importante, sem a comunidade, que é capaz de propor alternativas e evoluções, e é capaz também de selecionar as melhores soluções. O desenvolvedor Java tem que se manter informado e tem que saber escolher.

Quem tem a cultura Delphi / Microsoft e migra para Java sofre um bocado até entender que Java tem “ecosistema”, que é auto-sustentável, independente de decisões e de visão de mercado de uma empresa.

victorcosta:

Eu não acho ruim o fato de java ter milhões de frameworks não

Framework oficial pra web só existe um que é o JSF, oq acontece é que muita gente como eu não gosta dele. Felizmente temos diversas opções extras para escolher, já pensou q desgraça seria se só existisse o padrão JSF?

O problema do Java é q pelo menos na minha opinião, não existe nenhum framework web que seja tão bom quanto o Ruby on Rails, é por isso que ficam surgindo outros frameworks por ai, ninguem tá contente com o que já existe e quer algo melhor

O que não falta em Java é gente qualificada pra fazer um framework no nível do Rails, infelizmente isso não acontece, talvez Java esteja realmente ultrapassada para algo como desenvolvimento web ágil

1 - RoR pode ser executado dentro de uma JVM
2 - JBoss Seam e WebBeans são respostas à altura do Rails
3 - Ruby é uma linguagem com tipagem fraca, pode ser boa para desenvolver rapidamente, mas projetos que evoluem e que aumentam em complexidade apresentam sérios problemas de manutenção em médio ou em longo prazo - isso não é minha opinião, ou uma sensação: é matemática. Nada contra, existem situações onde é tolerável reconstruir em vez de reaproveitar, e num caso assim RoR pode ser melhor do que Java.

1 - e…? Pode ser rodado, mas o programador vai ter q aprender Ruby, do ponto de vista dele não muda nada usar JRuby ou Ruby
2 - WebBeans não conheço, o Seam eu não considero uma resposta à altura e garanto que muita gente pensa o mesmo, alias, o Seam não tem nada haver com RoR, é uma abordagem totalmente diferente
3 - Eu não tenho uma decisão certa sobre se prefiro tipagem fraca ou estatica como java. Gosto de java e do suporte que o Eclipse oferece a ela. O que não dá é Java continuar parada sem evoluir, tem que acompanhar o mercado como C# está fazendo.

Isso é minha opinião e não to mandando ninguem concordar, principalmente no item 3 que é uma questão complicada, Java deve parar para não ficar complicada ou deve evoluir?

rbellia:

victorcosta:

Eu não acho ruim o fato de java ter milhões de frameworks não

Framework oficial pra web só existe um que é o JSF, oq acontece é que muita gente como eu não gosta dele. Felizmente temos diversas opções extras para escolher, já pensou q desgraça seria se só existisse o padrão JSF?

O problema do Java é q pelo menos na minha opinião, não existe nenhum framework web que seja tão bom quanto o Ruby on Rails, é por isso que ficam surgindo outros frameworks por ai, ninguem tá contente com o que já existe e quer algo melhor

O que não falta em Java é gente qualificada pra fazer um framework no nível do Rails, infelizmente isso não acontece, talvez Java esteja realmente ultrapassada para algo como desenvolvimento web ágil

1 - RoR pode ser executado dentro de uma JVM
2 - JBoss Seam e WebBeans são respostas à altura do Rails
3 - Ruby é uma linguagem com tipagem fraca, pode ser boa para desenvolver rapidamente, mas projetos que evoluem e que aumentam em complexidade apresentam sérios problemas de manutenção em médio ou em longo prazo - isso não é minha opinião, ou uma sensação: é matemática. Nada contra, existem situações onde é tolerável reconstruir em vez de reaproveitar, e num caso assim RoR pode ser melhor do que Java.

E dizer que o Ruby/Rails não serve para projetos que evoluem e aumentam em complexidade é FUD, ainda mais quando a “justificativa” é a matemática. Mas, sendo generoso e lhe dando o benefício da dúvida, apresenta o teorema ou fato matemático que prova que o Ruby/Rails não serve pra projetos grandes?

Isso nao é verdade. Ruby é uma linguagem FORTEMENTE tipada.

O meu ponto é que o Java é uma plataforma madura que tem APIs para resolver milhares de problemas de desenvolvimento. É madura o suficiente para não precisar imitar o que outras propostas de linguagem oferecem.

Um programador Java aprende Ruby para aproiveitar os benefícios dessa linguagem, e ao usar JRuby em um projeto tem à sua disposição as APIs bem sucedidas e maduras do Java.

Fora do suporte ao Ruby incorporado no Java isso não é possível.

O Seam/WebBeans são respostas à altura para programadores Java que querem a produtividade do RoR e não querem aprender Ruby. Sim, a abordagem desses projetos é diferente do Ruby.

Outra resposta à altura do RoR é o Grails, que oferece ao programador Java a mesma produtividade, e de novo, sem a necessidade de aprender uma linguagem nova.

Java está no Colapso, Não é verdade, MAS o pensamento de empregar a tecnologia essa sim , está.

Não existe Metodologia e Plano de Projeto.

Exigem demasiadas certificações Java como um atestado de qualificação.
(JÁ DISSE SOFTWARE NÃO É CÓDIGO É REQUISITO), devemos entender os recursos e mapear soluções, para melhor aplicá-las.

Faculdades Privadas ou Públicas não tem parceirias com Empresas de Ponta, e Centro Educacionais em TI são poucos que existem e promovem mini-cursos Gratuito, em São Paulo só conhecedo dois a altura (Globalcode(fiz curso lá) e Caelum (por ouvir falar)).

Palestras e convenções são raras que centralize tal informação sobre o profissional de TI e assunto sobre OpenSource, gostaria de dizer que estive no OPEN TDC e achei uma otima iniciativa ,e foi uma boa atualização por cobrir melhores informações sobre mercado e outras apresentações a tecnologias, entretando as Empresas deveria financiar muitos desses Opens TDCs em parceiras com as mesma, sem custo algum.

As consultorias tem um papel de Marketing importante mas ela se confunde com o cliente por não entender a situação de encaminhar tal profissional para sua atuação frente a complexidade que este vai encarar.Querem um prodígio mas querem pagar um salário de profissional Junior.

Não existe pessoa ruim , existe pessoa mau treinada.

Java é a ponta de um IceBerg para contexto de outras tecnologias (Não trabalhamos só com uma única Maquinas Virtual Java e sim com outras em paralelo e outras aquiteturas) que busca inteligência para serviços e soluções para integrar plataformas ao business plan do cliente.

É entendido que aos profissionais de TI colaboradores esse adqueriram suas praticas e experiencia em projetos anteriores agregarão melhores técnicas, mas seja um começo ou um redesenho de projeto terão que se readequarem para as tendências na otica de negocio de seu cliente, vão criar seus proprios frameworks de soluções, ou se utilizar-se de outras soluções a reaprenderem com ela e suas complexidades, seja vão se reciclarem.

elomarns:

O Ruby, assim como o Java, tem tipagem forte. Experimente executar o comando puts 1 + “1” no irb e veja o resultado. A confusão ocorre porque além da tipagem forte, o Ruby possui tipagem dinâmica, o que muitos presumem ser sinônimo de tipagem fraca.

E dizer que o Ruby/Rails não serve para projetos que evoluem e aumentam em complexidade é FUD, ainda mais quando a “justificativa” é a matemática. Mas, sendo generoso e lhe dando o benefício da dúvida, apresenta o teorema ou fato matemático que prova que o Ruby/Rails não serve pra projetos grandes?

Ok, tipagem dinâmica.
O Ruby não tem tipagem fraca.
Me desculpem pela falta de precisão.

Eu não quero desmerecer o Ruby em favor do Java, o que eu quero é deixar claro que o Ruby, oferece muitas features de produtividade por suportar tipagem dinâmica.
Qualquer projeto que utiliza linguagem com tipagem dinâmica pode apresentar problemas, pois em tempo de desenvolvimento não é possível detectar determinadas inconsistências ao fazer refactoring. Isso é matemático.

Eu não disse que o Ruby não server para projetos grandes. Eu disse que por se basear na tipagem dinâmica podem haver conseqüencias em médio e longo prazo. Eu já conversei com programadores Ruby que afirmam que isso não é um problema, pois existem IDEs capazes de gerenciar o refactoring, e evitar problemas em tempo de execução.

Nossa fiquei muito emocionado, muito feliz em ver alguns posts falando que a culpa de muita coisa é da gerência de projeto.
Eu acho que muita coisa é culpa sim da gerência, da parte comercial e etc.
ufs… q post maneiro!!!

as coisas devem ser iniciadas direito, projetadas direito, programadas direito antes de qualquer coisa.Ah! orçadas direito!!! no fim a linguagem q acaba se dando mal!!! rssssssssss

[]

"

Tudo isso porque por muito tempo se pensou que pessoas muito boas tecnicamente para evoluírem na carreira deveria passar a ocupar um cargo de gerência ou coordenação… resultado?? muitos profissionais que eram bons técnicos se tornaram péssimos gerentes… ainda bem que parece que isso tem mudado …

A produtividade do Ruby não reside unicamente na tipagem dinâmica, ela envolve vários conceitos relacionados ao design da linguagem, como o fato dela ter interface humana, ao invés da interface mínima.

rbellia:

Qualquer projeto que utiliza linguagem com tipagem dinâmica pode apresentar problemas, pois em tempo de desenvolvimento não é possível detectar determinadas inconsistências ao fazer refactoring. Isso é matemático.

Por fim, mais uma vez você afirmou estar apresentando um fato matemático, quando na verdade postou a sua opinião, que é resultado da sua observação. Não estou a desmerecendo, você tem o direito de pensar o que quiser, estou apenas dizendo que a sua opinião, acrescida das opiniões dos programadores Ruby que você conhece, nem de longe constitui um fato matemático.

É isso aí…e ainda temos que considerar a economia $$ que querem fazer num projeto, e o tempo miúdo, que sempre acaba arruinando o programador .

A questão sobre a infinidade de frameworks existentes e que só os fortes e completos ficarão, como já disseram é NATURAL, porém até esperarmos que certos destes frameworks caiam em desuso é complicado para o ponto de vista empresarial, pois gera um alto custo para redesenhar certas aplicações em novos ou “os completos e fortes” frameworks.

É muito fácil para todos nós desenvolvedores ou arquitetos colocarmos a culpa na gerencia ou diretoria, que por questões financeiras acabando adotando tecnologias que não suportam seus negócios.

Não podemos esquecer que muito desta culpa cabe a “nós”, pois muitas vezes desenvolvedores ou arquitetos são consultados para empregar a melhor tecnologia X custo do projeto e empregamos tecnologia ou avançadas demais ou que simplemente atendem o negócio por um certo período.

Não quero fazer o papel de defensor de empresa mesmo por não saberia medir a quantidade de grana que já ganhei para muitos empresários, porém pensando pelo lado de negócio vemos que não é simples escolher tecnologia e profissional.

Mesmo por que não há uma formula básica para se contratar um ótimo profissional, eu acredito muito em intuíção do contratante e ética do profissional, pois já vi casos em que foi contratado “O PROFISSIONAL”, o curriculumo cara tinha mais siglas e simbolos que o alfabeto japones, mas na hora que o bicho pega o cara num rende, é purista demais, não sabe ponderar as coisas com bom senso. Neste caso de quem é a culpa ??? da gerencia ???

abs,

O fato matemático é que uma linguagem de tipagem estática consegue de detectar em tempo de compilação erros que uma linguagem com tipagem dinâmica não consegue. Ou se você preferir é uma diferença fundamental entre estes tipos de linguagem de programação.

Concordo, uma suíte de testes, em qualquer projeto complexo construído com qualquer tipo linguagem, pode detectar problemas oriundos de um refactoring, que ocorreriam em tempo de execução.

Entretando, nenhuma suíte de testes é capaz de garantir que não apareçam erros de programação em tempo de execução.

Se por um lado uma linguagem de tipagem dinâmica oferece maior produtividade, por outro ela demanda maior esforço e atenção na construção dos testes.

Com uma linguagem de tipagem estática é possivel detectar determinados problemas em tempo de desenvolvimento, investindo menos nos testes.

Isso normalmente não é levado em consideração quando afirmam que o Ruby/RoR são mais produtivos que o Java.

O fato matemático é que uma linguagem de tipagem estática consegue de detectar em tempo de compilação erros que uma linguagem com tipagem dinâmica não consegue

public class A{

    public static void main(String [] args){

        int [] x = new int[10];

        x[1099] = 1;

        System.out.println(x[1099]);

    }
}

Uma linguagem estática até pode detectar tais erros, porém ainda pode ter muitos erros em runtime ;-)

E alguns dos erros que só acontecem em runtime numa linguagem estática podem não acontecer numa linguagem dinamica: é o caso da versão em Ruby desse codigo. Se por um lado alguns testes podem ser necessários, por outros alguns testes podem ser desnecessários ;-)

"

O Tópico ainda está de pé ?

8. Bom, acho que o maior problema do meio Java não está no número de alternativas e sim nesse número fazendo exatamente a mesma coisa. Isso é uma sobreposição de funcionalidades, com ganho ínfimo. Mas até aí vai de cada equipe adotar algo que lhe traga melhor benefício.

O ponto da questão não é a pluridade de frameworks ou linguagens e plataformas e sim como as coisas são feitas dentro das companhias. Estamos ficando com um ambiente completamente heterogêneo dentro da mesma plataforma. Absurdo, mas nada conversa com nada, isso é fato !! Salve poucas libs utilitárias, o ganho de ter uma plataforma homogênea foi pro saco !!

Hoje temos aplicações Java que não conversam com a própria linguagem por falta de maturidade das equipes de arquitetura e engenharia de definirem contratos, modelos de coesão, versionamento de serviços, políticas, em fim , uma completa falta de planejamento.

Quantos sistemas nas companhias de vocês fazem extamente as mesmas coisas ? Ex. Consulta a pagamentos. Vai encontrar com JDBC, JPA, EJB-DAO, ActiveRecord - Rails e por aí vai. Falta um planejamento para entender como funciona o ecossistema da companhia e os satélites ( serviços que nascem) vão acompanhando esse universo. Definir modelos ( canônicos) baseados em pesquisa de negócio e DDD, versionamento desses serviços, controle de repositório , política de permissões e quanto de Throughput cada um pode aguentar de acordo com uma SLA e por aí vai…

Sinceramente vejo muita imaturidade no desenvolvimento de software dentro das companhias. Isso é uma crítica de um consultor que a cada 4-5 meses visita uma empresa para implementar soluções. Esse cenário é repetido em diversas empresas e vou ter a decência de não publicar nomes, mas a coisa é feia.

Isto é sentido pelos executivos no que chamamos de ROI - Retorno do Investimento ( Return on Investment). Algumas práticas como SCA que visa exatamente abraçar essa pluralidade de plataformas, linguagens e até OS, estão nascendo, mas se quem desenha o software não começar a ter consciência sobre como realmente reaproveitar as coisas , vai tudo por água abaixo.

PS: Gosto do tema e queria palestrar no JustJava sobre Enterprise Mashups - SOA 2.0 no JustJava, abordar algumas dessas questões que coloquei. Acho que o problema não está no montante de opções e sim como elas são escolhidas para resolver os problemas.

peczenyj:

O fato matemático é que uma linguagem de tipagem estática consegue de detectar em tempo de compilação erros que uma linguagem com tipagem dinâmica não consegue

public class A{

    public static void main(String [] args){

        int [] x = new int[10];

        x[1099] = 1;

        System.out.println(x[1099]);

    }
}

Uma linguagem estática até pode detectar tais erros, porém ainda pode ter muitos erros em runtime ;-)

E alguns dos erros que só acontecem em runtime numa linguagem estática podem não acontecer numa linguagem dinamica: é o caso da versão em Ruby desse codigo. Se por um lado alguns testes podem ser necessários, por outros alguns testes podem ser desnecessários ;-)

O fato do programa rodar sem lançar erros não implica em uma programação correta. O erro que acontece com os arrays em runtime no Java é bem vindo, pois impede uma alocação desordenada de memória.

Quando eu digo que é matemático, quero dizer também que não existe mágica. Toda feature de produtividade de uma linguagem de programação estática ou dinâmica implica em alguma penalidade ou em algum risco.
Eu não sou contra correr riscos, desde que sejam levados em consideração.

O uso de linguagens de tipagem dinâmica pode ser melhor em alguns casos. Em outros não.
A plataforma Java é sensacioinal pois já atingiu um grau de maturidade que permite a coexistência.

Concordo, o SOA é viável quando na área de TI está bem definido o conceito de serviços.

Os players do mercado de SOA vão oferecer plugins até para consumir uma base de dados Clipper, e os gerentes de TI vão achar o máximo, e vão enfiar isso goela a baixo, como a solução de todos os problemas.

As pessoas gostam de acreditar em mágica.

Depois dessa onda, os mesmos players de SOA vão faturar de novo vendendo consultoria ou ferramentas de otimização para um ambiente que virou SOA “na marra”.

Kenobi:

O Tópico ainda está de pé ?

8. Bom, acho que o maior problema do meio Java não está no número de alternativas e sim nesse número fazendo exatamente a mesma coisa. Isso é uma sobreposição de funcionalidades, com ganho ínfimo. Mas até aí vai de cada equipe adotar algo que lhe traga melhor benefício.

O ponto da questão não é a pluridade de frameworks ou linguagens e plataformas e sim como as coisas são feitas dentro das companhias. Estamos ficando com um ambiente completamente heterogêneo dentro da mesma plataforma. Absurdo, mas nada conversa com nada, isso é fato !! Salve poucas libs utilitárias, o ganho de ter uma plataforma homogênea foi pro saco !!

Hoje temos aplicações Java que não conversam com a própria linguagem por falta de maturidade das equipes de arquitetura e engenharia de definirem contratos, modelos de coesão, versionamento de serviços, políticas, em fim , uma completa falta de planejamento.

Quantos sistemas nas companhias de vocês fazem extamente as mesmas coisas ? Ex. Consulta a pagamentos. Vai encontrar com JDBC, JPA, EJB-DAO, ActiveRecord - Rails e por aí vai. Falta um planejamento para entender como funciona o ecossistema da companhia e os satélites ( serviços que nascem) vão acompanhando esse universo. Definir modelos ( canônicos) baseados em pesquisa de negócio e DDD, versionamento desses serviços, controle de repositório , política de permissões e quanto de Throughput cada um pode aguentar de acordo com uma SLA e por aí vai…

Sinceramente vejo muita imaturidade no desenvolvimento de software dentro das companhias. Isso é uma crítica de um consultor que a cada 4-5 meses visita uma empresa para implementar soluções. Esse cenário é repetido em diversas empresas e vou ter a decência de não publicar nomes, mas a coisa é feia.

Isto é sentido pelos executivos no que chamamos de ROI - Retorno do Investimento ( Return on Investment). Algumas práticas como SCA que visa exatamente abraçar essa pluralidade de plataformas, linguagens e até OS, estão nascendo, mas se quem desenha o software não começar a ter consciência sobre como realmente reaproveitar as coisas , vai tudo por água abaixo.

PS: Gosto do tema e queria palestrar no JustJava sobre Enterprise Mashups - SOA 2.0 no JustJava, abordar algumas dessas questões que coloquei. Acho que o problema não está no montante de opções e sim como elas são escolhidas para resolver os problemas.

Concordo com o Ninho…está coberto de razão, acho que explicou bem o que eu quis dizer na abertura do tópico, vocês não acham ?

Em São Paulo, minha área, o .NET está crescendo bastante por causa da estratégia de venda da Microsoft. Tem um exército de vendas falando pra cada CIO um monte de coisas e um monte de argumentos Microsoftianos para adotar o .NET ao invés do Java.

Por outro lado, não tem ninguém vendendo Java. O Java não bate na sua porta querendo se vender. O mesmo acontece com PHP, Ruby e qualquer outra plataforma não comercial.

IBM
Redhat / JBoss
Sun
Oracle

Estamos sujeitos às leis de mercado.
Se a Microsoft sabe vender melhor o peixe, e tem produtos competitivos, sorte dela.
Mas os CIOs também quebram a cara quando adotam Microsoft, e pagam bem caro por isso.

Converse com qualquer vendedor dessas empresas. Perqunte se eles estão vendendo Java ou outra coisa.

outra coisa, tipo soluções SOA, baseadas em Java ?

Concordo, o SOA é viável quando na área de TI está bem definido o conceito de serviços.

Os players do mercado de SOA vão oferecer plugins até para consumir uma base de dados Clipper, e os gerentes de TI vão achar o máximo, e vão enfiar isso goela a baixo, como a solução de todos os problemas.

As pessoas gostam de acreditar em mágica.

Depois dessa onda, os mesmos players de SOA vão faturar de novo vendendo consultoria ou ferramentas de otimização para um ambiente que virou SOA “na marra”.

Sinceramente acreidto que hoje há muito mais preconceito do que conhecimento sobre metodologias de exposição a serviços. Mesmo pq, muitos arquitetos chamam SOA de Same Old Architecture, pois na prática o conceito é bastante conhecido e não atrelado à uma especificação WS-SOAP por exemplo. Podemos ter uma Orientação a serviços baseados em RMI-IIOP, Corba, em fim, seja qual for a tecnologia que deseja encapsular sua problemática de negócio.

O que você citou sobre expor uma base de dados como serviços é uma visão equivocada sobre SOA e por isso realmente muitos projetos naufragam. Há boas soluções no mercado, mas nem todos os consultores possuem um bom discernimento sobre quais produtos ou estratégias adotar.

Lembro que SOA não necessariamente precisa estar atrelado a um player específico. Hoje há na comunidade excelentes produtos opensource que cumprem muito bem o seu papel.

O que falta mesmo é conhecimento, visão sobre como planejar os serviços por exemplo. Pensando no paradigma DDD by Eric Evans, quantas companhias possuem um modelo coerente de domínios que possa ser empregado em todo ciclo de desenvolvimento interno ? O que relatei é que nas visitas à diferentes instituições, o que encontro são equipes isoladas, vivendo como ilhas, definindo soluções proprietárias.

Alguns exemplos a se analisar são Ebay e Amazon, as cujas definiram um modelo de acesso ao seu ecossistema e construíram um universo com diversas aplicações satélites de terceiros, implementando e seguindo um contrato.

Pensem no modelo de usuários do Ebay. Caso você queira fazer um acesso à um determinado profile, como irá obter esse registro ? Algumas informações que não exigem credenciais ou políticas de segurança severes, poderiam adotar outras abordagens como REST, ATOM e os softwares consumerem informações como Feeds.

Ainda acho que falta esse tipo de visão dentro das companhias, de como organizar seu ativo tecnológico e por isso essa sensação de colapso vai ficar cada vez mais presente.

PS: Os players citados não são necessariamente um mal. As soluções normalmente são pautadas em linhas de pesquisa e consolidam o que temos de teoria. Exemplo são os ESB, que nada mais são que a implementação dos Enterprise Patterns prontos numa caixa para serem utilizados ( com features a mais) :-).

Claro que existem soluções que “prometem” e não cumprem, consultores sem o entendimento necessário, más implementações e por aí vai… Um bom projeto de SOA começa pelos fundamentos, literatura aberta como Thomas Erl entre outros arquitetos para só depois então pensar em produtos e quais lacunas queremos preencher com eles.

Nunca um projeto SOA pode nascer do produto para a solução…

Soluções SOA não necessariamente precisam ser baseadas em Java. Inclusive tem um projeto sendo incubado pela IBM - http://services.alphaworks.ibm.com/isc/ , baseado em REST e Rails.

O conceito não está preso à uma linguagem ou plataforma. Entretanto, java já está consolidado no segmento Middleware e faz do mesmo uma solução completamente viável. São muitos anos dedicados à evolução de JVM, ApplicationsServers e por aí vai …

Kenobi,

poderia apontar artigos e documentações sobre arquitetura SOA que você considera úteis?
Atualmente, (pouco menos de um mês) participo de um projeto SOA e não sei nada da teoria, exceto alguma documentação que eu passei o olho no site da Bea. Ainda estou desenvolvento na base do olha-como-o-colega-do-lado-fez-e-faz-igual, dá pra aprender muita coisa, mas sacomé.

Fiz uma procura no google com os termos “Thomas Er SOA”, e num primeiro momento não achei nada consistente.

[]'s

dlt:

Kenobi,

poderia apontar artigos e documentações sobre arquitetura SOA que você considera úteis?
Atualmente, (pouco menos de um mês) participo de um projeto SOA e não sei nada da teoria, exceto alguma documentação que eu passei o olho no site da Bea. Ainda estou desenvolvento na base do olha-como-o-colega-do-lado-fez-e-faz-igual, dá pra aprender muita coisa, mas sacomé.

Fiz uma procura no google com os termos “Thomas Er SOA”, e num primeiro momento não achei nada consistente.

[]'s

Procura como Thomas Erl , eu havia errado - digitação.

Quanto à soa, é bastante amplo, mas pode começar por esses dois sites - www.infoq.com/soa e http://complexevents.com/?cat=21 . Vai encontrar muito material pela frente :-).

Se precisar de mais dicas, me adicione no gtalk

Kenobi,

valeu pelas referências, cara.
Não ahcei informações sobre seu gtalk no seu profile.

Sua colocação tem problemas. Tipagem estática é normalmente melhor verificável por compiladores e se você falar de tipaem estática em, digamos, Haskell você tem uma segurança razoável mas a tipagem estática de Java é extremamente deficiente. Dizer que um objeto é de um dado tipo em Java não garante mais do que saber que ele tem operações com determinada assinatura, não há qualquer segurança sobre o que invocar estas operações significa. Um exemplo clássico é você implementar uma interface, por exemplo Comparable e não obedecer ao contrato, por exemplo lançando exceções ou retornando valores inesperados.

Tipagem estática é ótima em muitos casos mas em Java ela nem consegue garantir muita coisa nem precisava ser tão burocrática. Scala é estaticaente tipada e possui diversas funcionalidades que facilitam o desenvolvimento e a criação de abstrações melhores, como type inference, open classes e high order functions.

–
Java é uma linguagem com uma finalidade e um público alvo definidos. O grande problema para Java é que o público alvo está procurando usar soluções que não se adequam bem à linguagem. Pode ser que estejamos buscando ferramentas melhores para os mesmos problemas ou pode ser que os problemas são diferentes ou ambos; ja como for stamos mudando. Java ainda é ótima para muita coisa mas não é a melhor solução para tudo.

"

Haskell lembra erlang, mas é diferente.

Eu escrevi um pequeno tutorial sobre Haskell há anos

Disponibiliza ai!!!

por tutatis!!
esses romanos são uns neuroticos!! :lol:

brinco com java por hobby ja tem uns 7 anos e continuo novato (sério) e agora estou reapreendendo. desta vez de forma oo.
era tao preguiçoso (hj sou menos) que um dos meus primeiros postings no javalist quando se programava na unha com notpads ou na linha de comando foi:

como programar sem código???

um preguiçoso sempre imagina as coisas visuais e prontas e que nao precise se esforçar para aprender, seja a propria linguagem ou como fazer bom uso dela em contextos fora da programação. ex: aprender o dominio final da aplicação…

vejam. ja c passaram 7 anos e ainda estamos batendo cabeça com questao de dominio quando estamos inundados de idézes e frameworks.
num sei, mas parece dificil entender que o próbis não é tecnologia…

com o bom humor de todo bom programador java, um iluminado respondeu ± assim:
“sim é possivel programar 100 codigos, mas nao da pra fazer muita coisa”

kkk…

hj temos posting do tipo “sera o fim do java?” por conta de IDEs proprietarias tipo maker (repare. ide nao é linguagem de programação) ou mesmo discussões por conta do excesso de frameworks…aff

que tal abolir as IDEs e voltar a programar em edit ou notpad???

desconfio que os melhores programadores do mundo ainda fazem exatamente assim (me corrijam por favor).
ja c foram 7 anos e tenho netbean, eclipse,frameworks tudo free e memoria suficiente para roda-los numa boa e nem sei usar. porque?

Porque ainda não aprendi oo, java e dominio!!

aff. como eu sou preguiçoso!!!