Oracle va proposer JavaFX et Java SE pour iOS, Réactions à la publication du 19/02/2013 |
Bienvenue invité ( Connexion | Inscription )
Oracle va proposer JavaFX et Java SE pour iOS, Réactions à la publication du 19/02/2013 |
19 Feb 2013, 06:03
Message
#1
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 4 858 Inscrit : 15 Mar 2009 Membre no 132 890 |
Dans un billet posté sur le blog Java FX, Richard Blair, architecte chez Oracle travaillant sur Java, a lâché une information importante : Oracle travaille actuellement à un portage des environnements JavaFX et Java SE sous iOS et Android.
Publié sous licence open-source, ce projet pourrait marquer le grand retour de Java dans le monde mobile. Il y avait déjà connu son heure de gloire il y a quelques années, avec l'environnement Java ME, une version simplifiée de l'environnement Java, adaptée aux capacités des mobiles de l'époque, et visant principalement les "feature phones", alors que les smartphones avaient généralement leur propre environnement de développement. Ce portage va donc permettre de disposer d'un nouvel environnement de développement multiplateformes, permettant de cibler iOS et Android (et peut-être d'autres systèmes comme Tizen, BB10, Windows Phone ou Ubuntu Touch à l'avenir ?) avec le même code applicatif, tout en s'affranchissant des limitations des environnements multiplateformes basés sur HTML5/CSS/JavaScript. Compte tenu des conditions de distributions sur l'App Store, les applications iOS basées sur cet environnement devront toutefois chacune embarquer leur propre JVM, plutôt que d'avoir une seule JVM partagée entre toutes les applications, ce qui pourra avoir certains avantages (pas de conflits de version de JVM par exemple), mais risque de mener à un certain embonpoint des applications. Par Matthieu Sarter |
|
|
19 Feb 2013, 06:36
Message
#2
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 6 148 Inscrit : 31 Oct 2003 Membre no 11 118 |
Et ainsi chaque Apps apportera ses propres failles
-------------------- |
|
|
19 Feb 2013, 08:27
Message
#3
|
|
Adepte de Macbidouille Groupe : Membres Messages : 195 Inscrit : 17 Dec 2008 Membre no 127 626 |
Et ainsi chaque Apps apportera ses propres failles rien à voir. Les failles actuelles concernent des applets : ce sont des applications lancées dans un navigateur, pas des applications de bureau comme JDownloader, Eclipse, ... Après, je t'accorde qu'Oracle travaille mal sur sa réputation... |
|
|
19 Feb 2013, 08:52
Message
#4
|
|
Adepte de Macbidouille Groupe : Membres Messages : 218 Inscrit : 22 Mar 2006 Membre no 58 005 |
C'est une drôle d'idée mais pourquoi pas après tout - j'ose espérer qu'ils ont eu le ok d'Apple avant que d'annoncer ça !
|
|
|
19 Feb 2013, 09:38
Message
#5
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 32 183 Inscrit : 15 Nov 2005 Membre no 49 996 |
Et ainsi chaque Apps apportera ses propres failles Non.Le problème des failles avec Java, c'est que la JVM garanti normalement une certaine isolation entre l'environnement Java et l'environnement natif, mais qu'avec certaines failles, on peut passer outre cette isolation pour exécuter du code natif, avec un niveau de privilège plus élevé que celui auquel on aurait normalement droit. Ce problème est amplifié par l'existence de plug-ins de navigateurs, qui peuvent exécuter du code téléchargé depuis un site web, éventuellement à l'insu de l'utilisateur. Là on parle d'applications embarquant leur propre JVM et du code Java. Il n'y a donc pas d'exécution de code autre que celui de l'application. Et si ce code parvient à sortir de la JVM, il reste quand même bloqué dans la sandbox, comme n'importe quelle application native iOS. Niveau sécurité, c'est donc pareil : une application Java avec JVM embarqué pourra faire ni plus ni moins que ce que fait une application native. C'est une drôle d'idée mais pourquoi pas après tout - j'ose espérer qu'ils ont eu le ok d'Apple avant que d'annoncer ça ! Ils n'ont pas besoin du OK d'Apple.Leur solution respecte les règles de l'App Store (ie pas d'exécution de code extérieur à l'application autre que du JavaScript exécuté par le moteur JS d'iOS). Si Apple veut le bloquer, libre à elle... Mais ça ne sera qu'une nouvelle démonstration du caractère arbitraire des règles de validation d'Apple. -------------------- |
|
|
19 Feb 2013, 10:04
Message
#6
|
|
Macbidouilleur de vermeil ! Groupe : Membres Messages : 1 305 Inscrit : 22 Aug 2001 Lieu : Paris Membre no 668 |
Tu as l'article ? je ne l'ai pas trouvé.
On se parle d'un full Java SE ? Quid de la couche graphique, par exemple ? AWT & SWING ne sont tellement pas adaptés au touch... Il faut qqc de plus, comme l'a fait Dalvik qui a eu la bonne idée de ne pas les porter sur Android. Ou même encore comme l'avait fait l'antique J2ME. Pareil pour JNI, pas facile avec les contraintes d'Apple de le proposer, en tout cas en version compatible avec la VM desktop. Je serai assez surpris que la JVM soit standard, sinon il est quand même pas trop compliqué de télécharger (ou générer à la volée) du bytecode pour l'exécuter sans que l'OS y voit qqc. C'est quand même un peu plus puissant que Javascript. -------------------- MBP13 Early 2015 - Core i7.
|
|
|
19 Feb 2013, 10:13
Message
#7
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 5 429 Inscrit : 9 Apr 2004 Membre no 17 402 |
Un environnement de développement multi plateformes dont on parle trop peu est LiveCode
Il a le mérite d'être bien plus facile à appréhender et à mettre en oeuvre que Java ou Objective C. Ils vont porter le logiciel en Open Source pour donner la possibilité à tout un chacun de coder et partager ses créations : Ceci est une révolution ! LiveCode Kick starter Le site officiel : LiveCode -------------------- Exif Photoworker: Renommez et organisez vos photos et vidéos en quelques clics (téléchargement et période d'essai gratuits).
|
|
|
19 Feb 2013, 10:17
Message
#8
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 32 183 Inscrit : 15 Nov 2005 Membre no 49 996 |
Tu as l'article ? je ne l'ai pas trouvé. Cf source de la news.On se parle d'un full Java SE ? Quid de la couche graphique, par exemple ? AWT & SWING ne sont tellement pas adaptés au touch... Il parle de Java SE Embedded, donc normalement oui, c'est complet.Mais le but c'est à priori surtout de faire tourner JavaFX par dessus pour la couche graphique, plutôt que les couches graphiques plus "traditionnelles". Pareil pour JNI, pas facile avec les contraintes d'Apple de le proposer, en tout cas en version compatible avec la VM desktop. Je vois pas trop pourquoi. Mais j'ai pas beaucoup d'expérience avec JNI non plus...La seule fois où je l'ai utilisé, j'avais dû écrire des wrappers en C++ pour les fonctions de l'API C++ que je voulais utiliser via JNI, pour leur donner une interface compatible avec les types de données de JNI. Donc là je suppose que ça sera pareil, avec des wrappers en Objective-C. Je serai assez surpris que la JVM soit standard, sinon il est quand même pas trop compliqué de télécharger (ou générer à la volée) du bytecode pour l'exécuter sans que l'OS y voit qqc. C'est quand même un peu plus puissant que Javascript. Yep, techniquement c'est possible. Mais là c'est au process de validation d'Apple de le vérifier au cas par cas. Y a pas de raison qu'ils fassent un rejet systématique.Parce que des applications qui exécutent des binaires dans une VM ou un émulateur, ils en ont déjà accepté. Rejeter systématiquement celles le faisant en Java serait donc incohérent avec ce qui a été fait jusqu'à présent. -------------------- |
|
|
19 Feb 2013, 10:33
Message
#9
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 3 458 Inscrit : 23 Mar 2004 Lieu : Paris / Vancouver Membre no 16 640 |
Et ainsi chaque Apps apportera ses propres failles Non.Le problème des failles avec Java, c'est que la JVM garanti normalement une certaine isolation entre l'environnement Java et l'environnement natif, mais qu'avec certaines failles, on peut passer outre cette isolation pour exécuter du code natif, avec un niveau de privilège plus élevé que celui auquel on aurait normalement droit. Ce problème est amplifié par l'existence de plug-ins de navigateurs, qui peuvent exécuter du code téléchargé depuis un site web, éventuellement à l'insu de l'utilisateur. Là on parle d'applications embarquant leur propre JVM et du code Java. Il n'y a donc pas d'exécution de code autre que celui de l'application. Et si ce code parvient à sortir de la JVM, il reste quand même bloqué dans la sandbox, comme n'importe quelle application native iOS. Niveau sécurité, c'est donc pareil : une application Java avec JVM embarqué pourra faire ni plus ni moins que ce que fait une application native. C'est une drôle d'idée mais pourquoi pas après tout - j'ose espérer qu'ils ont eu le ok d'Apple avant que d'annoncer ça ! Ils n'ont pas besoin du OK d'Apple.Leur solution respecte les règles de l'App Store (ie pas d'exécution de code extérieur à l'application autre que du JavaScript exécuté par le moteur JS d'iOS). Si Apple veut le bloquer, libre à elle... Mais ça ne sera qu'une nouvelle démonstration du caractère arbitraire des règles de validation d'Apple. J'ajouterai que si actuellement les failles sont exploités si systématiquement c'est qu'elles permettent en fait d'exploiter assez facilement des failles du logiciel hote (pas seulement le navigateur...). Ensuite il faut tout de même relativiser encore leur gravité en les comparant avec les failles critiques que l'on trouve avec Flash, Adobe reader, et plus généralement sur les versions de Windows < 7. En fait je ne serai pas étonné si Oracle réussi a faire intégrer sa JVM dans iOS. Cela est tres facile puisque, en gros iOS c'est juste Mac OSX auquel on a remplace la couche d'interface graphique. La solution d'embarquer la JVM dans l'application est évidement réaliste, on peut par exemple faire des applications en Ruby pour iOS et elles passent sans pb sur l'App Store. Mais la multiplication des machines virtuelles va alourdir les applications et va surtout dehomogénéiser l'environnement, rendant la traque de bug de plus en plus difficile. De plus rentrer une machine virtuelle dans une app permet potentiellement d'introduire un vecteur de troyens considérable et va nécessiter un verrouillage supplémentaire de la part d'Apple. Se pose aussi le problème de la mise a jours en cas de faille. Si la machine virtuelle est dans l'app, c'est a l'utilisateur de mettre a jour chacune de ses app, donc il doit etre informé spécifiquement,... Ceci dit, je crois tres peu au développement multiplateforme grace a Java en dehors du monde corporate. Apple a installé Objective-C et maintenant Ruby comme environnement de développement dans ses OS et Java disparait de plus en plus des poste clients pour se cantonner sur les serveurs. Et une app ca ce conçoit avec Cocoa avant meme de parler de langage. De ce point de vu pour que l'app ait le look&feel iOS il faut qu'elle soit programmée en Cocoa directement, que le dev en comprenne la philosophie et l'ergonomie... Bref pourquoi devoir apprendre Cocoa et Objective-C pour devoir ensuite recreer l'experience utilisateur en s'escrimant avec Java SE et JavaFX? Va se poser la meme question sur Android, ou la ca va etre pire puisque on programme avec Java (mais pas la version d'Oracle) et a travers une API particulière. Le développeur devra choisir natif, ou JVM, avec les questions d'interfaces et de performances... Bref j'ai surtout l'impression que le but d'Oracle se cantonne au monde du corporate et installer Java sur des terminaux ARM qui arrivent en masse dans les entreprises est stratégique. Cela est meme un pas de plus pour préparer l'arrivée des serveurs et postes clients ARM. -------------------- Agnostique multipratiquant: Unixs, Linux, Mac OS X, iOS et un peu de Windows. Des Macs, des iDevices, des PC et des "ordinosaures"…
Citation « Celui qui t’entretient des défauts d’autrui entretient les autres des tiens. », Diderot« Quand on suit une mauvaise route, plus on marche vite, plus on s'égare. » |
|
|
Guest_anonym_8b8d481c_* |
19 Feb 2013, 11:25
Message
#10
|
Guests |
Je croyais que l'avenir était au html5/javascript alors bon pourquoi encore un 'nouveau' truc alternatif ...
aussi bien pour livecode que java sur mobile. Ce message a été modifié par anonym_8b8d481c - 19 Feb 2013, 11:25. |
|
|
19 Feb 2013, 11:37
Message
#11
|
|
Adepte de Macbidouille Groupe : Membres Messages : 208 Inscrit : 4 Mar 2010 Membre no 151 066 |
Si j'ai bien compris le but se serait pour le développeur d'écrire son application et de pouvoir sortir des versions ios et android sans surcharge de travail?
ça parait trop beau pour y croire vraiment. -------------------- 13'' mbp 2016, iPhone 7
|
|
|
19 Feb 2013, 12:39
Message
#12
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 3 458 Inscrit : 23 Mar 2004 Lieu : Paris / Vancouver Membre no 16 640 |
Si j'ai bien compris le but se serait pour le développeur d'écrire son application et de pouvoir sortir des versions ios et android sans surcharge de travail? ça parait trop beau pour y croire vraiment. Ben c'est le cas pour les OS desktop, il a y des applications 'metier' et opensource écrites en java et qui tournent sans presque de modification d'une plateforme a l'autre. Sauf que ce ne sont pas des applications Windows, Linux ou MacOS X, mais des applications Java, avec leurs interfaces bien particulières et leurs compromis. -------------------- Agnostique multipratiquant: Unixs, Linux, Mac OS X, iOS et un peu de Windows. Des Macs, des iDevices, des PC et des "ordinosaures"…
Citation « Celui qui t’entretient des défauts d’autrui entretient les autres des tiens. », Diderot« Quand on suit une mauvaise route, plus on marche vite, plus on s'égare. » |
|
|
19 Feb 2013, 12:46
Message
#13
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 358 Inscrit : 25 Nov 2007 Membre no 100 877 |
Et un gros lot de failles qui arrive avec Java
Ce message a été modifié par ziggyspider - 19 Feb 2013, 12:47. -------------------- How far can too far go ?
(The Cramps, Coluche & moi) iMac 27", i5 3,7 GHz, 40Go ram, VCV Rack, Blender, Arturia V serie, Adobe CC, Eurorack modulaire, Behringer Model D, Behringer Neutron, MS20 mini, Arturia MiniBrute, Arturia Beatstep Pro, Arturia Keystep, DarkTime, Dark Energy II, Akai EIEpro, Oxygen8, iMac 24", PowerBook G4, Power Mac G4 Silver, PowerMac G3, Mac SE … |
|
|
Guest_anonym_8b8d481c_* |
19 Feb 2013, 13:37
Message
#14
|
Guests |
mais maintenant les applications se font dans le cloud et plus en java sur mac linux et windows non ?
|
|
|
19 Feb 2013, 13:47
Message
#15
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 1 827 Inscrit : 11 Apr 2012 Membre no 175 864 |
Parce que des applications qui exécutent des binaires dans une VM ou un émulateur, ils en ont déjà accepté. Il ne me semble pas qu'iOS permet aux applications de générer du code natif et de l'exécuter. Ca serait pas plutôt une solution similaire à celle d'Adobe pour Flash : un outil qui fait le boulot de la VM (transcodage du byte code Java en code ARM natif) et crée ainsi une application native iOS ? |
|
|
19 Feb 2013, 13:57
Message
#16
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 32 183 Inscrit : 15 Nov 2005 Membre no 49 996 |
Il ne me semble pas qu'iOS permet aux applications de générer du code natif et de l'exécuter. Ca serait pas plutôt une solution similaire à celle d'Adobe pour Flash : un outil qui fait le boulot de la VM (transcodage du byte code Java en code ARM natif) et crée ainsi une application native iOS ? Non, il parle bien d'un portage iOS/Android, pas d'un simple compilateur produisant du natif.Et il me semble qu'Apple a déjà accepté des émulateurs, notamment pour certains jeux rétro, mais à la condition que les ROM soient embarquées dans l'application, et pas téléchargées. EDIT : c'est bien ce que Sega fait pour ses vieux jeux http://www.livetouch.fr/news/135611-SEGA_r...tion_sur_iPhone http://toucharcade.com/2011/01/27/segas-sh...rt-on-controls/ -------------------- |
|
|
19 Feb 2013, 14:58
Message
#17
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 1 827 Inscrit : 11 Apr 2012 Membre no 175 864 |
Je ne vois pas trop comment iOS peut s'assurer que le code qu'on lui demande d'exécuter a été transcodé depuis un fichier présent dans l'application, et non pas depuis un téléchargement. Je sais pas comment fonctionne l'émulateur de Sega, mais vu qu'il s'agit de vieux jeu, il s'agit peut-être d'un simple interpréteur.
|
|
|
19 Feb 2013, 18:09
Message
#18
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 468 Inscrit : 15 Mar 2004 Membre no 16 276 |
Je ne vois pas trop comment iOS peut s'assurer que le code qu'on lui demande d'exécuter a été transcodé depuis un fichier présent dans l'application, et non pas depuis un téléchargement. Je sais pas comment fonctionne l'émulateur de Sega, mais vu qu'il s'agit de vieux jeu, il s'agit peut-être d'un simple interpréteur. On parles de la validation de l'Appstore, là, pas d'une limitation d'iOS. Apple peut s'en assurer en regardant le code source de l'application, tout simplement. -------------------- Ma config Hackintosh :
CPU Intel Core i5 3570K - GPU Nvidia GeForce GTX660 - Carte mère Gigabyte GA-Z77-D3H - RAM 8Go DDR3-1600 - SSD Crucial M4 Dual-boot OS X 10.8 Mountain Lion/Windows 7 Pro 64 bits |
|
|
19 Feb 2013, 18:23
Message
#19
|
|
Macbidouilleur de vermeil ! Groupe : Membres Messages : 1 305 Inscrit : 22 Aug 2001 Lieu : Paris Membre no 668 |
Tu as l'article ? je ne l'ai pas trouvé. Cf source de la news.On se parle d'un full Java SE ? Quid de la couche graphique, par exemple ? AWT & SWING ne sont tellement pas adaptés au touch... Il parle de Java SE Embedded, donc normalement oui, c'est complet.Mais le but c'est à priori surtout de faire tourner JavaFX par dessus pour la couche graphique, plutôt que les couches graphiques plus "traditionnelles". Pareil pour JNI, pas facile avec les contraintes d'Apple de le proposer, en tout cas en version compatible avec la VM desktop. Je vois pas trop pourquoi. Mais j'ai pas beaucoup d'expérience avec JNI non plus...La seule fois où je l'ai utilisé, j'avais dû écrire des wrappers en C++ pour les fonctions de l'API C++ que je voulais utiliser via JNI, pour leur donner une interface compatible avec les types de données de JNI. Donc là je suppose que ça sera pareil, avec des wrappers en Objective-C. Je serai assez surpris que la JVM soit standard, sinon il est quand même pas trop compliqué de télécharger (ou générer à la volée) du bytecode pour l'exécuter sans que l'OS y voit qqc. C'est quand même un peu plus puissant que Javascript. Yep, techniquement c'est possible. Mais là c'est au process de validation d'Apple de le vérifier au cas par cas. Y a pas de raison qu'ils fassent un rejet systématique.Parce que des applications qui exécutent des binaires dans une VM ou un émulateur, ils en ont déjà accepté. Rejeter systématiquement celles le faisant en Java serait donc incohérent avec ce qui a été fait jusqu'à présent. Pour les 2, problème de validation made-in-apple. Ca fait 2 ans que je n'ai plus codé pour iOS, mais de mémoire, tu n'as pas le droit d'utiliser depuis ton code des apis non déclarées explicitement, et il faudrait avoir des headers d'Apple pour avoir le droit, non ? C'est vrai qu'il y a des apps à base d'émulateur. Moi je me suis fait refuser des apps parce qu'elles étaient capable de charger du code (javascript) qui peuvent en modifier le comportement. C'est trop facile, tu fais valider une app, et tu remplaces du code une fois installé. Il faudrait signer et lier au classloader cette signature, sinon, c'est open-bar. -------------------- MBP13 Early 2015 - Core i7.
|
|
|
19 Feb 2013, 19:03
Message
#20
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 1 827 Inscrit : 11 Apr 2012 Membre no 175 864 |
Je ne vois pas trop comment iOS peut s'assurer que le code qu'on lui demande d'exécuter a été transcodé depuis un fichier présent dans l'application, et non pas depuis un téléchargement. Je sais pas comment fonctionne l'émulateur de Sega, mais vu qu'il s'agit de vieux jeu, il s'agit peut-être d'un simple interpréteur. On parles de la validation de l'Appstore, là, pas d'une limitation d'iOS. Apple peut s'en assurer en regardant le code source de l'application, tout simplement. La validation se fait sur l'application compilée, pas sur le code source. |
|
|
20 Feb 2013, 15:25
Message
#21
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 1 736 Inscrit : 28 Oct 2008 Membre no 124 528 |
-------------------- AdBlock désactivé sur MB
|
|
|
20 Feb 2013, 15:40
Message
#22
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 32 183 Inscrit : 15 Nov 2005 Membre no 49 996 |
Et mal cité ^^
-------------------- |
|
|
Nous sommes le : 29th March 2024 - 15:18 |