Choisir des outils de développement Mac

[Bernard Senior]

Bonjour à tous,

Tout d'abord, mes félicitations à Thierry Santacana pour l'excellent site de Project:Omega et pour la qualité de ses traductions. En français, c'est quand même plus simple, non ?
Et puis... mon problème. Je suis confronté à un choix à faire dans les mois qui viennent concernant une migration vers d'autres outils de programmation et j'aimerais avoir l'avis de pros du secteur. Je programme depuis 1981 en autodidacte. J'ai une formation d'ingénieur (1976...la préhistoire !) et ai passé les 50 piges. Depuis 1994 je travaille sous FoxPro 2.5 Mac (SGBD langage XBase, programmation procédurale). J'ai développé deux applications principales d'environ 10 000 lignes de code chacune (Gestion de bibliothèque, gestion de fichiers d'adresses/VPC) + du menu fretin. Microsoft a abandonné FoxPro Mac en 1996. FoxPro 2.5 tournant toujours sous Mac 0S9, je ne m'étais pas trop alarmé. Le problème c'est que l'OS9 est petit à petit mis au placard au profit de Mac OS X. Si je ne fais rien et que je ne veux pas switcher sur PC , je vais droit dans le mur dans un avenir plus ou moins proche. Je gère actuellement un parc d'un trentaine d'ordinateurs (G3 B/B pour la plupart + quelques G4) + 3 PC (eh ! oui). Nous sommes sur Mac depuis 1987.
J'ai plusieurs possibilités, (il y en a probablement d'autres...) :
1. Migrer sous 4D.
2. Développer avec les outils XCode et Webobjects (maintenant gratuits mais pour combien de temps ?).
3. Utiliser le couple PHP/MySQL gratuit aussi.
Pour 4D, bien que le langage soit complètement différent, je me retrouve quand même en pays connu. Mais pour les deux autres, programmation objet et technique web... bon... pas trop évident pour moi. Je ne demande qu'à être convaincu mais il me faudrait des arguments massifs et percutants.
L'avis de ceux qui ont déjà été confrontés à un problème similaire me serait très profitable. Par exemple, combien de mois en moyenne (à raison de 35 h par semaine s'entend et sans y passer ses nuits !) il faut ramer à toute force avant d'être un peu à l'aise avec la programmation objet (en auto-formation).
Bien sûr, je tiens toute information complémentaire à votre disposition. D'avance merci.

Bonne année 2006 à tous.

 

[OlivierL]

Le passage à l'Orienté Objet me semble une bonne piste pour rester dans le coup.
Pour Java, le gros avantage, c'est la portabilité.
Tu développes aujourd'hui avec Eclipse (gratos) sous MacOS, et demain avec Eclipse sous Windows si besoin est.
Ou tu développes sous MacOS, tu déploies sur Unix...

Bon le passage à l'objet, on peut considérer qu'en 6 mois, tu auras acquis pas mal de chose, mais ca dépend tellement des gens.
Si tu programmes proprement en "procédural", tu programmeras proprement en objet, une fois les concepts compris. Le piège étant de coder en procédural, avec un langage objet, car là, y a pas de gain.

Et si je ne m'abuse, je crois que la dernière version de PHP est Orientée Objet également.

Bon courage.

 

[Bernard Senior]

Si tu programmes proprement en "procédural", tu programmeras proprement en objet, une fois les concepts compris. Le piège étant de coder en procédural, avec un langage objet, car là, y a pas de gain.

Merci de ta réponse et d'avoir pris la peine de me lire. Une grande part du problème est cette assimilation des concepts. La conception et la programmation orientées objet constituent un changement radical par rapport à la programmation procédurale standard. C'est cette radicalité qui me rend perplexe. Par où commencer ? Existe-t-il des tutoriels en français ? Pourquoi choisir Java plutôt qu'un autre langage ? Java ne me paraît pas d'un rapidité extrême à en juger par la lenteur de l'open source NeoOffice sur Mac.
Je programme du sur mesure pour une utilisation en interne. Pas question de déployer en externe. Je peux donc n'employer que des outils pour le Mac. Encore faut-il que ces outils soient perennes. Je me suis déjà foutu dedans avec FoxPro... bon. Je n'ai pas trop envie de recommencer. Qui me dit que WebObject a de l'avenir ? Des bruits de couloirs le donnaient déjà pour condamné. C'est difficile de s'y retrouver, non ? :o
A plus.

 

[GrandGibus]

Bonsoir,

