IPB

Bienvenue invité ( Connexion | Inscription )

 
Reply to this topicStart new topic
> Oracle va proposer JavaFX et Java SE pour iOS, Réactions à la publication du 19/02/2013
Options
Rédaction
posté 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
Go to the top of the page
 
+Quote Post
hellomorld
posté 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 wink.gif


--------------------
Go to the top of the page
 
+Quote Post
Groumf29
posté 19 Feb 2013, 08:27
Message #3


Adepte de Macbidouille
*

Groupe : Membres
Messages : 195
Inscrit : 17 Dec 2008
Membre no 127 626



Citation (hellomorld @ 19 Feb 2013, 07:36) *
Et ainsi chaque Apps apportera ses propres failles wink.gif


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...
Go to the top of the page
 
+Quote Post
godzila
posté 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 !
Go to the top of the page
 
+Quote Post
SartMatt
posté 19 Feb 2013, 09:38
Message #5


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (hellomorld @ 19 Feb 2013, 06:36) *
Et ainsi chaque Apps apportera ses propres failles wink.gif
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.

Citation (godzila @ 19 Feb 2013, 08:52) *
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.


--------------------

Go to the top of the page
 
+Quote Post
GregWar
posté 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.
Go to the top of the page
 
+Quote Post
ekami
posté 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).
Go to the top of the page
 
+Quote Post
SartMatt
posté 19 Feb 2013, 10:17
Message #8


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (GregWar @ 19 Feb 2013, 10:04) *
Tu as l'article ? je ne l'ai pas trouvé.
Cf source de la news.

Citation (GregWar @ 19 Feb 2013, 10:04) *
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".

Citation (GregWar @ 19 Feb 2013, 10:04) *
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.

Citation (GregWar @ 19 Feb 2013, 10:04) *
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.


--------------------

Go to the top of the page
 
+Quote Post
r@net54
posté 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



Citation (SartMatt @ 19 Feb 2013, 09:38) *
Citation (hellomorld @ 19 Feb 2013, 06:36) *
Et ainsi chaque Apps apportera ses propres failles wink.gif
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.

Citation (godzila @ 19 Feb 2013, 08:52) *
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. »,
« Quand on suit une mauvaise route, plus on marche vite, plus on s'égare. »
Diderot
Go to the top of the page
 
+Quote Post
Guest_anonym_8b8d481c_*
posté 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.
Go to the top of the page
 
+Quote Post
moogly81
posté 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
Go to the top of the page
 
+Quote Post
r@net54
posté 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



Citation (moogly81 @ 19 Feb 2013, 11:37) *
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. »,
« Quand on suit une mauvaise route, plus on marche vite, plus on s'égare. »
Diderot
Go to the top of the page
 
+Quote Post
ziggyspider
posté 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 …
Go to the top of the page
 
+Quote Post
Guest_anonym_8b8d481c_*
posté 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 ?
Go to the top of the page
 
+Quote Post
downanotch
posté 19 Feb 2013, 13:47
Message #15


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 827
Inscrit : 11 Apr 2012
Membre no 175 864



Citation (SartMatt @ 19 Feb 2013, 10:17) *
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 ?
Go to the top of the page
 
+Quote Post
SartMatt
posté 19 Feb 2013, 13:57
Message #16


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (downanotch @ 19 Feb 2013, 13:47) *
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/


--------------------

Go to the top of the page
 
+Quote Post
downanotch
posté 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.
Go to the top of the page
 
+Quote Post
Glukx ouglouk
posté 19 Feb 2013, 18:09
Message #18


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 468
Inscrit : 15 Mar 2004
Membre no 16 276



Citation (downanotch @ 19 Feb 2013, 15:58) *
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
Go to the top of the page
 
+Quote Post
GregWar
posté 19 Feb 2013, 18:23
Message #19


Macbidouilleur de vermeil !
****

Groupe : Membres
Messages : 1 305
Inscrit : 22 Aug 2001
Lieu : Paris
Membre no 668



Citation (SartMatt @ 19 Feb 2013, 10:17) *
Citation (GregWar @ 19 Feb 2013, 10:04) *
Tu as l'article ? je ne l'ai pas trouvé.
Cf source de la news.

Citation (GregWar @ 19 Feb 2013, 10:04) *
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".

Citation (GregWar @ 19 Feb 2013, 10:04) *
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.

Citation (GregWar @ 19 Feb 2013, 10:04) *
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.
Go to the top of the page
 
+Quote Post
downanotch
posté 19 Feb 2013, 19:03
Message #20


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 827
Inscrit : 11 Apr 2012
Membre no 175 864



Citation (Glukx ouglouk @ 19 Feb 2013, 18:09) *
Citation (downanotch @ 19 Feb 2013, 15:58) *
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.
Go to the top of the page
 
+Quote Post
Webtourist
posté 20 Feb 2013, 15:25
Message #21


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 736
Inscrit : 28 Oct 2008
Membre no 124 528



Citation (Rédaction @ 19 Feb 2013, 06:03) *
Par Matthieu Sarter

cité par PCWorld.fr : ici wink.gif


--------------------
AdBlock désactivé sur MB
Go to the top of the page
 
+Quote Post
SartMatt
posté 20 Feb 2013, 15:40
Message #22


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (Webtourist @ 20 Feb 2013, 15:25) *
Citation (Rédaction @ 19 Feb 2013, 06:03) *
Par Matthieu Sarter

cité par PCWorld.fr : ici wink.gif
Et mal cité ^^


--------------------

Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



Nous sommes le : 29th March 2024 - 15:18