JavaFX Script será descontinuado, Novidades na plataforma JavaFX surpreendem

[quote=GradeBook][quote=juliocbq]
Não quis dizer que não se possa fazer em assembly ou c++. Mas é que assembly nem é uma linguagem de programação, é uma linguagem de montagem para hardware.

um for( ; ; ) em c equivale umas 50 linhas em assembly. Seria muito mais trabalhoso, não concorda?[/quote]

[code]#include <stdio.h>

int main (int argc, char *argv[]) {
for(;;);
}
[/code]

        .file   "for.c"
        .text
        .globl  main
        .type   main, @function
main:
.LFB19:
        pushq   %rbp
.LCFI0:
        movq    %rsp, %rbp
.LCFI1:
        movl    %edi, -4(%rbp)
        movq    %rsi, -16(%rbp)
.L16:
        jmp     .L16
.LFE19:
        .size   main, .-main
        .section        .eh_frame,"a",@progbits
.Lframe1:
        .long   .LECIE1-.LSCIE1
.LSCIE1:
        .long   0x0
        .byte   0x1
        .string ""
        .uleb128 0x1
        .sleb128 -8
        .byte   0x10
        .byte   0xc
        .uleb128 0x7
        .uleb128 0x8
        .byte   0x90
        .uleb128 0x1
        .align 8
.LECIE1:
.LSFDE1:
        .long   .LEFDE1-.LASFDE1
.LASFDE1:
        .long   .LASFDE1-.Lframe1
        .quad   .LFB19
        .quad   .LFE19-.LFB19
        .byte   0x4
        .long   .LCFI0-.LFB19
        .byte   0xe
        .uleb128 0x10
        .byte   0x86
        .uleb128 0x2
        .byte   0x4
        .long   .LCFI1-.LCFI0
        .byte   0xd
        .uleb128 0x6
        .align 8
.LEFDE1:

[/quote]

hehe… assemblado é muito mais do que eu imaginava.

calma pessoas … risos …

nao encontrei um plugin de codigo fonte aberto (fora o web tools), resumidamente , q realiza-se tudo o q o software e.a.
e com editores e validadores xml(incorporar o castor nao vale), q gerasse aplicações em qq plataforma e em qq saida - swing/awt e web em java a principio.

por exemplo, pra swing eu tive q criar um mvc-zinho… bem, eu sei q ele eh baseado em mvc … mas … resumidamente, q fosse ao estilo struts 1 com actions … com possibilidade de se trabalhar com ajax … e q nao usasse inversao de dependencia, ou outro nome bonito pra isso. q gerasse codigo fonte, de qualidade e comentado. q nao maximo usasse um commons da apache.

depois q se pode gerar os filtros ,chains e artefatos jsp por ex. , gerar jsf foi mais facil …

eu comecei isso ha alguns anos, e todos diziam q nao era viavel. realmente nao era, e ainda nao o eh. mas … aprendi bastante com isso. risos …
e fazer um framework q gerasse grafico animado em swing(jah postei um exemplo destes aqui),e em js foi bem legal.
o framework teria q se auto-adaptar a plataformas mobile(telefones, pdas, pockets e qqs outros q se enquadrem).
o framework js, por exemplo, teria q ser automatico e sem sobras de codigo por plataforma.
pra isso, eu usei o velho e conhecido eclipse 3.2 como base de programacao.
e tudo se baseia na ideia de q todos os componentes tem q ter id, tudo pode ser englobado em arquivos properties e/ou arquivos de conifiguracao xml …
em swing, o mais dificil foi trabalhar com card-layouts q se inflavam automaticamente ao carregar toda a app de uma vez. entao tive q criar um componente q se comportasse como uma pgn web, parseando xmls. como viram, nada de mais . apenas uma ideia q me ajudou a desenvolver em java, com relatorios/formularios/graficos - 95% dos casos.

agora em assembly, os blocos de codigo realmente seriam maiores. na verdade o desenvolvimento eh bem diferente.
mas jah existem frameworks visuais pra assembly e c/c++ … nao quero reinventar o roda. mas como passa-tempo eh bem bacana. se aprofunda na linguagem e se aprende coisas novas.

c/c++ promete. assembly tb, apesas dos inumeros detalhes. java sempre serah minha paixao. nao imagino outra linguagem para desenvolver novos sistemas baseados totalmente em soa. ele poderia ser a base de um gerador assembly/c++ por ex. … isso ainda vai dar muito trabalho pra mim … criar um D.O.S. por ex., ainda estah na versao 0.0.0.0.0.1 (risos).
mas existem outros escovadores de bits q jah fizerem coisas bacanas, inclusive soh utilizando micro-processadores 8085 por ex.

