Des explications claires sur Java

Version imprimable

26/06/2015, 13h38
abc.xyz

Des explications claires sur Java

Bonjour,

1-Lorsque je regarde les offres Java, il n' y a que du Java EE et de l'Android. Quasiment pas de Java SE.
J'en conclus donc que les logiciels dans notre monde actuel se font préférentiellement en C et C++ par ex et presque jamais en Java.
Ce qui m'étonne d'autant plus que l'un des avantages majeurs de Java sur C et C++ c'est la portabilité. Les logiciels à l'aire de Java devraient se faire presque tout le temps en Java car il a cet avantage majeur de portabilité sur les autres langages.:roll:
Merci de m'éclairer.

2-Je suis devéloppeur web et j'ai Java comme compétence que je n'utilise jamais (je fais comme vous l'imaginez que de l'intégration et du PHP).
Cependant je me pose une question:
Si j'ai une idée de logiciel en Java SE à implémenter et que je le code ce logiciel, quels moyens s'offrent à moi pour vendre mon logiciel?

merci de votre aide.:D
26/06/2015, 14h25
eulbobo

Tu ne fais pas de JavaEE sans JavaSE.
JavaSE, c'est la brique de base pour tout le reste. JavaEE, c'est un ensemble de spécifications pour permettre l'utilisation à plus grosse échelle pour le développement d'applications plus conséquentes (web, connecteurs, temps réel...)

Donc oui, les applications JavaEE sont bien faites en Java...

Pour vendre ton logiciel? Ben ça dépend de la forme du logiciel... Web? Application lourde? Système de location applicative?
26/06/2015, 14h44
abc.xyz

merci de ta réponse cependant j'attends toujours la réponse à mes questions précises comparant l'utilisation de C et C++ à Java dans le monde des logiciels non web.(donc merci de ne pas me parler de Java EE). Pourquoi pour faire des logiciels non web et non android on demande des codeurs C++ et presque jamais des codeurs Java?Java est portable en plus par rapport à C++ c'est à n'y rien comprendre!;)
quant au logiciel que je veux vendre il s agit d'un soft non web.
26/06/2015, 15h09
eulbobo

Citation:

Envoyé par abc.xyz

Pourquoi pour faire des logiciels non web et non android on demande des codeurs C++ et presque jamais des codeurs Java?

Source?
Si tu parles d'application lourdes, ça dépend de l'application ! Il y a des tas d'outils, de bibliothèques et d'outils dans JavaSE pour faire des applications lourdes full java. Il y en a beaucoup d'ailleurs, notamment dans les logiciels embarqués qui utilisent souvent des versions allégées de de JavaSE : Java Micro Edition (JavaME).
Si tu parles d'application très graphiques (jeux vidéo par exemple), le C sera souvent préféré par culture/habitude ou juste par soucis de performance, les liens entre les différents frameworks graphiques étant eux aussi réalisés en C (ou assembleur)

Donc tu penses à quel type de logiciel quand tu dis que les codeurs C sont préférés?

Pour ce qui est des moyens pour vendre ton logiciel c'est les mêmes que pour tout le monde : faire un site pour le présenter, faire des démarches commerciales, aller le présenter à tes clients cibles, proposer des formations/démonstrations, faire de la publicité...
26/06/2015, 15h18
abc.xyz

Bien si demain je suis embauché par une société qui a l'idée je dis nimporte quoi de faire un super client FTP avec des fonctionnalités évoluées elle m'emploiera en tant que codeur C++ et pas Java.
Parce que dans le monde de l'informatique non web non android et non embarqué on ne code quasiment jamais en Java et je ne sais pas pourquoi. Toutes les offres de codeur java sont relatives à Java EE, android etc..on ne demande jamais un codeur Java pur et dur..(pur et dur dans le sens où ce ne serait ni du Java EE (donc web) ni de l'android(donc du mobile).
26/06/2015, 15h28
eulbobo

Si on t'emploie à faire une super client FTP en C, tu peux dire qu'on peut aussi le faire en java puisqu'il y a plein de bibliothèques qui te permettront de te concentrer sur l'utilisation de ton logiciel plutôt que la logique de l'échange de données.

Pourquoi on ne cherche pas de codeur Java pur? Parce que ça n'a pas réellement de sens. Si tu ne maîtrises que Java et aucun des frameworks/outils associés, tu va passer ton temps à réinventer des roues carrées.
Autre raison plus proche de la réalité? Les recruteurs n'ont aucune idée de ce qu'est Java et des distinctions qui s'y trouvent. Ils connaissent J2EE parce qu'il y a le mot Enterprise Edition dedans, et ils considèrent que tout développeur Java EST un développeur J2EE (même s'il n'en a jamais fait et qu'il ne travaille pas en J2EE)

Les recruteurs, ils cherchent des gens qui savent faire soit du Java, soit du JAVA J2EE RUBY SPRING STRUTS JSF JBOSS MVC GROOVY GLASSFISH TOMCAT ANT ORACLE MAVEN POSTGRES... Bref, des suites des mots-clés qui n'ont pas réellement de sens.
Mais si, ça existe des recruteurs qui en fait cherchent des gens pour faire du Java pur ! (encore faut-il savoir ce que c'est)
26/06/2015, 15h43
Nico02

Citation:

Envoyé par eulbobo

Les recruteurs, ils cherchent des gens qui savent faire soit du Java, soit du JAVA J2EE RUBY SPRING STRUTS JSF JBOSS MVC GROOVY GLASSFISH TOMCAT ANT ORACLE MAVEN POSTGRES... Bref, des suites des mots-clés qui n'ont pas réellement de sens.

Je plussoie.

Citation:

Envoyé par eulbobo

Pourquoi on ne cherche pas de codeur Java pur? Parce que ça n'a pas réellement de sens. Si tu ne maîtrises que Java et aucun des frameworks/outils associés, tu va passer ton temps à réinventer des roues carrées.

Et je plussoie encore plus.

Le fait est que maintenant savoir faire du Java pur n'est pas suffisant et qu'il tu faut maitriser un minimum son écosystème.

Après est-ce une mauvaise chose ? Comme le dit @eulbobo pourquoi réinventer la roue à chaque fois alors qu'il y a 99% de chance de trouver un outil/Framework/API qui fait ce que tu veux.
26/06/2015, 21h01
adiGuba
Salut,

Citation:

Envoyé par abc.xyz

Ce qui m'étonne d'autant plus que l'un des avantages majeurs de Java sur C et C++ c'est la portabilité. Les logiciels à l'aire de Java devraient se faire presque tout le temps en Java car il a cet avantage majeur de portabilité sur les autres langages.:roll:

Ce n'est pas tout à fait vrai. Il est tout à fait possible de concevoir une application portable en C/C++.
La principale différence c'est qu'il faut générer un binaire pour chaque cible.

Le problème de Java coté desktop, c'est qu'il n'a jamais réussi à s'y imposer.
Les raisons sont sans doute multiples et variés. En voici quelques une en vrac :
- Les applications desktop était déjà développées en C/C++.
- Les toutes premières versions de Java ont souffert du "Java c'est lent".
- AWT a souffert de nombreuses limitations (c'était portable mais limité aux fonctionnalités communes à tous les systèmes... et du coup c'était assez pauvre)
- Swing était plus riche, mais a souffert du conflit Sun/Microsoft sur Java (en gros à l'époque MS distribuait sa propre version de Java sous Windows... qui n'incluait pas Swing).
- L'intégration dans le système pouvait s'avérer complexe, car la moindre fonctionnalité avancée peut nécessiter de passer par JNI et sa complexité.
  Par exemple il a fallut attendre Java 6 (fin 2006) pour pouvoir afficher une icône dans la barre des tâche, ou ouvrir un fichier avec le programme associé.
a++
27/06/2015, 08h50
abc.xyz

Je n'ai jamais su pour quelle raison on disait "Java c'est lent..".
Ensuite si moi je décide de coder java desktop (et que le desktop n'a jamais réussi à s'imposer comme tu le dis), je vois pas ce qui m'empêche de vendre mon soft si il apporte (bien sur) des fonctionnalités intéressantes aux utilisateurs..Je ne souhaite en effet pas dire adieu à cette compétence que je possède sous prétexte que cette compétence n'a jamais réussi à s'imposer dans le monde du codage..:weird:
N'ais je pas raison?
27/06/2015, 10h05
adiGuba

Citation:

Envoyé par abc.xyz

Je n'ai jamais su pour quelle raison on disait "Java c'est lent..".

Les toutes premières versions de Java étaient simplement interprétée, et donc nettement moins performante qu'une application native.
Mais cela ne concernait vraiment que les deux premières années de Java (1996-1998).
Le compilateur JIT est arrivé dès Java 1.2 et a apporter des performances similaires... mais le "mythe" est resté.

Citation:

Envoyé par abc.xyz

Ensuite si moi je décide de coder java desktop (et que le desktop n'a jamais réussi à s'imposer comme tu le dis), je vois pas ce qui m'empêche de vendre mon soft si il apporte (bien sur) des fonctionnalités intéressantes aux utilisateurs..Je ne souhaite en effet pas dire adieu à cette compétence que je possède sous prétexte que cette compétence n'a jamais réussi à s'imposer dans le monde du codage..:weird:
N'ais je pas raison?

Je n'ai jamais dit que ce n'était pas possible ni viable.
Juste que ce n'était pas la techno la plus courante dans le domaine...

a++
27/06/2015, 11h55
tchize_

Pourquoi dire adieu à cette compétence? Je gage que tu es toujours aux études. Selon moi c'est plus les premiers postes que tu occupera dans ta carrière et les aléas de ton employeur qui auront tendance à orienter tes compétences que l'inverse. En formation on va t'apprendre à gérer pas mal de chose et ça va partir dans tous les sens. Après 2/3 ans de carrière t'aura déjà une forte tendance dans tes compétences, mais ça pourrait prendre un virage à 180° suivant les besoins de ton boss.

Concernant java SE, pour parler d'expérience concrète, j'ai changé de boulot récemment. Sur les employeurs que le bureau de recrutement m'a présenté, je dirait qu'environ 30% demandaient du JavaSE. L'un d'entre eux faisait du javaSE et du angluar JS, pas de couche J2EE pour gérer leur serveur, par exemple... Je bosse maintenant dans une boit où c'est pluri disciplinaire. Y a des gars qui font du mobile java, des gars qui font du web / J2EE 7, des gars qui font de l'embarqué en Java 2....

J'ai fait toute ma carrière pour le moment en java, ça fait plus de 10 ans, dès le premier jour de travail. J'ai été engagé au départ comme DBA, je me destinais en sortant des études à une carrière orientée sécu informatique et mon Travail de fin d'étude était en Fortran. Je me souviendrais toujours de mon premier jour de travail:

Citation:

On s'est trompé dans le recrutement, fallait un néerlandophone pour le DBA. Tu connais java?

Comme quoi, on ne peut pas vraiment prévoir :mouarf:

Aussi méfie toi des taux sur les offres de recrutement que tu trouve en ligne. Pas mal d'offre sont de la forme "pour un client situé à X, nous cherchons". En fait ça veux dire que pour un poste, 10 SSII cherchent et postent une annonce pour avoir le contrat. Et comme javaEE c'est du ronflant, ça fini toujours dans l'annonce même si pas nécessaire. Puis c'est un domaine où on cherche pas mal de gens compétents avec expérience. Qui dit expérience dit salaire plus élevé et tarification plus élevée pour la SSII. Donc les SSII ont tendance à mettre ce genre d'annonce même si elles n'ont pas de poste vacant. Comme ça un client potentiel voit sur leur site pas mal d'offre passée en Java EE et en concluent qu'ils ont un bon panel de senior J2EE et auront plus tendance à travailler avec eux... Situation similaire avec les bureaux de recrutement. Bref tant qu'on te présente pas chez l'employeur final, avec ce genre de boite, dis toi que le poste n'existe pas :mrgreen:
27/06/2015, 12h17
abc.xyz

explique moi stp la différence entre de l'interprété et une appli native.

merci
27/06/2015, 12h25
tchize_

une application native est compréhensible directement par le CPU. Quand tu met dedans qu'il faut additionner deux registre, le CPU fait une seule instruction.
une application interprété va lire l'instruction, va la décoder, va récupérer les données concernée, va exécuter l'opération et stocker le résultat elle même.

Donc alors que d'un code c = a+b va se traduire sur le cpu en

lire a dans un registre 1
lire b dans un registre 2
faire registre 1 + registre 2
ecrire registre 3 dans l'adresse c

soit 4 instruction,

dans la version interprétée, tu va avoir un code qui va faire des choses du genre

lire l'instruction dans registre
comparer avec -
comparer avec +
saut vers methode plus
lire opérande 1 dans registre 1
lire l'adresse réferencée par opérande 1 dans registre
lire la valeur à l'adresse présente dans registre 1 dans registre 3
lire opérande 2 dans registre 2
lire l'adresse réferencée par registre 2 dans registre 2
lire la valeur à l'adresse présente dans registre 2 dans registre 4
faire registre 3 + registre 4
lire nom de resultat dans registre 6
lire l'adresse réferencée par registre 6 dans registre 6
stocker la valeur de registre 5 dans l'adresse pointée par registre 5
retour methode plus

et encore pas mal des ces instruction réprésentent plusisuers instructions au niveau CPU, car chercher l'adresse de C en interprété, c'est pas mal de comparaison et d'itération dans une table de noms....

Bref du coup on gaspille tout plein de CPU.