Peut-être pourrais tu décrire d'avantage les besoins: le choix des outils (et des langages) se fait d'avantage en fonction des besoins et non l'inverse .

Pour revnir à certaines remarques: Pourquoi Java ?

• Parce qu'il est bien plus propre dans sa syntaxe (comparé à d'autres langage)
• Parce qu'il est multi-plateforme (mais faudrait voir tes besoins)
• Parce que beaucoup de solutions open source gravitent autour
• Une communauté sympa et hétéroclyte (because multi platforme)
• ... la liste pourrait être encore longue !

Comme très bien dit par OlivierL, le point de vigilence dans ton cas sera de ne pas faire du procédural en objet. Outre l'apprentissage de la syntaxe inhérente à l'objet (mais comme tout langage de programmation), il conviendra surtout d'apprendre... enfin, de comprendre les design patterns... Si tu passes à l'objet, ils seront tes meilleurs compagnons... et ce quelque soit le langage.

Pour WebObject, il s'agit d'une solution Apple pour faire facilement du J2EE (tout ce qui gravite autour du web en Java)... Là encore, dis-nous en plus sur tes besoins.

 

[Bernard Senior]

Peut-être pourrais tu décrire d'avantage les besoins: le choix des outils (et des langages) se fait d'avantage en fonction des besoins et non l'inverse.

Merci de tes avis. Ta remarque est très juste. Je voulais simplement ne pas être trop long pour amorcer la discussion et ne pas lasser le lecteur.
Pour les besoins, je vais me limiter à l'application maison qu'il me faut migrer en premier, à savoir une gestion d'adresses. Pour la gestion d'une bibliothèque, c'est moins pressé et on peut éventuellement acheter un progiciel tout fait (bon... c'est qd même aux alentours de 15 000/20 000 euros minimum).
Les outils basiques dont j'ai besoin sont une gestion de base de données et des outils pour gérer l'interface et les sorties papier. Les SGBD font cela très bien. J'aurais bien gardé FoxPro que je connais bien maintenant . Mais désirant rester sur Mac, je suis coincé. En plus, la possibilité de consulter sur intranet les fiches-adresses sans avoir à installer le logiciel sur tous les postes clients (Mac ou PC) serait vraiment bienvenue. 4D sait faire cela. Mais le choix de 4D est un choix définitif étant donné que le langage de 4D est propriétaire et il faudra mettre la main au porte-monnaie pour toutes les mises-à-jour. Les centaines de milliers de développeurs 4D augurent bien de sa pérennité et militent en sa faveur... Mais, bon..., je voudrais m'assurer que je mise sur le bon cheval. Puisse que je dois tout remettre à plat, je ne privilégie d'emblée aucune solution.
La base comporte une trentaine de fichiers. Le fichier-adresse est d'environ 35 000 fiches. Il y a environ 100 000 historiques. Mon interface est assez fournies : la fiche-adresse comporte environ 50 objets (champs, cases à cocher, pop-up, boutons...). Actuellement, tout cela tient sur un écran 1024x768 et c'est bien commode de n'avoir pas à faire défiler plusieurs écrans pour avoir une vue d'ensemble de la fiche. Il y a aussi pas mal de sorties papier : mailings, bordereaux transporteur, La Poste, comptabilité VPC... L'utilisateur peut modifier lui-même sans programmation les modèles d'impression. Voilà pour l'essentiel.
Ce qui me paraît séduisant dans les techniques objet, c'est la possibilité de réutilisation et de déclinaison du code. Ce qui est beaucoup plus difficile avec les fonctions de la programmation classique où, le plus souvent, on est obligé de dupliquer et d'adapter le code. Les techniques web, elles, permettent de s'affranchir de la plateforme et de n'avoir pas à distribuer le logiciel sur tous les postes clients. Elles ouvrent des possibilités qu'on ne peut envisager avec les programmes classiques.
Merci de m'avoir lu jusqu'au bout...

 

[GrandGibus]

[cirage_de_pompes ON]

C'est d'autant plus un plaisir de te lire jusqu'au bout qu'il n'y a pas de fautes d'orthographe tous les 3 mots (quoique pas souvent sur macgé comparé aux autres forums)... et en plus tu sais exactement dont tu as besoin et tu l'exprimes clairement !

[cirage_de_pompes OFF]


A la lecture de tes besoins, il est clair que Java et PHP sont des bons candidats.