:arrow: assembly:

tasm , masm, nasm ? intel, amd, arm ? 8085, x86 … eh uma biblia sem tamanho.

alguem jah resolveu procurar por exemplos, forums, e softwares pra isso ?
sempre trabalhos de mestrado, doutorado … area de professores em univ …
nada amigavel.

se desenvolver em plataforma 64 bits entao, foi uma guerra … e eu nem falei do primeiro hello world, q pra um codigo ser portavel, teria q englobar comportamentos de acesso a interrupcao e garbage …

mas pra win32, como eu disse anteriormente, eh dificil, mas eh mais facil - usando tasm.

fazer um programinha pra criptografar/decriptografar(sem entrar em detalhes) dados em memoria por ex. foi mais facil de se desenvolver, devido ao numero de exemplos. mundo estranho este do assembly. serah q eu encontro alguem com menos de 40 nestas comunidades ? risos …

desenvolver um mini-DOS(sistema operacional) em assembly , seria um grande desafio … alguem ? risos …

[quote=Shelson]calma pessoas … risos …

nao encontrei um plugin de codigo fonte aberto (fora o web tools), resumidamente , q realiza-se tudo o q o software e.a.
e com editores e validadores xml(incorporar o castor nao vale), q gerasse aplicações em qq plataforma e em qq saida - swing/awt e web em java a principio.

por exemplo, pra swing eu tive q criar um mvc-zinho… bem, eu sei q ele eh baseado em mvc … mas … resumidamente, q fosse ao estilo struts 1 com actions … com possibilidade de se trabalhar com ajax … e q nao usasse inversao de dependencia, ou outro nome bonito pra isso. q gerasse codigo fonte, de qualidade e comentado. q nao maximo usasse um commons da apache.

depois q se pode gerar os filtros ,chains e artefatos jsp por ex. , gerar jsf foi mais facil …

eu comecei isso ha alguns anos, e todos diziam q nao era viavel. realmente nao era, e ainda nao o eh. mas … aprendi bastante com isso. risos …
e fazer um framework q gerasse grafico animado em swing(jah postei um exemplo destes aqui),e em js foi bem legal.
o framework teria q se auto-adaptar a plataformas mobile(telefones, pdas, pockets e qqs outros q se enquadrem).
o framework js, por exemplo, teria q ser automatico e sem sobras de codigo por plataforma.
pra isso, eu usei o velho e conhecido eclipse 3.2 como base de programacao.
e tudo se baseia na ideia de q todos os componentes tem q ter id, tudo pode ser englobado em arquivos properties e/ou arquivos de conifiguracao xml …
em swing, o mais dificil foi trabalhar com card-layouts q se inflavam automaticamente ao carregar toda a app de uma vez. entao tive q criar um componente q se comportasse como uma pgn web, parseando xmls. como viram, nada de mais . apenas uma ideia q me ajudou a desenvolver em java, com relatorios/formularios/graficos - 95% dos casos.

agora em assembly, os blocos de codigo realmente seriam maiores. na verdade o desenvolvimento eh bem diferente.
mas jah existem frameworks visuais pra assembly e c/c++ … nao quero reinventar o roda. mas como passa-tempo eh bem bacana. se aprofunda na linguagem e se aprende coisas novas.

c/c++ promete. assembly tb, apesas dos inumeros detalhes. java sempre serah minha paixao. nao imagino outra linguagem para desenvolver novos sistemas baseados totalmente em soa. ele poderia ser a base de um gerador assembly/c++ por ex. … isso ainda vai dar muito trabalho pra mim … criar um D.O.S. por ex., ainda estah na versao 0.0.0.0.0.1 (risos).
mas existem outros escovadores de bits q jah fizerem coisas bacanas, inclusive soh utilizando micro-processadores 8085 por ex.

[/quote]

usar assembly para sistemas é outra coisa. É para isso que ele serve. Agora um erp construído em assembly mesmo com um toolkit ou framework é completamente inviável, inclusive com apenas um programador.

Já usei um desses toolkits, realmente é legal de mexer.

por isso minha revolta com o descaso do java pela oracle, por exemplo.
muito codigo teria q ser feito em c/c++ isso nao há duvidas … pelo menos enquanto novas ferramentas nao surgirem.
qual serah a linguagem preferida, eu nao sei. mas a ideia de aberta, gratuita e produtiva ainda me agrada.

