10 razões por que precisamos do Java 3

Programação Arquitetura
#1

http://www.onjava.com/pub/a/onjava/2002/07/31/java3.html

Boa leitura! :slight_smile:

#2

esse link tem na secao de links do guj! eh o meu preferido!

eu voto SIM, mas diga NAO ao nome java3!

#3

Não ao nome? Ué, iriamos chamar do que? Java TNG? Java++? :slight_smile:

#4

Concordo plenamente com o artigo e fica a sugestão de traduzirem, pois muitos terão preguiça de ler.

#5

Há!

concordo em não mudar o nome e sim a versão.

#6

Tanta gente querendo tirar aquele monte de core APIs desnecessarias em muitos casos (inclusive a propria JDBC), e vc falando de adicionar o JDO!? Putz!

Diz a lenda que perguntaram ao James Gosling uma vez se tinha alguma coisa que ele tiraria do Java, e a resposta dele foi “A JDBC. Eu não uso pra nada, não me faria falta, mas eu sei, é claro, que muita gente depende disso.”, e eu concordo com ele: foi um erro colocar a JDBC no pacote java.sql - no Java 3, ela poderia ser toda colocada no pacote javax.sql sem maiores problemas.

#7

Só reescrevendo, pois não tinha assinado…

sim ao Java3, principalmente ao que diz respeito ao refatoramento das Threads e à morte ao AWT. Uma outra proposta que eu faria ao Java3 é tornar o JDO uma core API da plataforma e a maneira padrão para se fazer persistência de objetos (chega de ficar criando código para JDBC).

#8

É, eu já vi esta entrevista do Gosling sobre a “inutilidade” do JDBC. Talvez seja mesmo um exagero colocar JDBC (e JDO) como core API, mas continuo com a posição de que JDO deveria ser o meio padrão para se fazer persistência.

#9

Uma coisa legal seria desmembrar a classe System… ela fere bastante a orientação a objetos, fazendo uma mistureba geral de coisas mais-ou-menos relacionadas ao sistema. System.out, .in e .err poderiam muito bem ir para a classe Console ou algo do gênero, depois de toda a repensada no sistema de IO do Java…

#10

Creio que chamar o Java 1.2 para cima de “Java2” foi uma destas “brilhantes” idéias do Departamento de Marketing que acabam não correspondendo a verdade. Não há grandes modificações na linguagem da versão 1.1 para a 1.2 (só na API), nem para a 1.3. Na 1.4 temos a inclusão do “assert”. Entretanto para a 1.5 as modificações serão mais profundas, com a inclusão dos generics, a “promoção” dos tipos primitivos para classes, etc. Aí sim seria adequada uma nova denominação. Poderiamos ter um “Java 2.0” ao invés de 1.5, mas aí teriamos uma confusão com o “Java2”. Deve ser por isso que estão falando em “Java3”.
Só espero que isso não crie mais confusão nos nomes.

Grato,

#11

Eh legal o artigo, mas muita coisa eh puramente gosto pessoal do autor. Por exemplo, ele diz para converter todos os arquivos de configuracao para XML? Pra que?? puro modismo. Arquivos .properties ( classe Properties ) sao simples, formato campo = valor… eu pessoalmente nao vejo um beneficio real para converter para XML… um arquivo que atualmente eh

pathPrincipal = /usr/local/seila
nomeSistema = Meu Sistema
emailAdmin = email@do.admin

viraria

<?xml version="1.0" encoding="ISO-8859-1"?>
<properties>
    <entry>
        <name>pathPrincipal</name>
        <value>/usr/loca/seila</value>
    </entry>

    <entry>
        <name>nomeSistema</name>
        <value>Meu Sistema</value>
    </entry>

    <entry>
        <name>emailAdmin</name>
        <value>email@do.admin</value>
    </entry>
</properties>

Algumas coisas sao guerras de conceitos mesmo, como no caso dos metodos deprecated… de fato, se esta deprecated eh melhor nem usar, e se nao eh para usar, entao tire. Mas sempre tem alguem que acaba usando; ou pior, se na versao X o metodo nao eh decrepated, porem na X + 1 ele virou deprecated, se na X + 2 ele sumir e o cara fizer upgrade para a X + 2, vai ter alguns probleminhas…
Claro, reescrevendo as partes resolve, mas a questao de mantre total compatibilidade entre versoes mais antigas vem a tona…

Rafael

#12

Mas lembre-se que voce pode redirecionar o System.out, entao nao faria sentido chamar Console, se nem sempre o out padrao eh Console e tal.

Mas realmente. Haja saco pro System 100% static.

#13

agora, viajando mais um pouquinho, já que estamos discutindo/propondo as mudanças que podem/gostaríamos de ver no Java3, como seria a J3EE?

#14

J3EE? Que tal algo no estilo do JBoss AOP? Não tem EJB, tem POJOs sendo aspectados pra cima e pra baixo e virando EJBs no meio do caminho… outra ideia legal ia ser repensar a coisa toda com mais enfoque aos Message-Driven Beans, dando mais facilidade ao desenvolvimento de webservices e similares…

#15

Digo sim as atualizações… mas concordo… Java3…??? façam o seguinte… entaum vcs desistiram do Java3… segurem q tecla SHIFT e escrevam java3…… vs veram porque o nome naum pega bem… hehehe

#16

Curioso como tem pouco software 3.0 por aí…parece um número místico :smiley:

#17

morte dos ejbs, que acha?

e obrigar o uso de JMX em tudo que eh canto, HUAUHUAHUHA. ia ser DOIDO. tipo, toda configuracao de qquer coisa tem de ser jmx.

#18

Eu acho que EJBs já vão tarde :slight_smile:

…o que levaria à introdução de novas APIs, chamadas JMXX (Java Management Extensions Extensions), o que nos levaria a querer o Java 4 :smiley:

#19

concordo que os EJBs vão tarde, principalmente os EB (seja CMP ou BMP). A idéia de JMX tbm é muito boa, mas acho que eu proporia umas melhorias sobre o JCA, que deveria se assemelhar mais ao JDBC. Aliás, talvez uma fusão entre JDBC e JCA, tratando os DBMS como legados (acho que o Carlos e o Klaus iriam gostar de tratar os bancos de dados como legados :lol: ).

#20

alguem pode me explicar pra que JCA exist e dar uma exemplo real que eu utilizaria?
valeu