Oracle revela planos de longo prazo para o Java

Maravilhaaa !

Muito interessante. Fico pensando como seria essa integração com PFGA’s. Seria uma VM para rodar em FPGA’s? Ou alguma integração entre Java com VHDL?

ViniGodoy:

A Oracle revelou planos de longo prazo para o Java.

Entre eles incluem:

• Suporte a GPU (será que agora teremos uma plataforma completa para games?)
• Suporte a FPGA;
• Eliminação das primitivas (mesmo tipos como int serão objetos);
• Melhor suporte a 64 bits (tipos de dados maiores, arrays com indexação long, etc);
• Suporte a generics reais.

Confiram a fonte da reportagem para mais detalhes:
Fonte: http://www.javaworld.com/javaworld/jw-03-2012/120315-oracle-s-java-roadmap.html

lendo alguns destes itens e depois de ler eu pensava “tipo o c#?” :twisted:

bom…agora falando serio… eu ja cheguei a ver alguém falando aqui que as atualizações pares (1.4, 1.6) mechiam mais na estrutura dos batecodes enquanto que as impares na linguagem em si… será que isso ficaria para o java 8? será que mudaria por ter sido decidido colocar metade do java 7 no java 8?

Por mim a Oracle faria um checklist do que o C# tem e o Java não tem e sairia implementando (mais ou menos como o Netbeans fez em relação ao editor do Eclipse).

http://qconlondon.com/dl/qcon-london-2012/slides/SimonRitter_TheFutureOfTheJavaPlatformJavaSE8Beyond.pdf

Excelente link! Lá pelo meio do documento ele fala do suporte do ]ava à dispositivos como sensores de temperatura, acelerômetros etc. Muito legal!

Já evito usar desde hoje…

Excelente link! Lá pelo meio do documento ele fala do suporte do ]ava à dispositivos como sensores de temperatura, acelerômetros etc. Muito legal!

Sem querer te desanimar mas a Sun fala isso desde a década de 90 quando o Java foi inventado.

Pode ser que agora a Oracle arrume um jeito de cobrar pra instalar banco de dados nesses dispositivos?

Já eu prefiro acreditar em coelhinho da Páscoa!

Você até pode evitar para ids e campos, mas não para processamento matemático.

A vantagem é que aí está a promessa de que não precisaremos mais nos preocupar se um tipo é ou não primitivo, e que as operações serão feitas da maneira mais eficiente possível. No fundo, é ter um tipo primitivo, com as facilidades dos tipos não primitivos.

A diferença é que naquela época esses dispositivos não tinham a importância que tem hoje.

Parece que a Oracle tem em mente fazer uma boa limpeza na sintaxe do Java. Espero que realmente façam isso.
Ainda que isso quebre a compatibilidade em alguns casos, muitas vezes é importante fazer uma faxina na casa. Principalmente quando a linguagem ultrapassa os 10 aninhos de existência.

A parte de gpu já está praticamente implementada com o javafx 2.1 que está incluso no jdk 7 após o update 2. Eu andei fazendo um test drive e posso garantir que está a um ano luz de distância do swing. É totalmente integrada com o sistema operacional.

O novo toolkit gráfico se chama glass windowing toolkit e vai alavancar o java para soluções desktop com interfaces ricas

Já havia passado a hora de acabar com aquele falso puritanismo que dizia que java deveria rodar isolado dos sistemas.

ViniGodoy:

Parece que a Oracle tem em mente fazer uma boa limpeza na sintaxe do Java. Espero que realmente façam isso.
Ainda que isso quebre a compatibilidade em alguns casos, muitas vezes é importante fazer uma faxina na casa. Principalmente quando a linguagem ultrapassa os 10 aninhos de existência.

O responsável pelo JDeveloper e outras monstruosidades fazer “faxina” no Java? E pra rodar em sensores?

Fala sério…

Java está condenado ao que sempre foi [EDIT: Trolling]