[quote=Shelson]por isso minha revolta com o descaso do java pela oracle, por exemplo.
muito codigo teria q ser feito em c/c++ isso nao há duvidas … pelo menos enquanto novas ferramentas nao surgirem.
qual serah a linguagem preferida, eu nao sei. mas a ideia de aberta, gratuita e produtiva ainda me agrada.

[/quote]

No caso do c++ eu concordo com você. Existem frameworks muito produtivos.
Dá uma olhada aqui:

http://qt.nokia.com/

[quote=juliocbq][quote=Shelson]por isso minha revolta com o descaso do java pela oracle, por exemplo.
muito codigo teria q ser feito em c/c++ isso nao há duvidas … pelo menos enquanto novas ferramentas nao surgirem.
qual serah a linguagem preferida, eu nao sei. mas a ideia de aberta, gratuita e produtiva ainda me agrada.

[/quote]

No caso do c++ eu concordo com você. Existem frameworks muito produtivos.
Dá uma olhada aqui:

http://qt.nokia.com/[/quote]

esse realmente promete . eh da nokia.

eu tenho me interessado por este:

VISG

q eh gerador de codigo para as seguintes linguagens:

■C/C++
■Basic
■Pascal
■Assembler
■Gentee
■JScript

testado nos seguintes ambientes de programação e compiladores:
■MS Visual C++
■Dev-C++
■Delphi
■FreePascal
■FreeBASIC
■Visual Basic
■TASM
■MASM
■lzasm
■fasm
■Gentee
■WSH/JScript+WSO

eu usei o tasm, e funcionou 100%.

Então, JavaFX Script vai ser mesmo continuado como “Visage”, mas pela comunidade.

Uma boa coisa, pois, embora Groovy e Scala aproximam-se do JavaFX Script, JFXScript é voltado pra view e só para a view com mais umas classes de suporte, como o HttpRequest e tals.

[]'s

[quote=Jesuino Master]Então, JavaFX Script vai ser mesmo continuado como “Visage”, mas pela comunidade.

Uma boa coisa, pois, embora Groovy e Scala aproximam-se do JavaFX Script, JFXScript é voltado pra view e só para a view com mais umas classes de suporte, como o HttpRequest e tals.

[]'s[/quote]

q bom hein ! :lol:

[quote=Jesuino Master]Então, JavaFX Script vai ser mesmo continuado como “Visage”, mas pela comunidade.

Uma boa coisa, pois, embora Groovy e Scala aproximam-se do JavaFX Script, JFXScript é voltado pra view e só para a view com mais umas classes de suporte, como o HttpRequest e tals.

[]'s[/quote]

jesuino, nesta mesma linha: o sr. mandic , velho de guerra da bbs, vai lançar o “java Internet explorer 3.0” junto com o visage.
:twisted: :roll:

[quote=Shelson][quote=Jesuino Master]Então, JavaFX Script vai ser mesmo continuado como “Visage”, mas pela comunidade.

Uma boa coisa, pois, embora Groovy e Scala aproximam-se do JavaFX Script, JFXScript é voltado pra view e só para a view com mais umas classes de suporte, como o HttpRequest e tals.

[]'s[/quote]

jesuino, nesta mesma linha: o sr. mandic , velho de guerra da bbs, vai lançar o “java Internet explorer 3.0” junto com o visage.
:twisted: :roll:[/quote]

Droga, não entendi a sua piada, até li partes disso pra ser se caia a minha ficha:

http://idgnow.uol.com.br/blog/navedigital/2010/04/20/para-alexandar-mandic-lugar-de-dono-de-empresa-e-no-twitter/

comofas pra entender :S

falando serio agora,

judoscript daria pra ser usado em cjto do swing e javafx ?

estes dias eu vi um tal da cajuscript tb … serah q funciona ?

[quote=bzy]Todos falam que o desktop está morrendo, mas o desktop é a base!
As aplicações Web são desenvolvidos no desktop, são publicadas por um programa FTP que roda no desktop, são visualizadas por um programa navegador desktop e o Tomcat é um aplicativo desktop.
[/quote]

Concordo em gênero, número e grau! Todo mundo diz que desktop já morreu e que tudo deve rodar em um navegador. Mas o pessoal esquece que até o próprio navegador é desktop! :smiley:
Então não adianta condenar a base. Por mais que para vários usos, desktop esteja se tornando obsoleto, para outros um aplicativo web não daria conta do recado…

[quote=Jesuino Master][quote=juliocbq][quote=Jesuino Master]

É[será] multimedia também, olhe no javafx.com/roadmap:

[/quote]

Acabei de ler lá. Vai ser uma mudança muito boa pela informações que eu vi. Só faz uma coisa, muda o título da notícia de descontinuado para reestruturado, senão o pessoal vai pensar que o jfx acabou, que nem eu pensei.[/quote]