A la facilité de PHP, on pourra opposer la capacité de Java d'intégrer des modules plus complexes. Sans vouloir froisser les supporters de php, il ne faut pas oublier que c'est un langage qui a été conçu à la base pour faire du web et uniquement du web... donc la partie de présentation des données. A ce titre, même les récentes évolutions du langage et ses rapprochements avec d'autres langages ne le permettront d'avoir le statut de VRAI langage de programmation. A titre d'exemple, essaie de faire du threading ou de l'asynchrone en php :rateau:.

Tout ceci pour dire que le choix se fera en fonction de la complexité fonctionnelle que ton programme devra rendre. Pour tout ce qui est présentation des données, sans soucis, c'est php qui sort grand vainqueur (facile d'apprentissage, dans la réalisation...). Par contre si tu dois intégrer un moteur de recherche basé sur une indexation de données (comme google) et pas un simple générateur de requêtes SQL, et que ce genre de fonctionnalité est d'une importance capitale... alors, il conviendra de considérer Java.

Dernier point, et la tendance récente le montre: le client WEB semble être le meilleur choix pour ton besoin (facilité de déploiement, migration des versions...)... on parlera alors d'application web.


Ceci n'est que mon avis et je n'ai pas non plus science infuse :rateau:.

 

[olof]

C'est clair que le client web est une bonne solution. Par contre, Bernard parle de sortie papier dont l'utilisateur peut gérer lui-même le modèle... A ce niveau, ça risque de pas être facile... A moins qu'il existe déjà des outils ?!?!

 

[Bernard Senior]

Tout ceci pour dire que le choix se fera en fonction de la complexité fonctionnelle que ton programme devra rendre. Pour tout ce qui est présentation des données, sans soucis, c'est php qui sort grand vainqueur (facile d'apprentissage, dans la réalisation...). Par contre si tu dois intégrer un moteur de recherche basé sur une indexation de données (comme google) et pas un simple générateur de requêtes SQL, et que ce genre de fonctionnalité est d'une importance capitale... alors, il conviendra de considérer Java.

Merci de tes compliments et de la qualité de cette discussion. Je m'efforce, en effet, de ne pas trop écorcher le français... C'est l'âge probablement...
Pour ce qui concerne la recherche des données, je travaille dans FoxPro surtout sur les index combinés : par exemple, pour appeler les fiches-adresses, Pays + Nom, ou Pays + Code postal, ou plus simplement Numéro de fiche. J'utilise SQL dont l'implémentation essentielle dans FoxPro est l'instruction SELECT. Le problème, c'est que ma version ne gérant pas le client-serveur et de plus le système de fichiers XBase n'étant pas une base SQL à proprement parler, les temps de réponses sont prohibitifs (3 à 4 minutes sur 35 000 fiches). En effet, les fichiers se baladent tout entiers sur le réseau (100 BaseTX). Je ne l'utilise que pour les mailings. Je n'ai aucune idée des temps de réponse que je pourrais obtenir dans une base SQL avec interrogations en PHP ou Java.
L'idée de pouvoir accéder à toutes les données des champs de mes fiches-adresses me sourie assez mais je n'en fais pas un absolu. Avec le système actuel, l'utilisateur tombe très rapidement sur la fiche recherchée (j'ai quand même à épurer régulièrement des doublons !). Ce serait seulement un plus.
Pour la base SQL, laquelle choisir ? Il y en a pas mal sur web.
Un dernier point. Si je me lance dans une application web, quels outils sont les plus rapidement assimilables outre le langage Java ou PHP à apprendre ?

Pour répondre à Olof

Par contre, Bernard parle de sortie papier dont l'utilisateur peut gérer lui-même le modèle... A ce niveau, ça risque de pas être facile... A moins qu'il existe déjà des outils ?!?!

C'est un outil assez puissant intégré au SGBD FoxPro. Cela permet des personnalisations assez poussées et des sorties de qualités puisse qu'il y a un éditeur avec outils graphiques. Mais là encore, je n'en fais pas un absolu...

 

[GrandGibus]

Quelques réponses en vrac:

Concernant le choix du moteur de la base de données, Mysql semble être tout désigné pour faire un bon candidat.

Les performances dans tes recherches ne dépendent pas du langage qui fait le requêtage (java...), mais du moteur proprement dit . De même, le réseau n'intervient pas dans l'exécution de la requête.

Pour le reporting, il faut peut-être regarder du coté de Jasper Reports. Bien que c'est du Java, il y aurait moyen de faire quelque chose tout en gardant du php... ou bien tout faire directement en php. A jeter un oeuil coté développements open source sur sourceforge... ça fourmille de modules php.