Desculpe a ignorância, Vini, mas, por gentileza, do que se trata esse item?

Por mim a Oracle faria um checklist do que o C# tem e o Java não tem e sairia implementando (mais ou menos como o Netbeans fez em relação ao editor do Eclipse).

Desconfio que eles estão fazendo…hehehe e se estiverem, estão certos em fazer, sempre que uma linguagem é criada com certo recurso legal as concorrentes incluem isso na próxima versão, a OO no PHP 5 foi assim, a criação do c# foi assim, ja ouvi falar que o vb e o delphy ja tiveram muitos casos assim também… só o que não é justamente deixar uma coisa extensa demais, tem que pensar em versatilidade, reusabilidade… enfim, acredito que (espero que…rs) o pessoal responsavel por isso conheça esse tipo de coisa bem melhor do que eu.

alias:

ViniGodoy:

• Suporte a generics reais.
  

Desculpe a ignorância, Vini, mas, por gentileza, do que se trata esse item?

os tipos genericos que você utiliza somente são considerados em tempo de compilação, nos bytecodes gerados nada disso existe, por exemplo, nos bytecodes você não vai encontrar um “List<String>” ou “List<Pessoa>”, tudo isso vai ser gerado apenas como “List” (e você não faz cast no seu código, mas o bytecode gerado para esse seu código fará).

Muito legal!

Desculpe a ignorância, Vini, mas, por gentileza, do que se trata esse item?

os tipos genericos que você utiliza somente são considerados em tempo de compilação, nos bytecodes gerados nada disso existe, por exemplo, nos bytecodes você não vai encontrar um “List<String>” ou “List<Pessoa>”, tudo isso vai ser gerado apenas como “List” (e você não faz cast no seu código, mas o bytecode gerado para esse seu código fará).

Obrigado, colega. Então Java terá reificação de tipos genéricos? Lindo! (embora falem disso há algum tempo, hehe)

Em 2007 escrevi sobre as promessas de reificação do generics pro Java 7 (!), agora prometem pra 10 anos depois, no Java 10, 2017:

GPU O.O

eu li direito???

Isso é uma boa notícia, mas isso será a longo prazo, algo que o Java já deveria ter implementado a muito tempo. O C# em alguns recursos está bem a frente.

Será que irão melhorar a integração com o Sistema Operacional?

Botocudo:

ViniGodoy:

Parece que a Oracle tem em mente fazer uma boa limpeza na sintaxe do Java. Espero que realmente façam isso.
Ainda que isso quebre a compatibilidade em alguns casos, muitas vezes é importante fazer uma faxina na casa. Principalmente quando a linguagem ultrapassa os 10 aninhos de existência.

O responsável pelo JDeveloper e outras monstruosidades fazer “faxina” no Java? E pra rodar em sensores?

Fala sério…

Java está condenado ao que sempre foi [EDIT: Trolling]

Se eles fizerem mesmo uma boa limpeza na linguagem, talvez até você aprenda a programar em java mine troll 8)

Se eles fizerem mesmo uma boa limpeza na linguagem, talvez até você aprenda a programar em java mine troll 8)

Eu programo em Java, apesar que ultimamente estou muito satisfeito usando linguagens dinâmicas, são muito mais produtivas.

Talvez queira me ensinar a ser um nofanboy?

Como o Paulo citou, a Sun deixou o Java estagnar por muito tempo, agora o Java precisa correr pra não perder mercado. O Java 7 já foi um avanço e a coisa acelera com o Java 8.

Sobre FPGAs, meu mestrado foi sobre isso, sou fascinado pelo tema. Desenvolvemos um compilador em Haskell para programar esses dispositivos, é uma tecnologia muito interessante.

marcosalex:

Como o Paulo citou, a Sun deixou o Java estagnar por muito tempo, agora o Java precisa correr pra não perder mercado. O Java 7 já foi um avanço e a coisa acelera com o Java 8.