A linguagem não será mais melhorada pela Oracle. JavaFX Script foi descontinuado! O que virá com o JavaFX 2.0 não será acessível com JavaFX Script.[/quote]

Concordo plenamente… Quando eu pesquisei a 2 dias atraz sobre “o futuro do JavaFx”… Pqp, fiquei abismado quando li a palavra descontinuado. Java FX não foi descontinuado gente… Oracle nunca que daria uma bola fora dessas…
Pelo que me parece vai ser uma revolução e tanto o JavaFx2.0! Eu já estava brincando pra caramba com a JavaFx 1.3, irei esperar mais um pouquinho pra mergulhar de cabeça.

Realmente estou entusiasmado com a versão 2.0 do JavaFX. Comecei a estudar o JavaFX 1.3, mas vou dar uma segurada pra focar no 2.0.

Alguém sabe se a Oracle liberou alguma data estimada do lançamento, nem que seja de uma versão beta?

No roadmap só fala que a versão beta vai sair no primeiro semestre, mas não dá uma data aproximada (em meados de abril, por exemplo).

[quote=kamikase_x]Realmente estou entusiasmado com a versão 2.0 do JavaFX. Comecei a estudar o JavaFX 1.3, mas vou dar uma segurada pra focar no 2.0.

Alguém sabe se a Oracle liberou alguma data estimada do lançamento, nem que seja de uma versão beta?

No roadmap só fala que a versão beta vai sair no primeiro semestre, mas não dá uma data aproximada (em meados de abril, por exemplo).[/quote]

Por enquanto eles estão centrando esforços no JDK 7 pra que ele não atrase. JavaEE 7, JavaFX 2 e JME vão ser retomados depois. O JavaEE 7 então, vai funcionar somente com o JDK 7.

O problema é que o Sun deixou o Java parado muito tempo, agora eles precisam retomar logo todos os projetos.

[quote=marcosalex][quote=kamikase_x]Realmente estou entusiasmado com a versão 2.0 do JavaFX. Comecei a estudar o JavaFX 1.3, mas vou dar uma segurada pra focar no 2.0.

Alguém sabe se a Oracle liberou alguma data estimada do lançamento, nem que seja de uma versão beta?

No roadmap só fala que a versão beta vai sair no primeiro semestre, mas não dá uma data aproximada (em meados de abril, por exemplo).[/quote]

Por enquanto eles estão centrando esforços no JDK 7 pra que ele não atrase. JavaEE 7, JavaFX 2 e JME vão ser retomados depois. O JavaEE 7 então, vai funcionar somente com o JDK 7.

O problema é que o Sun deixou o Java parado muito tempo, agora eles precisam retomar logo todos os projetos.[/quote]
Vish, se o JavaFX 2 só for retomado depois da release do JDK 7, os deadlines que estão no roadmap vão pras cucuias.

Até o JDK 7 ser homologado, ainda vai demorar :?

A Oracle deixou a Sun em segundo plano depois de ter comprado ela, agora tem que correr atrás do prejuizo.

Acho que vou dar uma estudada no 1.3 mesmo. Não vai ser conhecimento perdido, uma vez que o JavaFX Script vai continuar sendo mantido pela comunidade

[quote=kamikase_x]
Vish, se o JavaFX 2 só for retomado depois da release do JDK 7, os deadlines que estão no roadmap vão pras cucuias.

Até o JDK 7 ser homologado, ainda vai demorar :?

A Oracle deixou a Sun em segundo plano depois de ter comprado ela, agora tem que correr atrás do prejuizo.

Acho que vou dar uma estudada no 1.3 mesmo. Não vai ser conhecimento perdido, uma vez que o JavaFX Script vai continuar sendo mantido pela comunidade[/quote]

É o contrário do que você falou, a Sun que deixou o Java em segundo plano, cada release demorava séculos pra sair, quanto tempo faz que a Sun estava trabalhando no 7?

A previsão pra ele é no meio desse ano e já está no estágio Feature Complete, agora é só correção de bugs.

Quem já participou de uma aquisição de empresa grande sabe que as coisas é um processo demorado, imagina entre duas empresas gigantes como são Oracle e Sun. O que acontece é que a empresa foi comprada em um dia e no dia seguinte já ficou aquele tando de gente querendo que eles decidissem tudo sobre tudo. Até que foram rápidos, provavelmente porque as duas empresas já tinham muitos projetos conjuntos.

Corram para as colinas [857]

Alguém usa JavaFX? Já vai tarde! :wink: