Java 6 (Nom de code Mustang) et Mac OS X

[Joelaloose]

Une nouvelle release de Java, apportant sont lot de nouveautés (à priori de nettes améliorations de performances (20 à 40% selon certains articles) vient de pointer le bout de son nez (plus d'info directement ici).
Seulement une fois n'est pas coutume les pocesseurs de mac sont laissé sur le bande d'arrêt d'urgence du dévelloppement Java.
Selon vous comment s'explique ce phénomène et peut on espérant une release pour nos architecture prochainement ?

 

[GrandGibus]

Si tu veux des infos concernant Java sur Mac OS X, c'est d'avantage chez Apple qui faut lorgner que chez Sun :hein:...

 

[Anonyme]

Une nouvelle release de Java, apportant sont lot de nouveautés (à priori de nettes améliorations de performances (20 à 40% selon certains articles) vient de pointer le bout de son nez (plus d'info directement ici).
Seulement une fois n'est pas coutume les pocesseurs de mac sont laissé sur le bande d'arrêt d'urgence du dévelloppement Java.
Selon vous comment s'explique ce phénomène et peut on espérant une release pour nos architecture prochainement ?

Selon les dernières rumeurs Steve Jobs aurait déclaré : «Java 6? Rien à battre!».

Je vous jure que c'est vrai...

 

[Joelaloose]

Je ne crache sur personne bien au contraire, pour être honète jusque là je ne savais pas d'ou provennais le problème....
D'un point de vue marketing il ne faudrait pas oublier que les développeurs aussi sont une cible potentielle et qu'ils utilisent des ordinateur.... c'est bien domage

 

[molgow]

Une nouvelle release de Java, apportant sont lot de nouveautés (à priori de nettes améliorations de performances (20 à 40% selon certains articles) vient de pointer le bout de son nez (plus d'info directement ici).
Seulement une fois n'est pas coutume les pocesseurs de mac sont laissé sur le bande d'arrêt d'urgence du dévelloppement Java.
Selon vous comment s'explique ce phénomène et peut on espérant une release pour nos architecture prochainement ?

Je dirais plutôt "Comme d'habitude"

Et puis je n'ai aucune idée des performances (même si tes chiffres me semblent bien grands), mais la JVM est de toute manière portée sur Mac OS X par Apple. Donc il se pourrait très bien que le gain ne soit pas présent sur Mac.

Et puis Java 1.6 n'apporte pas grand chose... enfin c'est mon avis

 

[claw59]

...et puis de toute façon le défaut indirecte de java pour mac, c'est qu'l est multi-plateforme.... donc tu peux inciter pour des raisons de gains financiers à faire migrer les developpeurs de mac vers pc.... alors qu'avec objective-c 2.0 .... il y a de fortes chances pour que cela consiste à faire migrer les dev de pc VERS le mac encore plus qu'avant...

 

[p4bl0]

...et puis de toute façon le défaut indirecte de java pour mac, c'est qu'l est multi-plateforme.... donc tu peux inciter pour des raisons de gains financiers à faire migrer les developpeurs de mac vers pc.... alors qu'avec objective-c 2.0 .... il y a de fortes chances pour que cela consiste à faire migrer les dev de pc VERS le mac encore plus qu'avant...

Pourquoi ?

Si le but c'est de faire du multi plateforme (le marché de java) je voit pas en quoi Objective-C (même 2.0) pourrait faire passer des développeurs sous mac... ?

ou alors j'ai raté une info

 

[claw59]

j'émettais seulement l'hypothèse d'une stratégie qui consiste à faire en sorte de s'intéresser d'abord au langage roi de la technologie mac, l'objective-c afin de valoriser le plus possible les technologies osx.

C'est quand même plus facile avec java de transporter des projets JAVA de mac <--->pc qu'avec objective-c [même si c'est un langage qui existe sous linux, tu ne pourras pas profiter de cocoa].

Puisque leopard n'intégrera pas java dans ces frameworks comme cocoa, les dev devront obligatoirement utiliser une partie de ce langage pour bénéficier des techno leopard... et donc le buz sur les performances du futur débogage xcode 3, rapidité annoncé d'objective-c, etc ...

Personnellement, objective-c est un langage très intéressant et très facile pour mélanger différents niveaux de complexité en passant par des langages différents .

 

[GrandGibus]

(...) Et puis Java 1.6 n'apporte pas grand chose... (../)

Euh... le pipeline OpenGL ? Ce peut être utile pour des projets genre Aerith .

C'est quand même plus facile avec java de transporter des projets JAVA de mac <--->pc qu'avec objective-c [même si c'est un langage qui existe sous linux, tu ne pourras pas profiter de cocoa].

Des projets Java qu'ils soient sur Mac ou sur autre chose restent multi-plateforme ou alors, le choix de Java perd de son sens.

Je me suis toujours demandé quel était le sens de faire du Java avec Objective-C, sachant qu'une des raisons d'utiliser Java est bien le multi-platforme et qu'un tel couplage le condamne... Autant faire de l'Objective-C :hein: ? Si quelqu'un avait un retour d'expérience à nous faire partager...

 

[Joelaloose]

Le seul intérêt serait de disposer de cocoa et d'utiliser l'interface graphique de mac os x... parceque sur ce point swing et awt ont souvent des problème de portabilité entre système je me souviens avoir mis en place un drag & drop swing il y a quelque temps et sous mac os.... le résultat était pas terrible.
Cela dit le portage entre os deviendrait très fastidieux si on devait passer par un langage "support" propre à chacun, et sur ce point je suis d'accord avec GrandGibus, autant ne plus faire de langage multi-plateforme si c'est pour en arriver là...

 

[claw59]

java --> récupérer et utiliser des services Web ou contenus web divers

c --> fabrication d'un algorithme

objective-c --> utiliser plusieurs algorithmes de façon dynamique (des structures statiques issues de core foundation contrôle la manière de faire évoluer son algo).

objective-c++ --> utiliser différents algorithmes d'abord de façon statique ( en fonction de critère utilisateur) qui engendre ceux dynamiques (en fonction de critères de réservation mémoire)

Dans ce genre de statégie, les choses sont un peu plus clair au détriment d'une certaine complexité d'implémentation. Ces considérations me sont personnelles et justifie mon intérêt pour l'objective-c : on peut faciliement jongler avec des techniques très diverses !!.

 

[claw59]

j'avais oubli&#233; un petit dernier......

Assembleur --> d&#233;tail de fonctionnement d'une proc&#233;dure langage 'C' pour optimisation d'un algorithme 'C'

donc au final, ....production de r&#233;sultat sous la forme de page web gr&#226;ce &#224; du contenu java produisant du contenu multim&#233;dia 3D ou 2D &#224; volont&#233; (&#224; condition d'avoir l'exp&#233;rience ....).

Il y a ainsi de quoi r&#233;aliser soi-m&#234;me de mani&#232;re tr&#232;s clair...des projets de taille cons&#233;quent....tout seul...
....enfin ... c'est mon avis sur la question

 

[GrandGibus]

java --> récupérer et utiliser des services Web ou contenus web divers

c --> fabrication d'un algorithme

objective-c --> utiliser plusieurs algorithmes de façon dynamique (des structures statiques issues de core foundation contrôle la manière de faire évoluer son algo).

objective-c++ --> utiliser différents algorithmes d'abord de façon statique ( en fonction de critère utilisateur) qui engendre ceux dynamiques (en fonction de critères de réservation mémoire)

Est-ce vraiment réaliste :affraid: : 4 langages différents dans le but de réaliser une seule et unique tâche ?
Dans un challenge "personnel" et "technique", je veux bien :mouais:... mais pas plus :rateau:.

 

[GrandGibus]

Le seul intérêt serait de disposer de cocoa et d'utiliser l'interface graphique de mac os x... parceque sur ce point swing et awt ont souvent des problème de portabilité entre système

Détrompe-toi, Swing a fait d'énormes progrès et l'implémentation sous Mac OS X est assez aboutie... La preuve:

​

 

[claw59]

Alors là GrandGibus,..... tu as probablement raison... mais il y a longtemps... j'avais un Atari 520 STF. ete à l'époque je me suis rendu compte que pour moi c'était très intéressant d'imbriquer plusieurs langages de nature différents... je codais une partie en 'C' dont les "plus précises" se faisait en assembleur dans le but de l'optimisation. je rassemblais le tout sous la forme d'une bibliothèque... dont je cherchais à automatiser le tout en GFA Basic....

Avec l'objective-c je retrouve ma facilité à jongler entre plusieurs langage. !!

 

[ntx]

Détrompe-toi, Swing a fait d'énormes progrès et l'implémentation sous Mac OS X est assez aboutie... La preuve:

Petit aparté : GrandGibus, avec quel outil fais-tu tes interfaces sous Swing ?

Claw59, pour pondre de nos jours un code assembleur plus efficace que ce que fait un compilateur, il faut quand même avoir un certain niveau.

 

[GrandGibus]

Petit apart&#233; : GrandGibus, avec quel outil fais-tu tes interfaces sous Swing ?

A la main :rose:.

[avis personnel]
Les layout de Swing sont difficillement utilisables pour qu'un builder d'IHM graphique soit ergonomique et convivial. De plus, le code g&#233;n&#233;r&#233; par ces outils est hiddeux. Du coup, je fais tout &#224; la main. Mais au final, avec un peu d'habitude on va aussi vite (voire plus) qu'avec un outil d&#233;di&#233;. La marche de d&#233;part est juste un peu plus haute.
[\avis personnel]

Petite pr&#233;cision, la capture d'&#233;cran n'est constitu&#233;e que de composants standards (i.e. JPanel, JLabel...) de Swing. Il n'y a pas de skin ou de UI particulier. Il y a juste quelques astuces (le JLabel accepte du HTML) et le packaging adapt&#233; &#224; Mac OS X (toute la ribembelle d'options -D...).

Claw59, pour pondre de nos jours un code assembleur plus efficace que ce que fait un compilateur, il faut quand m&#234;me avoir un certain niveau.

+1

 

[claw59]

L'assembleur... ça j'avoue que c'était seulement à l'époque de mon ATARI 520...mais aujourd'hui les fois où je m'en intéresse, c'est avoue tout pour comprendre des choses au niveau du débogage avec Xcode (fonctionnement d'adressage, de direction, de branchement,...), et c'est vrai que ce n'est pas facile de s'y retrouver vu qu'aujourd'hui les processeurs embarquent des techno spécialisés comme SSE....

mais C'est tout à fait exact qu'aujourd'hui pour faire quelque chose de potable en assembleur, il vaut mieux avoir des connaissances solides.

 

[Nicky Larson]

[avis personnel]
Les layout de Swing sont difficillement utilisables pour qu'un builder d'IHM graphique soit ergonomique et convivial. De plus, le code généré par ces outils est hiddeux. Du coup, je fais tout à la main. Mais au final, avec un peu d'habitude on va aussi vite (voire plus) qu'avec un outil dédié. La marche de départ est juste un peu plus haute.
[\avis personnel]

[avis personnel]
C'est totalement faux. Il suffit de jeter un oeil à Matisse sur netbeans pour s'en convaincre.
http://www.netbeans.org/files/documents/4/476/gui_builder2.swf
[/avis personnel]

 

[GrandGibus]

[avis personnel]
C'est totalement faux. Il suffit de jeter un oeil à Matisse sur netbeans pour s'en convaincre.
http://www.netbeans.org/files/documents/4/476/gui_builder2.swf
[/avis personnel]

Certes.... dans le cas d'une dialog toute simple, et sur laquelle il n'y a rien de dynamique.... Dès qu'on doit par la suite intervenir dedans et tomber dans un cas qui n'est pas prévu par l'IDE... aïë aïe aïe.

Et c'est sans parler du fait que tu te lies avec l'IDE ce qui est un handicap pour un travail d'équipe (tout le monde doit avoir le même IDE)...

Donc, je ne suis toujours pas convaincu ... mais je ne demande qu'à l'être...