Sobre FPGAs, meu mestrado foi sobre isso, sou fascinado pelo tema. Desenvolvemos um compilador em Haskell para programar esses dispositivos, é uma tecnologia muito interessante.

Já estamos perdendo mercado…
3 meses atras estava desempregado e via MUITO mais vagas para java do que .net, agora… estou vendo iguais ou favoráveis ao lado do .net.

marcosalex:

Como o Paulo citou, a Sun deixou o Java estagnar por muito tempo, agora o Java precisa correr pra não perder mercado. O Java 7 já foi um avanço e a coisa acelera com o Java 8.

Sobre FPGAs, meu mestrado foi sobre isso, sou fascinado pelo tema. Desenvolvemos um compilador em Haskell para programar esses dispositivos, é uma tecnologia muito interessante.

Opa, interessante. No caso Kaskell era usado de que forma? O Haskell era usado para descrever os circuitos que a FPGA implementaria, tal como o VHDL faria?

Elizeu_Santos:

GPU O.O

eu li direito???

Wlw pelas noticia.

matheuslmota:

marcosalex:

Como o Paulo citou, a Sun deixou o Java estagnar por muito tempo, agora o Java precisa correr pra não perder mercado. O Java 7 já foi um avanço e a coisa acelera com o Java 8.

Sobre FPGAs, meu mestrado foi sobre isso, sou fascinado pelo tema. Desenvolvemos um compilador em Haskell para programar esses dispositivos, é uma tecnologia muito interessante.

Opa, interessante. No caso Kaskell era usado de que forma? O Haskell era usado para descrever os circuitos que a FPGA implementaria, tal como o VHDL faria?

Sim, linguagens funcionais são muito mais intuitivas pra descrever hardware porque os circuitos grosseiramente também são funções lógicas. Hardware que em VHDL exigem 200 linhas de código, conseguimos implementar em 15 linhas. E construir compiladores de linguagens novas em Haskell também é prático.

juliocbq:

A parte de gpu já está praticamente implementada com o javafx 2.1 que está incluso no jdk 7 após o update 2. Eu andei fazendo um test drive e posso garantir que está a um ano luz de distância do swing. É totalmente integrada com o sistema operacional.

O novo toolkit gráfico se chama glass windowing toolkit e vai alavancar o java para soluções desktop com interfaces ricas

Já havia passado a hora de acabar com aquele falso puritanismo que dizia que java deveria rodar isolado dos sistemas.

Júlio, em que sentido é melhor? Mais fácil de montar um layout ou é simplesmente mais rápido ?

Obrigado!

Alguns dos itens parece ficção científica

cheio_de_duvidas:

juliocbq:

A parte de gpu já está praticamente implementada com o javafx 2.1 que está incluso no jdk 7 após o update 2. Eu andei fazendo um test drive e posso garantir que está a um ano luz de distância do swing. É totalmente integrada com o sistema operacional.

O novo toolkit gráfico se chama glass windowing toolkit e vai alavancar o java para soluções desktop com interfaces ricas

Já havia passado a hora de acabar com aquele falso puritanismo que dizia que java deveria rodar isolado dos sistemas.

Júlio, em que sentido é melhor? Mais fácil de montar um layout ou é simplesmente mais rápido ?

Obrigado!

É mais fácil, tem muito mais desempenho(porque usa a placa aceleradora e troca de mensagens do sistema nativo), mais bonito porque você pode usar css3 para alterar os widgets como no qt.
Em suma, é uma versão muito(muito mesmo) melhorada do swt. Quando o javafx 2.1 for lançado, e como já existe o openjfx(para linux) você vai ver que o java em termos de desktop vai ficar bem melhor do que é hoje. O swing pode ser muito bem portável, mas está muito longe de dar a experiência que o usuário quer em aplicações desse tipo. Eu estive fazendo a conta na minha casa com alguns testes e vi que se o netbeans fosse portado para o glass, ele ocuparia pouco mais de 200 mb na ram. Hoje aqui, e agora ele está ocupando 724mb de ram.

