Tor Norbeye anunciou em seu blog o lançamento da JSR 273, “Design-Time API for JavaBeans JBDT”.
A lista de mudanças propsotas pela JSR inclui (minha tradução livre):
Como menmbros iniciais do Expert Group, estão: BEA, Borland, Google, Oracle, OTRIX e Sun.
Como supporters temos a adição de Business Objects Corp., Software FX, Inc. e ESRI.
O lídear da spec é Joe Nuxoll
Agora que já fiz a parte “burocrática” de postar a notícia como “GUJ”, vamos aos comentários pessoais.
Quando será que as emrpesas que produzem IDEs “produtivas” vão se preocupar menos com velocidade e mais com qualidade?
Injetar mais parafernalha no modelo obsoleto de componentes JavaBeans, que viraram structs passando entre Commands hoje em dia, em vez de investir num modelo refatorado de componentes, utilizando metadados nativos da linguagem? Isso me soa bem retrô.
O que o Google está fazendo nesse comitê, BTW?
Olá,
Chegando a este post atraves do link neste outro. http://www.guj.com.br/posts/list/23431.java
Pra mim a IDEA é uma IDE que tem uma certa preocupacao com qualidade aliada a produtividade. Mas claro esta longe de ser o ideal.
Quando quem compra parar de achar que desenvolver sistema é de um dia pro outro e que mais vale um sistema bem feito, mesmo que gaste mais tempo do que um monte de gambiarra com milhares de bugs.
Grande pergunta.
Agora mais um perguntinha, sera que foi por isso* que o JBuilder ando batendo as botas?
]['s
A grande movimentação em torno de “agile”, quando na verdade as pessoas querem dizer “qualidade” é um ponto interessante na sua pergunta. Tantos gurus, blogs, sites, plugins, IDEs, papers, palestras, etc. falando sobre como aumentar a qualidade, como montar um sistema melhor…
Eu estou cansado, de saco cheio, estressado de virar noites consertando software feito com point-and-click. Nada contra ferramentas de produtividade, mas sim contra pseudo-programadores que não sabem quando usar essas ferramentas e quando parar dez minutos para pensar ANTES de arrastar a droga do componente.
Quando estava indo por STD 2005 (acho que já mencionei isso aqui) fui perguntado mais de dez veses sobre o que estava fazendo quanto ao JSF. E as pessoas que me perguntavam são claramente pessoas que fazem JSP+JavaBeans hoje,e vão fazer a mesma coisa amanhã, com JSF de modo mais rápido, mais sujo e mais preso ao vendor da plataforma.
A idéia dos caras, na verdade, nem seria tão ruim se fosse há quatro anos atrás, ou se Java 5 não viesse com metadados. Hoje em dia a Sun (e os outros players) vendem JavaBeans como structs, porque as pessoas “aprendem” mais rápido a “programar” assim. O modelod e componentes JavaBeans faliu (não vingou como a Sun achou que ia vingar, com componentes para tudo brotando em todos os sites web) e está obsoleta, para que get/set se eu tenho annotations? Para que investir uma JSR nisso? Pergunto novamente: não é um passo para trás?
Claro que vão postar aqui (e eu já sei até quem vai 
) sobre “o que importa é vender”, mas essa filosofia burra de que entregar um sistema em X meses é ótimo, mesmo gastando três vezes esse tempo todos os anos em manutenção dessa porcaria já deu o que tinha que dar. É simpels questãod e matemática de primeiro grau!
Como dizem: “o cliente não quer saber se você vai usar delphi, Struts, webwork… ele quer os istema pronto rápido!”, respondo: “o cliente também não quer saber se você tem que alterar vinte mil arquivos gerados automaticamente que você nem sabe como funcionam, que tem que mudar um framework mal escolhido…ele quer que o sistema FUNCIONE (volte a funcionar depois de um defeito ou mudança ou funcione de verdade pela primeira vez), e bem rápido”
[quote=pcalcado]
Eu estou cansado, de saco cheio, estressado de virar noites consertando software feito com point-and-click. [/quote]
Sou totalmente a favor neste ponto, passar seu tempo dando manutenção em um sistema feito com point-abn-click é pior do que “bater na mãe”, a ainda ressalvo mais, esses “pseudo-programadores que não sabem quando usar essas ferramentas e quando parar dez minutos para pensar ANTES de arrastar a droga do componente.” são geralmente pessoas vindas de tecnologias como asp.net VB, Delphi e VFP que acham que para tudo deve existir um componente para facilitar as coisas para que eu não tenha que pesquisar nada … (Deixo claro que não são todos 
).
Cito o exemplo de uma consultoria que fui fazer semana passada em uma empresa aqui em sp, elas gostariam de portar o sistema deles para web, os programadores Delphi, tinham todas as funçoes implementadas atraves de botões, se eu quisesse ver a logica de uma funcionalidade eu tinha que dar dois cliques no botão para abrir a função e “ploft” la estava o codigo macarronico em um action de botão.
Facilitar o trabalho sim, mas de uma maneira que prevaleçam qualidade com rapidez, o que eu particularmente dificil
Cada vez eu tenho mais medo do Google! :shock:
Também acho a IDEA (The most intelligent IDE for Java ) a melhor IDE. Sem dúvida melhora o tempo de desenvolvimento. Mas como foi dito, muita preocupação em produtividade e pouca em qualidade.
Mas eu acho que isso vem porque durante muito tempo e ainda hoje se diz que desenvolver em java é demorado, então as IDE’s tentam resolver esse problema… Talves quando não tiver mais esse problema elas se foquem na produtividade.
Pessoalmente eu acho que é errado comparar tempo de desenvolvimento em linguagens com paradigmas diferentes, mas vai explicar isso!!!
Não acho o modelo de componentes javabeans tão ruim assim, de fato acho ele legalzinho se pensarmos que ele foi projetado no século passado.
O problema, o [color=red]enorme[/color] problema, é que quase todos misturam objetos e componentes. Dai que vem a farra dos super java beans.
Um componente deve exportar para seus clientes propriedades, evetos e métodos/funções. Um propriedade, diferente de um atributo, é estado observavel e manipulavel de um componente. Só pensar em um JComponent e a propriedade visible, export isso de outra forma vai acabar sendo mais complicado.
O modelo de componentes não vingou e todo mundo achou que era uma convenção para objetos comuns, porque o trabalho foi feito pela metade pela Sun, definiram o modelo de programação, mas não de empacotamento e deployment e arquivos jars são simplorios demais para essa tarefa.
Essa vai ser rápida…
[quote=louds]Não acho o modelo de componentes javabeans tão ruim assim, de fato acho ele legalzinho se pensarmos que ele foi projetado no século passado.
[/quote]
Esse é o problema, investir am algo obsoleto emv ez de priorizar as coisas que a própria Sun/JCP fez no Tiger.
De resto, perfeito
???
hum???
Artima: Java Rockets Closer to VB-like Ease with JSR 273
Fonte: TSS
Microfilo: você não precisa de convenções de nomenclatura e toda a estrutura de beans para fazer “introspecção padronizada”, basta anotar seus métodos ou atributos 