L'approche JNI pourrait permettre une migration progressive de la partie client.
Tu ne recodes que la couche présention et appelle ta logique applicative au travers de JNI dans un premier temps
Si tu arrives à fiare passer plusieurs itérations pour le projets c'est pas mal.
Notes que j'avais vu passer une fois que JNI n'était pas l'unique (ni la meilleure) solution pour appeler du natif ou qu'il y avait des surcouches qui facilitaient le travail (je ne me souviens plus)
un coup de Google http://weblog.janek.org/Archive/2005/07/28/AlternativestoJavaNative(...)
Mais c'est vrai qu'on s'éloigne un peu du sujet sur les tk graphiques
Sinon pour rich cleintss semble que dans ma boite on s'oriente vers une solution RCP face aux alternatives Xul, OpenLazlo et autres Flex.
Il faut dire qu'ici la culture est plus Java/clients légers.
[^] # Re: A propos d'Eclipse
Posté par golum . En réponse au journal Eclipse, Qt et GTK+ sont dans un bateau .... Évalué à 2.
Tu ne recodes que la couche présention et appelle ta logique applicative au travers de JNI dans un premier temps
Si tu arrives à fiare passer plusieurs itérations pour le projets c'est pas mal.
Notes que j'avais vu passer une fois que JNI n'était pas l'unique (ni la meilleure) solution pour appeler du natif ou qu'il y avait des surcouches qui facilitaient le travail (je ne me souviens plus)
un coup de Google
http://weblog.janek.org/Archive/2005/07/28/AlternativestoJavaNative(...)
Mais c'est vrai qu'on s'éloigne un peu du sujet sur les tk graphiques
Sinon pour rich cleintss semble que dans ma boite on s'oriente vers une solution RCP face aux alternatives Xul, OpenLazlo et autres Flex.
Il faut dire qu'ici la culture est plus Java/clients légers.