Si le reporting est la seule fonction avancée, php me semble donc être la voie à suivre... car coté technos Java, la marche est beaucoup plus haute, pour un gain incertain.

 

[cretinoïde]

Quand à moi, je te donne mon avis de développeur Cocoa.

Quitte à "migrer" de Foxpro autant le faire vers en priorité vers :

4D ou FileMaker.

Ensuite, quitte à faire quelque chose de plus évolué, sophistiqué et puissant, autant le faire sans Java mais en Cocoa.

Dans ce dernier cas, surtout pas de MySQL mais SQLite qui est le micro-moteur intégré idéal pour une "application nouvelle génération". CoreData est aussi un tres bon choix technique bien qu'audacieux.

 

[GrandGibus]

Une amorce de débat... Selon toi, quelles raisons amènerait à faire les choix que tu cites ?


... Non pas que je sois d'accord ou pas, mais pour mieux mettre au clair les avantages et les inconvénients de chacune des options possible à notre ami...

 

[Nicky Larson]

Apparemment, il y a des macs ET des PCs. Je ne vois pas trop comment cocoa pourrait l'aider.

 

[molgow]

Je partage l'avis de GrandGibus. L'application web me semble une bonne solution. Ça facilite la distribution, l'utilisation multiplateforme et la création des interfaces graphiques. Après J2EE est quand même un monstre qu'il est difficile à apréhender. PHP est au contraire plus facile, mais il faut savoir bien l'utiliser car il est vite fait de coder pas propre à la "façon procédural".

 

[Didier Guillion]

Bonjour,

Une question qui me turlupine et qui a trait aux outils de développement basés sur Obj-C/Nibs/Cocoa.
Enormément d'informations étant rangées dans les Nibs qu'utilisez vous comme outil pour vérifier que les Nibs des différentes langues sont bien synchronisés. J'ai une appli basés sur des Nibs en 6 ou 7 langues différentes et c'est vraiment un gros boulot de vérifier cela a la main. Et encore l'appli n'a qu'une dizaine de boite de dialogue...

Cordialement

 

[Bernard Senior]

Merci à tous pour vos contributions. Je ne pensais pas que ma question susciterait autant de réponses...

Quitte à "migrer" de Foxpro autant le faire vers en priorité vers :
4D ou FileMaker.

Ton avis n'est pas "crétin" . 4D fait partie des possibilités. Je l'ai pratiqué un peu et je dois dire qu'il fait tout ce que fait FoxPro et bien plus puisqu'il est ouvert sur le web. Ma seule objection contre 4D est que c'est un langage propriétaire et que ce choix s'avère définitif, pour autant qu'il puisse se maintenir indéfiniment..., avec l'obligation de passer au guichet à chaque mise-à-jour.
Pour FileMaker, il y a un truc vraiment gênant, c'est l'impossibilité d'exécuter un script quand on quitte un champ ou un objet. Les utilisateurs le réclament à cor et à cri. Du reste, je ne sais pas quelle astuce ils ont trouvée pour s'en passer.

Tout ceci pour dire que le choix se fera en fonction de la complexité fonctionnelle que ton programme devra rendre.

Il me semble être passé à côté de ton expression complexité fonctionnelle. Me permets-tu d'y revenir ? J'ai pensé qu'une copie d'écran vaut mieux qu'un long discours. Au premier plan, le formulaire d'expédition VPC. En arrière plan, une partie de la fiche-adresse avec les historiques et la liste des fiches à gauche. Il y a pas mal d'interactions entre les objets avec beaucoup de contrôles et messages d'alertes pour vérifier la cohérence des enregistrements. Ce module est un des plus complexes (1750 lignes dBase). Le programme comporte plus de 50 formulaires, dont la moitié environ sont simples. J'ai peut-être un peu sous-évalué le nombre de ligne de mon appli car je n'ai pas de compteur.
Comme tu peux le voir sur la copie d'écran, le formulaire fait pas mal de chose à la fois : comptabilité (on enregistre les ventes comptant, c'est donc ce module qui permets de générer une facture VPC qui regroupe toutes les ventes d'une période), traitement de la commande, statistiques avec le code pub., articles et emballage, poids pour éditer en auto les étiquettes colissimo avec le logiciel de La Poste Expeditor i-net (qui tourne sous Virtual PC). En sortie, on édite une liste des colis à faire, la course correspondante (tous les articles à sortir du stock), les bons de colisages à mettre dans les colis.
Il y a aussi beaucoup de raccourcis-clavier pour gagner du temps à la saisie. Comment un navigateur web peut-il gérer cela ? S'il faut cliquer partout, cela devient rapidement la galère.

