QT e Java juntos: QT Jambi Preview
“A Trolltech® liberou um preview inicial da tecnologia "Qt Jambi" para testes. Agora vai ficar mais fácil para desenvolvedores Java criarem suas interfaces no padrão KDE. Oba!” A nota foi enviada por Jorge Eduardo Birck (jorgeΘlabcal·ufsc·br), que enviou este link para mais detalhes.
Segundo o anúncio, o Qt Jambi permite criar aplicativos em Java com aparência e comportamento nativos, rodando em Linux, Windows e Mac, a partir de uma mesma base de código.
(postado por Augusto Campos)
Comentários dos leitores
Comentário de xultz
31/07/06 16:59 - usuário registrado #313
Isso não é juntar dois: Isso não é juntar dois pesos-pesados num único programa e tornar o aplicativo ainda mais pesado?
Comentário de hamacker
31/07/06 17:32 - usuário registrado #168
Gostaria de saber, onde vai: Gostaria de saber, onde vai parar o "run in everywhere" com tanta gente fazendo esses binds externos.
Com tantas bibliotecas e linguagens multiplataforma vai ser mais inteligente faze-lo em C, C++, Python,... do que em java, não ?
Com tantas bibliotecas e linguagens multiplataforma vai ser mais inteligente faze-lo em C, C++, Python,... do que em java, não ?
Comentário de fzero
31/07/06 17:38 - usuário registrado #3168
Java nunca foi realmente "run anywhere": Pergunte a qualquer um fazendo aplicativos para celulares, por exemplo. De qualquer forma, programas java em geral não mantêm 100% de coerência entre as plataformas. Chega a ser surpreendente quando acontece.
Comentário de Thiago Alves
31/07/06 17:58
Algumas informações a mais: Bom, primeiramente não se refira a biblioteca da Trolltech como QT. QT é normalmente uma abreviatura para QuickTime, isso já foi discutido algumas vezes nos foruns da Trolltech.
Segundo, um erro muito comum a quem não conhece a Qt é dizer que ela é um toolkit gráfico. Na verdade essa é uma das features que a Qt fornece. Inclusive para o conhecimento de todos, na sua última versão (4.X) é possível criar aplicativos console com a Qt.
Eu utilizo Qt em meus softwares desde a versão 2 da mesma, não sou um expert em Qt mas posso dizer que o que mais chama atenção nela não é o seu toolkit gráfico e sim o seu sistema de comunicação entre seus objetos (signals/slots), recomendo uma lida na documentação da Qt.
A grande vantagem desse passo que a Trolltech deu com o Jambi não é poder usar a "carinha" do KDE (ou melhor, da Qt) em seu programa java. Com o Jambi você poderá utilizar os recursos da Qt no seu programa java como o sistema de troca de mensagens entre objetos, SQL (realmente eu acho que o jdbc deve ser melhor, mas vai que...), comunicação em rede (outro ponto que eu acho que o java já é bem maduro) e outros (eu acho :P).
Estava lendo o press-release da Trolltech sobre o Jambi e eu acredito que outro ponto importante é o contrário do que estamos debatendo aqui, é provavel que a Trolltech esteja interessada fazer uma aplicação feita em Qt executar programas/classes/etc. feitos em java, e isso sim seria uma grande vantagem que a Qt poderia ter.
Texto extraído do press-release da Trolltech:
"For C++ developers, Qt Jambi enables C++ (Qt) and Java code to exist side-by side in a single project, expanding the opportunities for efficient collaboration between C++ and Java programmers in a mixed development team. Through Qt Jambi, single projects can incorporate both C++ and Java code and skills, more rapidly delivering native, rich-client applications on multiple platforms."
Segundo, um erro muito comum a quem não conhece a Qt é dizer que ela é um toolkit gráfico. Na verdade essa é uma das features que a Qt fornece. Inclusive para o conhecimento de todos, na sua última versão (4.X) é possível criar aplicativos console com a Qt.
Eu utilizo Qt em meus softwares desde a versão 2 da mesma, não sou um expert em Qt mas posso dizer que o que mais chama atenção nela não é o seu toolkit gráfico e sim o seu sistema de comunicação entre seus objetos (signals/slots), recomendo uma lida na documentação da Qt.
A grande vantagem desse passo que a Trolltech deu com o Jambi não é poder usar a "carinha" do KDE (ou melhor, da Qt) em seu programa java. Com o Jambi você poderá utilizar os recursos da Qt no seu programa java como o sistema de troca de mensagens entre objetos, SQL (realmente eu acho que o jdbc deve ser melhor, mas vai que...), comunicação em rede (outro ponto que eu acho que o java já é bem maduro) e outros (eu acho :P).
Estava lendo o press-release da Trolltech sobre o Jambi e eu acredito que outro ponto importante é o contrário do que estamos debatendo aqui, é provavel que a Trolltech esteja interessada fazer uma aplicação feita em Qt executar programas/classes/etc. feitos em java, e isso sim seria uma grande vantagem que a Qt poderia ter.
Texto extraído do press-release da Trolltech:
"For C++ developers, Qt Jambi enables C++ (Qt) and Java code to exist side-by side in a single project, expanding the opportunities for efficient collaboration between C++ and Java programmers in a mixed development team. Through Qt Jambi, single projects can incorporate both C++ and Java code and skills, more rapidly delivering native, rich-client applications on multiple platforms."
Comentário de Copernico Vespucio
31/07/06 18:07 - usuário registrado #4868
não seria o caso: Esse não seria o caso, Xultz. Veja o porquê:
Swing, ao contrário do AWT e SWT, desenha sua própria interface gráfica ao invés de apenas pedir ao sistema que faça isso. A maneira como o Swing desenha seus componentes e como eles reagem ao usuário é configurada por um conjunto de classes de fábrica classificadas como PLAF(Aparência e Comportamento Plugável). Trocando o PLAF, vc. troca a forma de renderizar os componentes.
Alguns PLAF podem ter (e alguns possuem) integração nativa, ou seja, aproveitam recursos do SO, se existirem, ou emulam esses recursos se eles não estiverem presentes.
Se o PLAF do Qt for produzido com integração nativa, o swing aproveitaria as bibliotecas se estivessem carregadas (no KDE, por exemplo), mas o sistema não teria de carregar as bibliotecas do Qt em um ambiente que não precise delas (como no Gnome, por exemplo, que usa GTK)!
Já tentou monitorar um sistema Gnome, por exemplo, quando vc. tem de rodar um aplicativo que usa Qt? As bibliotecas e dependências são carregadas em cascata, gastando muito mais memória só para rodar um único aplicativo... Com o Jambi seria a mesma coisa.
Swing, ao contrário do AWT e SWT, desenha sua própria interface gráfica ao invés de apenas pedir ao sistema que faça isso. A maneira como o Swing desenha seus componentes e como eles reagem ao usuário é configurada por um conjunto de classes de fábrica classificadas como PLAF(Aparência e Comportamento Plugável). Trocando o PLAF, vc. troca a forma de renderizar os componentes.
Alguns PLAF podem ter (e alguns possuem) integração nativa, ou seja, aproveitam recursos do SO, se existirem, ou emulam esses recursos se eles não estiverem presentes.
Se o PLAF do Qt for produzido com integração nativa, o swing aproveitaria as bibliotecas se estivessem carregadas (no KDE, por exemplo), mas o sistema não teria de carregar as bibliotecas do Qt em um ambiente que não precise delas (como no Gnome, por exemplo, que usa GTK)!
Já tentou monitorar um sistema Gnome, por exemplo, quando vc. tem de rodar um aplicativo que usa Qt? As bibliotecas e dependências são carregadas em cascata, gastando muito mais memória só para rodar um único aplicativo... Com o Jambi seria a mesma coisa.
Comentário de nemesis
31/07/06 18:08 - usuário registrado #1514
viadagem: sempre desconfiei desse pessoal do KDE e seu visual multicolorido e ícones saltitantes... ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Copernico Vespucio
31/07/06 18:15 - usuário registrado #4868
WORA: A plataforma Java é portável, os programas nem sempre.
Mesmo em desktop, se um programador depende intencionalmente de um recurso do SO ou da máquina, ele prende seu aplicativo ao sistema.
No entanto, vc. pode (e é assim que se faz, em Java) isolar a parte não portável através de uma API padronizada.
Em J2Me, isso é feito através das configurações (CLDC, MIDP, MIDP2.0, etc) e da API (que padroniza o acesso a recursos do dispositivo). Afinal, vc. não pode usar o infravermelho do celular se ele não está lá, certo?
Mas não significa que sua aplicação vai funcionar 100% em um ambiente e estourar um memory leak em outro, por exemplo.
Mesmo em desktop, se um programador depende intencionalmente de um recurso do SO ou da máquina, ele prende seu aplicativo ao sistema.
No entanto, vc. pode (e é assim que se faz, em Java) isolar a parte não portável através de uma API padronizada.
Em J2Me, isso é feito através das configurações (CLDC, MIDP, MIDP2.0, etc) e da API (que padroniza o acesso a recursos do dispositivo). Afinal, vc. não pode usar o infravermelho do celular se ele não está lá, certo?
Mas não significa que sua aplicação vai funcionar 100% em um ambiente e estourar um memory leak em outro, por exemplo.
Comentário de nemesis
31/07/06 18:38 - usuário registrado #1514
huhuhu: "A plataforma Java é portável"
a plataforma Linux bem mais: roda em muito mais processadores e arquiteturas diferentes do que a plataforma Java.
se enforcou, hein Copérnico? ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
a plataforma Linux bem mais: roda em muito mais processadores e arquiteturas diferentes do que a plataforma Java.
se enforcou, hein Copérnico? ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Douglas Augusto
31/07/06 18:46 - usuário registrado #12
Em seguida, a utilização:
A TrollTech alega[1] que o Qt roda em Linux/x86, Linux/PPC, Linux/AMD64, Linux/IA64, Altix, Mac OSX, AIX, HP-UX, IRIX, Solaris, FreeBSD, Windows 98/Me/NT/2000/XP/2003 e sistemas embutidos.
Me parece que o pré-requisito do Jambi é ter a disponibilidade do Qt, portanto, não acredito que exista algum gargalo no que tange a portabilidade.
1. http://www.trolltech.com/developer/notes/supported_platforms
--
GAFFitter: a file fitter powered by a genetic algorithm.
Em seguida, a utilização desse toolkit serve apenas ao KDE (ou a sistemas que carreguem suas bibliotecas Qt), reduzindo a portabilidade das aplicações feitas com ela.
A TrollTech alega[1] que o Qt roda em Linux/x86, Linux/PPC, Linux/AMD64, Linux/IA64, Altix, Mac OSX, AIX, HP-UX, IRIX, Solaris, FreeBSD, Windows 98/Me/NT/2000/XP/2003 e sistemas embutidos.
Me parece que o pré-requisito do Jambi é ter a disponibilidade do Qt, portanto, não acredito que exista algum gargalo no que tange a portabilidade.
1. http://www.trolltech.com/developer/notes/supported_platforms
--
GAFFitter: a file fitter powered by a genetic algorithm.
Comentário de Copernico Vespucio
31/07/06 18:53 - usuário registrado #4868
Não confunda: Linux tem de ser reescrito (embora não completamente, é verdade) para ser portado a uma nova plataforma.
Sem problemas, é natural que isso aconteça com um sistema operacional. Sua função é oferecer serviços de baixo nível para que aplicações possam abstrair detalhes como a arquitetura da máquina.
Se um determinado dispositivo solicitado por um programa não estiver presente, um SO deve lidar com isso de forma elegante sem travar na sua cara. Isso é portabilidade.
No entanto, se um programador faz acesso direto a um componente sem se preocupar com sua possível ausência ou tratar falha, quando o dispositivo estiver ausente ele vai travar na sua cara! O SO continua sendo portável, mas o programa não é.
Ou seja: a plataforma é portável (oferecem todos os subsídios de portabilidade). Já os aplicativos, nem sempre.
Java trabalha em uma camada superior (que procura abstrair qual sistema operacional está sendo usado ou até abstrai a presença ou não de um SO) mas o raciocínio é o mesmo...
Java permite escrever programas portáveis. Bons programadores podem ampliar essa portabilidade ou limitá-la.
a plataforma Linux bem mais: roda em muito mais processadores e arquiteturas diferentes do que a plataforma Java.
Por favor, não diga bobagens...
Graças ao Linux, Java roda em todas essas plataformas. Graças ao Solaris, em muitas outras, etc, etc, etc. Onde houver um SO para o qual haja uma JVM, haverá Java. E em muitos lugares onde não há um SO portado, é possível que haja Java também... :P
Sem problemas, é natural que isso aconteça com um sistema operacional. Sua função é oferecer serviços de baixo nível para que aplicações possam abstrair detalhes como a arquitetura da máquina.
Se um determinado dispositivo solicitado por um programa não estiver presente, um SO deve lidar com isso de forma elegante sem travar na sua cara. Isso é portabilidade.
No entanto, se um programador faz acesso direto a um componente sem se preocupar com sua possível ausência ou tratar falha, quando o dispositivo estiver ausente ele vai travar na sua cara! O SO continua sendo portável, mas o programa não é.
Ou seja: a plataforma é portável (oferecem todos os subsídios de portabilidade). Já os aplicativos, nem sempre.
Java trabalha em uma camada superior (que procura abstrair qual sistema operacional está sendo usado ou até abstrai a presença ou não de um SO) mas o raciocínio é o mesmo...
Java permite escrever programas portáveis. Bons programadores podem ampliar essa portabilidade ou limitá-la.
a plataforma Linux bem mais: roda em muito mais processadores e arquiteturas diferentes do que a plataforma Java.
Por favor, não diga bobagens...
Graças ao Linux, Java roda em todas essas plataformas. Graças ao Solaris, em muitas outras, etc, etc, etc. Onde houver um SO para o qual haja uma JVM, haverá Java. E em muitos lugares onde não há um SO portado, é possível que haja Java também... :P
Comentário de Douglas Augusto
31/07/06 18:54 - usuário registrado #12
Éca:
A forma como o Qt implementa o sistema de comunicação é suja, abusando de macros. Como conseqüência a sintaxe de um programa Qt não é passível por compiladores C++ até que um pré-processamento seja feito; isto existe um outro "compilador", o famigerado Meta Object Compiler.
--
GAFFitter: a file fitter powered by a genetic algorithm.
mas posso dizer que o que mais chama atenção nela não é o seu toolkit gráfico e sim o seu sistema de comunicação entre seus objetos (signals/slots), recomendo uma lida na documentação da Qt.
A forma como o Qt implementa o sistema de comunicação é suja, abusando de macros. Como conseqüência a sintaxe de um programa Qt não é passível por compiladores C++ até que um pré-processamento seja feito; isto existe um outro "compilador", o famigerado Meta Object Compiler.
--
GAFFitter: a file fitter powered by a genetic algorithm.
Comentário de Douglas Augusto
31/07/06 19:12 - usuário registrado #12
Linux tem de ser reescrito:
A plataforma Java (a camada) precisa ser reescrita para fornecer a portabilidade em sistemas distintos. Não há como fugir disso.
--
GAFFitter: a file fitter powered by a genetic algorithm.
Linux tem de ser reescrito (embora não completamente, é verdade) para ser portado a uma nova plataforma.
A plataforma Java (a camada) precisa ser reescrita para fornecer a portabilidade em sistemas distintos. Não há como fugir disso.
--
GAFFitter: a file fitter powered by a genetic algorithm.
Comentário de Hugo
31/07/06 19:21 - usuário registrado #9
...:
Isso iria tirar uma das principais vantagens da Qt que é justamente sua API fácil e intuitiva... aprendendo a API da Qt você aprende uma API que serve para programar em Linux embarcado, linux "normal", windows, mac e agora também para a plataforma Java... tudo com uma única API, no white paper do lançamento tem algumas comparações entre a API da Qt e a API do Swing que servem de exemplo para a palavra "intuitiva".
E agora a Qt4.2 vem com um widget style de fabrica que imita o widget style do gnome, ideal para quem sofre de Qtfobia.
--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
No entanto, agregaria muito mais se ao invés de simplesmente oferecer uma interface nativa com API "própria", este se integrasse ao padrão Java Swing (ou seja, a Trolltech implementasse seu toolkit como um PLAF - Plugable Look And Feel - do Swing).
Isso iria tirar uma das principais vantagens da Qt que é justamente sua API fácil e intuitiva... aprendendo a API da Qt você aprende uma API que serve para programar em Linux embarcado, linux "normal", windows, mac e agora também para a plataforma Java... tudo com uma única API, no white paper do lançamento tem algumas comparações entre a API da Qt e a API do Swing que servem de exemplo para a palavra "intuitiva".
E agora a Qt4.2 vem com um widget style de fabrica que imita o widget style do gnome, ideal para quem sofre de Qtfobia.
--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Comentário de Hugo
31/07/06 19:34 - usuário registrado #9
As biliotecas? Se você: As biliotecas? Se você estiver falando da Qt4 geralmente são apenas 2 biliotecas, QtCore e QtGui, se tiver falando de Qt3, o que acho provável, só existe uma biblioteca... e não entendo como pode acontecer uma cascata de uma biblioteca só.
Muito provavelmente você deve estar falando de programas que utilizam a kdelibs, mas ai o gasto de memória deve-se mais ao fato de ter de iniciar o arts, DCOP e cia, ou seja... executar um mini-kde para executar apenas um programa.
--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Muito provavelmente você deve estar falando de programas que utilizam a kdelibs, mas ai o gasto de memória deve-se mais ao fato de ter de iniciar o arts, DCOP e cia, ou seja... executar um mini-kde para executar apenas um programa.
--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Comentário de Copernico Vespucio
31/07/06 19:39 - usuário registrado #4868
níveis diferentes: No entanto, se eu tenho um novo porte de Linux para um novo hardware, eu não preciso reescrever a JVM desse SO.
Existem 3 ou 4 SO principais no mundo que suportam uma enorme variedade de maquinas. As 4 implementações de JVM (Win, Solaris, Linux e Mac) suportam os SO citado e, através deles, todas as máquinas por eles suportadas.
Adicionalmente, existem JVMs alternativas para outros SO que não estes, que suportam outras plataformas de hardware.
Em algumas plataformas de hardware embarcado, não há porte de SO por limitações do dispositivo. Com J2Me e Java Card, Java também está lá.
O núcleo de uma aplicação Java Card pode ser carregado dinamicamente para uma aplicação J2Me em um celular ou J2SE em desktop.
Vc. pode escrever e testar no seu desktop uma aplicação para celulares (de qualquer configuração especificada), um sistema corporativo distribuído, uma aplicação de cartão inteligente (sem possuir uma gravadora de cartões).
Essa é a vantagem real para o desenvolvedor. O resto é filosofia.
Existem 3 ou 4 SO principais no mundo que suportam uma enorme variedade de maquinas. As 4 implementações de JVM (Win, Solaris, Linux e Mac) suportam os SO citado e, através deles, todas as máquinas por eles suportadas.
Adicionalmente, existem JVMs alternativas para outros SO que não estes, que suportam outras plataformas de hardware.
Em algumas plataformas de hardware embarcado, não há porte de SO por limitações do dispositivo. Com J2Me e Java Card, Java também está lá.
O núcleo de uma aplicação Java Card pode ser carregado dinamicamente para uma aplicação J2Me em um celular ou J2SE em desktop.
Vc. pode escrever e testar no seu desktop uma aplicação para celulares (de qualquer configuração especificada), um sistema corporativo distribuído, uma aplicação de cartão inteligente (sem possuir uma gravadora de cartões).
Essa é a vantagem real para o desenvolvedor. O resto é filosofia.
Comentário de Alexandro Henrique
31/07/06 22:49
Se é viadagem o visual do: Se é viadagem o visual do KDE, então o do MAC OS X é o que? Orgia Satânica?
Bati palmas para Linus Torvalds algum tempo atrás sobre um determinado comentário dele a respeito de desenvolvedores "nazistas" no software livre.
Bati palmas para Linus Torvalds algum tempo atrás sobre um determinado comentário dele a respeito de desenvolvedores "nazistas" no software livre.
Comentário de rca_cap
01/08/06 9:21 - usuário registrado #7078
Parabéns para Trolltech: O que eu quero, é um sistema operacional aonde eu posso desenvolver meus aplicativos. E que eles rodem em qqer outro sistema operacional.
Se o layout ficar bonito e com a interface do sistema operacional que o aplicativo está rodando melhor ainda.
Se o layout ficar bonito e com a interface do sistema operacional que o aplicativo está rodando melhor ainda.
Comentário de nemesis
01/08/06 10:20 - usuário registrado #1514
"Qt4.2 vem com um widget: "Qt4.2 vem com um widget style de fabrica que imita o widget style do gnome"
pra que servem temas?
"ideal para quem sofre de Qtfobia."
e para quem sofre de C++-fobia, mas ainda deseja escrever em uma linguagem compilada, seja para ganhar performance ou evitar dependências?
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
pra que servem temas?
"ideal para quem sofre de Qtfobia."
e para quem sofre de C++-fobia, mas ainda deseja escrever em uma linguagem compilada, seja para ganhar performance ou evitar dependências?
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de nemesis
01/08/06 10:28 - usuário registrado #1514
usuários Mac são: usuários Mac são reconhecidos frescos de longa data... ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
É uma notícia boa, é verdade. No entanto, agregaria muito mais se ao invés de simplesmente oferecer uma interface nativa com API "própria", este se integrasse ao padrão Java Swing (ou seja, a Trolltech implementasse seu toolkit como um PLAF - Plugable Look And Feel - do Swing).
Isso porque, em primeiro lugar, programadores terão de aprender mais uma API (do Jambi). Em seguida, a utilização desse toolkit serve apenas ao KDE (ou a sistemas que carreguem suas bibliotecas Qt), reduzindo a portabilidade das aplicações feitas com ela.