Isso porque toda a biblioteca do swing tem que ser bootada na ram pra jvm usar. O glass está a um ano luz do swing.

Você até pode evitar para ids e campos, mas não para processamento matemático.

A vantagem é que aí está a promessa de que não precisaremos mais nos preocupar se um tipo é ou não primitivo, e que as operações serão feitas da maneira mais eficiente possível. No fundo, é ter um tipo primitivo, com as facilidades dos tipos não primitivos. :)

primitivos são (muito) mais rápidos

Você até pode evitar para ids e campos, mas não para processamento matemático.

A vantagem é que aí está a promessa de que não precisaremos mais nos preocupar se um tipo é ou não primitivo, e que as operações serão feitas da maneira mais eficiente possível. No fundo, é ter um tipo primitivo, com as facilidades dos tipos não primitivos. :)

primitivos são (muito) mais rápidos

Isso é verdade. Mas depende também da qualidade do compilador. Se tiverem cacife para fazer algo bom dessa forma só tem a melhorar para nós.

Você até pode evitar para ids e campos, mas não para processamento matemático.

A vantagem é que aí está a promessa de que não precisaremos mais nos preocupar se um tipo é ou não primitivo, e que as operações serão feitas da maneira mais eficiente possível. No fundo, é ter um tipo primitivo, com as facilidades dos tipos não primitivos. :)

primitivos são (muito) mais rápidos

Isso é verdade. Mas depende também da qualidade do compilador. Se tiverem cacife para fazer algo bom dessa forma só tem a melhorar para nós.

o problema é que envolve chamadas de métodos e tal. primitivos são calculados diretamente. eu particularmente gostaria de usar apenas os objetos (acho que ficaria mais padronizado). mas o desempenho teria que ser bastante bom

Suporte a GPU feito pela própria Oracle?! Maravilha!

O C# já faz isso hoje. Você pode fazer coisas como:

O compilador é capaz de determinar o tipo da variável em compile time, e transformar isso a chamada a métodos. Eu realmente acho que eles vão copiar o modelo, onde você tem um int normal, e o tipo int? que permite null (e provavelmente é mapeado para um wrapper). De qualquer forma, a VM também é capaz de fazer operações com o int? na forma de int, quando vê que são seguras.

Mas desde o princípio, sempre achei que esse deveria mesmo ser um papel da VM e do compilador, e não do programador.

Extremamente interessante isso, eu só não conhecia o conceito do Suporte a FPGA;

Mas tudo de bom e go go.

O C# já faz isso hoje. Você pode fazer coisas como:

…
Seria interessante que colocassem algo como inferência de tipos, mais ou menos como temos em Scala. Assim o tipo a ser retornado seria o tipo requerido, sendo chamado o método de conversão mais conveniente.

O C# já faz isso hoje. Você pode fazer coisas como:

…
Seria interessante que colocassem algo como inferência de tipos, mais ou menos como temos em Scala. Assim o tipo a ser retornado seria o tipo requerido, sendo chamado o método de conversão mais conveniente.

tipo uma conversão implícita? como fazem nas sobrecargas de operadores?

O C# já faz isso hoje. Você pode fazer coisas como:

…
Seria interessante que colocassem algo como inferência de tipos, mais ou menos como temos em Scala. Assim o tipo a ser retornado seria o tipo requerido, sendo chamado o método de conversão mais conveniente.

tipo uma conversão implícita? como fazem nas sobrecargas de operadores?
Parecido com isto. No caso de Scala pode não ser indicado o tipo, sendo este inferido a partir do tipo do dado que está sendo recebido:

Como em Java o tipo deve ser indicado ele poderia ser usado para escolher uma função de conversão apropriada do lado direito da expressão. Assim:

poderia ser escrito como:

O C# já faz isso hoje. Você pode fazer coisas como:

…
Seria interessante que colocassem algo como inferência de tipos, mais ou menos como temos em Scala. Assim o tipo a ser retornado seria o tipo requerido, sendo chamado o método de conversão mais conveniente.

tipo uma conversão implícita? como fazem nas sobrecargas de operadores?
Parecido com isto. No caso de Scala pode não ser indicado o tipo, sendo este inferido a partir do tipo do dado que está sendo recebido:

Como em Java o tipo deve ser indicado ele poderia ser usado para escolher uma função de conversão apropriada do lado direito da expressão. Assim:

poderia ser escrito como:

Mas qual a vantagem disso:

em relação a isso?

[quote=juliocbq]

Mas qual a vantagem disso:

em relação a isso?

Na verdade o primeiro codigo criaria uma variável String o segundo cria uma variável int (pois ele infere que 10 é um inteiro).

[quote=AbelBueno]

juliocbq:

Mas qual a vantagem disso:

em relação a isso?

Na verdade o primeiro codigo criaria uma variável String o segundo cria uma variável int (pois ele infere que 10 é um inteiro).

Pra mim parecem funcionar da mesma maneira.

Na verdade para algo simples assim, não faz muita diferença mesmo.

Quando você tem declarações mais complexas (Map de Map) ou aproveitar diretamente o retorno de uma função para definir o tipo, só digitar menos já começa a compensar.

Um exemplo mais prático é a possibilidade de tipos anônimos.

Em scala você pode fazer algo assim:

val objetoSemTipo = new Object() {  def falaOi = println("oi")  }

  objetoSemTipo.falaOi
  objetoSemTipo.falaOi

No Java, você não consegue chamar o método falaOi, sem definir uma classe para isso.
Aqui o var vai capturar que é uma classe anônima e dar acesso a todos os métodos que definir nela.

O .NET faz uso disso no Linq, se não me engano, para montar objetos com o resultado das queries.

Pois é, isso ajuda em situações muito específicas. Na grande maioria das situações, não muda quase nada.

AbelBueno:

juliocbq:

Sim, mal qual a vantagem de um em relação ao outro?.

Na verdade para algo simples assim, não faz muita diferença mesmo.

Quando você tem declarações mais complexas (Map de Map) ou aproveitar diretamente o retorno de uma função para definir o tipo, só digitar menos já começa a compensar.

Um exemplo mais prático é a possibilidade de tipos anônimos.

Em scala você pode fazer algo assim:

val objetoSemTipo = new Object() {  def falaOi = println("oi")  }

  objetoSemTipo.falaOi
  objetoSemTipo.falaOi

No Java, você não consegue chamar o método falaOi, sem definir uma classe para isso.
Aqui o var vai capturar que é uma classe anônima e dar acesso a todos os métodos que definir nela.

O .NET faz uso disso no Linq, se não me engano, para montar objetos com o resultado das queries.

eu entendi seu ponto de vista. mas há um problema implícito nisso.

vejamos!

ficaria assim:

a1 = SeuFactory.CreateObjfalaOi();
  a1.falaOi;

correto?

imagine agora o código maior

a1 = SeuFactory.CreateObjfalaOi("ptbr");
  a1.falaOi;

  aI = SeuFactory.CreateObjfalaOi("eng");
  a1.falaOi;

teve algum erro ai? o compilador perceberia?

no java hoje não teria esse risco. pq a sintaxe distingue mt bem o q é declaração do q é apenas uso.

TipoFala aI = SeuFactory.CreateObjfalaOi("eng");

a1 = SeuFactory.CreateObjfalaOi("eng");

mas eu concordo com vc q ajudaria se pudesse ter a tipagem na declaração implicita. tipo o with do pascal.
pq o with passa o contexto baseado no retorno e não na declaração.

GilsonNunes:

a1 = SeuFactory.CreateObjfalaOi("ptbr");
  a1.falaOi;

  aI = SeuFactory.CreateObjfalaOi("eng");
  a1.falaOi;

teve algum erro ai? o compilador perceberia?

no java hoje não teria esse risco. pq a sintaxe distingue mt bem o q é declaração do q é apenas uso.