Voir la pièce jointe 8343

 

[SuperCed]

Une appli orientée web te donnera un accès quelque soit la machine et te permettra de concentrer tes données.
Le choix est donc maintenant restreint à php ou Java (J2EE).

Je te conseille php/mysql. C'est éprouvé, facile d'accès, rapide. Tu trouveras énormément de documentation.

J'ai pu tester un peu J2EE, mais pour moi, ça ne vaut pas le php, certe plus simpliste mais plus rapide pour le développement et les tests.

Molgow, je ne suis pas trop d'accord avec ta phrase qui dit associe le codage procédural avec du "mauvais" codage. Je pense qu'en objet comme en procédural, on peut mal ou bien programmer. La bonne ou mauvaise programmation est de toutes façons plus ou moins subjective.

PHP est pour moi, vraiment un langage qui sort du lot. Quand, en local, on peut discuter sur le C/C++/ Java pour savoir quel est le meilleur, sur le web, on ne discute plus trop la supériorité de php, même si certains cas bien précis s'adapte mieux à Java (surtout quand il y a déjà un existant dans ce même langage).

 

[GrandGibus]

Si le choix du web est fait uniquement pour des questions de migration, déploiement... tu peux déployer très facilement et à grande échelle en faisant du Java WebStart.

De plus, à regarder ton appli, il y a l'air d'avoir énormément de contraintes ergonomiques. Là, sur ce plan le web ne peut rivaliser avec du client lourd !

Une solution pourrait être de développer ton application en Java standard (donc pas de web)... et n'ouvrir que les fonctionalités qui le méritent au web (facilement faisable). Ceci serait bien entendu valable que si le nombre de ces fonctions est restreint.

Pour résumer donc: si grosse contrainte d'ergonomie, liée à une utilisation majoritairement en intranet: Java (Swing) redeviendrait mon choix principal.

Si par contre, tu veux faire de la consultation massive distante, alors il faudra dire un peu adieu à l'ergonomie et passer à du php.


A noter que Swing n'est pas compliqué à apprendre, possède un modèle objet pas trop mal foutu (comparé à MFC, pour ceux qui connaissent ). De plus, il n'est pas si lent que ça, et on peut faire des choses qui ressemblent vraiment à du mac os en Swing (la preuve).

 

[molgow]

Molgow, je ne suis pas trop d'accord avec ta phrase qui dit associe le codage procédural avec du "mauvais" codage. Je pense qu'en objet comme en procédural, on peut mal ou bien programmer. La bonne ou mauvaise programmation est de toutes façons plus ou moins subjective.

Oui, je me suis pas très bien exprimé. Ce que je voulais plutôt dire c'est que PHP permet de faire de l'objet, mais ne t'y contraint pas... et donc c'est vite fait de tomber dans le piège d'utiliser des objets mais de programmer en procédural... ce qui donne qqch de très moche !

 

[Bernard Senior]

Bon... Je crois qu'on a avancé d'un grand pas et qu'on arrive bientôt au bout.

De plus, à regarder ton appli, il y a l'air d'avoir énormément de contraintes ergonomiques. Là, sur ce plan le web ne peut rivaliser avec du client lourd !

Pour l'ergonomie, il m'est difficile d'y renoncer pour les postes de production. En effet, quand tu reçois, après un mailing catalogue, 100 commandes le 1er jour, puis 80 le second, puis 60..., (ce n'est pas La Redoute quand même!) si ton programme n'est pas rempli d'automatismes, de raccourcis, de contrôles de cohérence, c'est rapidement l'engorgement avec pour conséquence des retards et erreurs dans les envois, ce qui est du plus mauvais effet. :mad:

Une solution pourrait être de développer ton application en Java standard (donc pas de web)... et n'ouvrir que les fonctionalités qui le méritent au web (facilement faisable). Ceci serait bien entendu valable que si le nombre de ces fonctions est restreint.
Pour résumer donc: si grosse contrainte d'ergonomie, liée à une utilisation majoritairement en intranet: Java (Swing) redeviendrait mon choix principal.

D'accord pour un client lourd pour les postes qui ont l'accès à l'ensemble des fonctions. D'accord aussi, pour un accès limité par intranet (en fait la consultation et éventuellement la modification des adresses). Il n'est pas question pour moi de consultation massive à distance.