Na verdade daria erro de compilação pois a variável al não foi declarada.
A declaração continua obrigatória, o que é opcional é você deixar explícito o tipo.

Se você quiser, pode especificar o tipo também:

val  a:String = "uma string" 
val b = "outra string"

O scala é estaticamente tipado, assim como o Java.
Não tem esse risco de usar variáveis que não existem por engano.

mas no java o q indica q é declaração é justamente o tipo.
se omitir o tipo, só sobra o

xx = qqCoisa;

ou entendi errado?

como ficaria a declaração “sem tipo” no java?

GilsonNunes:

mas no java o q indica q é declaração é justamente o tipo.
se omitir o tipo, só sobra o

xx = qqCoisa;

ou entendi errado?

como ficaria a declaração “sem tipo” no java?

Para esse tipo de recurso é criada uma palavra reservada para declarar variaveis.

Em C# é usado o "var"
Em Scala, você pode usar “var” para variaveis normais e “val” para variaveis que não podem ser reatribuidas (estilo final do java)

ai sim!!

e apesar de alguns terem dito q não via vantagem nisso, creio q existe sim, uma q poderia destacar, é o fato de assim não ser necessário os “imports”.

GilsonNunes:

ai sim!!

e apesar de alguns terem dito q não via vantagem nisso, creio q existe sim, uma q poderia destacar, é o fato de assim não ser necessário os “imports”.

e como funcionaria isso?

Não gostei da mudança de tipos primitivos para Objetos (forçadamente), pra mim poderiam mesmo era criar uma cópia de todos os Objetos que podem ser primitivos em primitivos para que possamos escolher.

até String virar string, nem sempre queremos tratar uma String apenas salvar um texto nela.

Imagine a piora no processamento eu usar assim;

Integer x;
for(x=0, x < 10000; x++)

:shock: :shock: :shock: :shock: :shock: :? :? :?

namor:

Imagine a piora no processamento eu usar assim;

Integer x;
for(x=0, x < 10000; x++)

:shock: :shock: :shock: :shock: :shock: :? :? :?

Se internamente a máquina virtual entender a sua necessidade e trabalhar esse código como um tipo primitivo, não vejo problemas.

marcosalex:

namor:

Imagine a piora no processamento eu usar assim;

Integer x;
for(x=0, x < 10000; x++)

:shock: :shock: :shock: :shock: :shock: :? :? :?

Se internamente a máquina virtual entender a sua necessidade e trabalhar esse código como um tipo primitivo, não vejo problemas.

sim, é tudo uma questão de “compilador bom”. Você pode ter até uma linguagem de extremo alto nível, sendo o compilador bom o suficiente pra otimizar tudo isso.
O problema é o custo do software, desse jeito precisa de mais memória ram, e o java é a plataforma mais custosa que existe atualmente.

juliocbq:

marcosalex:

Se internamente a máquina virtual entender a sua necessidade e trabalhar esse código como um tipo primitivo, não vejo problemas.

sim, é tudo uma questão de “compilador bom”. Você pode ter até uma linguagem de extremo alto nível, sendo o compilador bom o suficiente pra otimizar tudo isso.
O problema é o custo do software, desse jeito precisa de mais memória ram, e o java é a plataforma mais custosa que existe atualmente.

Entendo.
Falar nisso, todo mundo aqui já está usando a versão 7 do Java?

juliocbq:

GilsonNunes:

ai sim!!

e apesar de alguns terem dito q não via vantagem nisso, creio q existe sim, uma q poderia destacar, é o fato de assim não ser necessário os “imports”.

e como funcionaria isso?

simplesmente a declaração sendo implícita.

vejamos:

import PacoteFalantes;
...
...
...
ClassFala a1 = SeuFactory.CreateObjfala("ptbr");  
a1.falaOi;  
a1.falaOla;  
a1.falaFui;  
  
a1 = SeuFactory.CreateObjfala("eng");  
a1.falaOi;  
a1.falaOla;  
a1.falaFui;

se não fosse a declaração:

SeuFactory.CreateObjfala("ptbr").falaOi;  
SeuFactory.CreateObjfala("ptbr").falaOla;  
SeuFactory.CreateObjfala("ptbr").falaFui;  
  
SeuFactory.CreateObjfala("eng").falaOi;  
SeuFactory.CreateObjfala("eng").falaOla;  
SeuFactory.CreateObjfala("eng").falaFui;

assim não precisaria do import, aja vista, não houve referencia explicita à classe.
mas ai teve chamadas a CreateObjfala excessivamente e erradamente
no pascal vc poderia fazer assim:

with SeuFactory.CreateObjfala("ptbr") do
begin
  falaOi;  
  falaOla;  
  falaFui;  
end;

with SeuFactory.CreateObjfala("eng") do
begin
  falaOi;  
  falaOla;  
  falaFui;  
end;

então, segundo a sugestão, creio q ficaria assim:

with a1 = SeuFactory.CreateObjfalaOi("ptbr");  
a1.falaOi;  
a1.falaOla;  
a1.falaFui;  
  
with a1 = SeuFactory.CreateObjfalaOi("eng");  
a1.falaOi;  
a1.falaOla;  
a1.falaFui;

Eu gosto para isso aqui:

Que pode estar substituindo isso aqui:

No C++, a palavra chave auto faz essa declaração.

Muito boa. O “with” realmente deveria ser parte integrante para evitar rechear o código daquela maneira.

juliocbq:

GilsonNunes:

simplesmente a declaração sendo implícita.

vejamos:

import PacoteFalantes;
...
...
...
ClassFala a1 = SeuFactory.CreateObjfala("ptbr");  
a1.falaOi;  
a1.falaOla;  
a1.falaFui;  
  
a1 = SeuFactory.CreateObjfala("eng");  
a1.falaOi;  
a1.falaOla;  
a1.falaFui;

se não fosse a declaração:

SeuFactory.CreateObjfala("ptbr").falaOi;  
SeuFactory.CreateObjfala("ptbr").falaOla;  
SeuFactory.CreateObjfala("ptbr").falaFui;  
  
SeuFactory.CreateObjfala("eng").falaOi;  
SeuFactory.CreateObjfala("eng").falaOla;  
SeuFactory.CreateObjfala("eng").falaFui;

assim não precisaria do import, aja vista, não houve referencia explicita à classe.
mas ai teve chamadas a CreateObjfala excessivamente e erradamente
no pascal vc poderia fazer assim:

with SeuFactory.CreateObjfala("ptbr") do
begin
  falaOi;  
  falaOla;  
  falaFui;  
end;

with SeuFactory.CreateObjfala("eng") do
begin
  falaOi;  
  falaOla;  
  falaFui;  
end;

então, segundo a sugestão, creio q ficaria assim:

with a1 = SeuFactory.CreateObjfalaOi("ptbr");  
a1.falaOi;  
a1.falaOla;  
a1.falaFui;  
  
with a1 = SeuFactory.CreateObjfalaOi("eng");  
a1.falaOi;  
a1.falaOla;  
a1.falaFui;

Muito boa. O “with” realmente deveria ser parte integrante para evitar rechear o código daquela maneira.

O comando with realmente faz falta, não apenas esse comando, mais vários outros.

Oracle vamos agilizar as novas features…,

Interessante a idéia do with
Talvez dê para simular isto usando as features do projeto lambda.

pena que o salario não melhora.

rs… realmente

Botocudo:

O responsável pelo JDeveloper e outras monstruosidades fazer “faxina” no Java? E pra rodar em sensores?

Fala sério…

JDeveloper é uma IDE voltada a desenvolvedores para Fusion Apps, SOA Suite, ADF, e alguns outros produtos. Se você ou sua empresa não tem esse proposito, então NetBeans ou Eclipse atendem muito bem.