Pour me lancer dans Java sans perdre trop de temps, il faudrait que tu puisse m'indiquer les raccourcis pour démarrer. J'ai regardé un peu sur Google Java et Java Swing (ton interface CCAM+ est superbe ! ). C'est la forêt ! Comment ne pas s'y paumer ! Voici quelques unes de mes interrogations :
1. Qu'est-ce qu'il faut installer sur Mac pour commencer à programmer en Java ? Editeur, compilateur ? Où trouver cela ?
2. Quel Interface Builder s'il en existe ? Quelle base de données ? Pilote JDBC ?
3. Quel tutoriel progressif choisir en français (le meilleur évidemment) ? Je lis l'anglais mais passé un certain degré d'abstraction technique, je suis largué. Si déjà c'est difficile à comprendre en français, alors l'obstacle de la langue ne fait qu'empirer la situation.
4. Parmi les bouquins proposés sur Project:Omega, quel est celui par lequel commencer en toute sécurité ? Puis, que choisir comme manuel de référence ?
5. Enfin, last but not least, il se peut que la marche s'avère trop haute pour moi (faut rester modeste ! ), quel délai minimum me donner avant de jeter l'éponge et me rabattre sur 4D ? Mes responsables n'apprécieraient pas trop que je passe 6 mois à me former pour finalement aboutir à une impasse.
Merci pour tout.

 

[GrandGibus]

Tant mieux si tu y vois un peu plus clair . Voici quelques réponses en vrac:

1. Qu'est-ce qu'il faut installer sur Mac pour commencer à programmer en Java ? Editeur, compilateur ? Où trouver cela ?

Java est par défaut en standard sur mac os x.
De l'avis de beaucoup de gens (moi compris), Eclipse est l'un des meilleurs IDE (open source) du marché. Par contre, il est relativement gourmand, et tu pourras pester contre quelques lenteurs quand tu maîtriseras tous les raccourcis . Attention toutefois, il fait un peu peur au début, mais pas de panique.

2. Quel Interface Builder s'il en existe ?

Il existe de nombreux interface builder... mais aucun n'est vraiment convaincant. Je suis moi-même assez opposé à ce genre d'outil, surtout lorsqu'il s'agit de dépasser le cadre du simple maquettage. Là, c'est un point, je l'avoue, qui pourrait se révéler rédhibitoire au début: les interfaces sont codées à la main. D'un autre coté, cela t'apporte la maîtrise totale de ton code. Perso, je vais plus vite à la main qu'avec un builder...

2. Quelle base de données ? Pilote JDBC ?

MySQL ! Il est dispo sous mac en distrib binaire. Le seul reproche (mais ça n'en est pas un pour toi), c'est qu'il est soumis à des contraintes pour le redistribuer. Sinon, que du bonheur. Tu trouveras des pilotes JDBC qui vont avec. D'ailleurs, la question de l'accés à la base de données est entière: peut-être envisageras-tu d'utiliser un ORM comme Hibernate/ ?

3. Quel tutoriel progressif choisir en français (le meilleur évidemment) ?

Je passe ... Peut-être chez developpez.com ?
Par contre, je me souviens avoir beaucoup utiliser les tutoriels de chez Sun pour tout l'apprentissage de Swing (le bon choix à mon avis pour ton programme comme librairie IHM).

4. Parmi les bouquins proposés sur Project:Omega, quel est celui par lequel commencer en toute sécurité ? Puis, que choisir comme manuel de référence ?

Je passe ...

5. Enfin, last but not least, il se peut que la marche s'avère trop haute pour moi (faut rester modeste ! ), quel délai minimum me donner avant de jeter l'éponge et me rabattre sur 4D ? Mes responsables n'apprécieraient pas trop que je passe 6 mois à me former pour finalement aboutir à une impasse.

Tout dépend de l'implication que tu mettras à l'apprentissage. Au début cela te fera un gros volume de nouveautés à absorber. Cependant, la communauté est sympa... Tu peux poster ici-même d'ailleurs. Je me souviens être passé à Java après une semaine de formation. Le seul point critique à mon avis est sur la conduite de projet elle-même. Il faut que tu appréhendes les problématiques dans le bon ordre si tu ne veux pas te trouver noyé sous des tonnes de docs ... mais ton expérience devrait t'aider sur ce point.

Peut-être pourrais-tu négocier une semaine de formation à Java ?

A voir sinon avec les modos du forum, s'il n'y a rien de confidentiel dans l'appli, tu peux ouvrir un fil consacré à cette dernière. Tu peux également te lancer dans l'avanture Open Source (et ainsi avoir de l'aide)...