Pourquoi offrir un cadre de développement et rester ouvert ? Parce qu'il existe une multitude d'applications ...
Tout code qui répond à son besoin est utile. Si un bon framework permet de faire le travail plus proprement et plus rapidement. Ce serait un tord de s'en passer.
Tout système se compose d'autres systèmes
Il y a autant de raison que de fonctionnalité non supportée (ex: génération PDF, accès aux bases NoSQL, etc.) ou buggée.
Un architecte "dessine" un cadre de travail qu'il s'agisse des technologies mais aussi de processus/méthode (y compris les moyens de formation des intervenants). Mais tout cela reste un plan qu'il convient d'ajuster par les retours pertinents des intervenants.
Il n'est pas question d'enseigner les principes de la performance et du multi-thread (sauf débutant), un développeur doit connaître cela car c'est son métier. L'architecte veillera à ce que les choix techniques soient cohérents (en tout temps) avec les besoins de l'application ; et notemment sa capacité à tenir la charge (en multithread ou non). Une raison de plus de sortir du standard.
J2EE a 16ans et Spring 12 ans. Le premier est un standard au sens de spécification et le second un standard de fait.
Trouver des solutions techniques d'implémentation est loin d'être le ressort de l'architecte. Et appeler un expert technique pour tout contournement me donne l'impression de passer à côté du métier de développeur.
Je ne connais pas l'environnement .Net mais je doute que Microsoft fournisse un standard pour tous ce qui existe (logs, TU, mock, messagerie, injection de dépendance, ESB, EAI, router, grille de calcul, cache distribué, etc.).
Et pourquoi pas ? Même si à mon sens c'est plus le rôle du développeur. J'ai souvent patché des COTS (Hibernate, JSF, RichFaces).
Ou alors ils font simplement avec, comme toi
Au delà de la correction, ce que je trouve intéressant c'est le débug (comprendre pourquoi ton utilisation ne fonctionne pas), éventuellement comprendre comment ca marche (utile surtout quand la documentation est absconse) et sourtout pour trouver des points d'extension (endroit où l'on peut injecter des changements).
Tout cela nous éloigne de la question initiale, est-ce que le langage Java est mourant. A mon avis, non. Il évolue au fil des ans pour prendre ce qui peut l'être "facilement". Même s'il y a de nombreux langages alternatifs (pour la JVM) intéressant (Groovy, Scala, Ceylon, JavaScript, etc.). Je pense qu'il demeura un langage "simple" et donc le langage standard pour la JVM.
Ca revient régulièrement sur Quora et autres. Et il me semble également que des gens l'ont déjà mentionné aussi sur DVP.
D'un certains point de vue, Scala est plus évolué que Java : traits, inférence, pattern matching. Il y a également le support "natif" des structures de données (list, map, tuple, destructuration).
Le support évolué de la programmation fonctionnel est aussi un argument.
Parce que le développement asynchrone est un très bon choix pour les environnements concurrents. Et que le paradigme fonctionnel permet de traiter très bien l'asynchronicité et la concurrence. Et comme on demande de plus en plus de choses aux SI, il faut bien en passer par là.
Après on en demande aussi de plus en plus parce qu'on sait en digérer de plus en plus. Mais quand on voit les retours pour les entreprises, elles n'hésitent pas à investir dans des applications de plus en plus gourmandes en données (et en traitements).
C'est surement un bon argument. Tant dans le fait que Scala permet de manipuler l'un aussi bien que l'autre indépendamment mais aussi (et surtout) ensemble !
Tout ce qui pourra tuer Java me convient. Donc gloire à Scala !
Plutot "esperent" que "pensent". Car il ne me semble pas que quiconque dans la communaute des developpeurs de Scala ait annonce cette intention, entame les demarches pour que Scala soit standardise via un JCP ou une JSR, et en fait il semblerait que "la majorite silencieuse" n'ait en fait pas besoin de tout ce qu'apporte Scala et se contente tres bien de Java.
Note que je ne suis pas oppose a cette idee, c'est juste qu'elle me parait vraiment lointaine.
Quand le bateau Java/JVM aura entierement coule, que tous les acteurs ayant capitalise sur Java le laisseront sombrer, alors Scala pourra en prendre la barre
Quand le bateau Java aura coulé, à mon avis, le bateau JVM restera, et il y aura bien un langage plus plaisant qui sortira après la compilation du bytecode.
Et donc, au fond, la grande force du combo Java -> JVM, c'est la JVM. Elle va subsister, mais pas forcément le Java. Et c'est cool pour nos ami-e-s de la DSI, parce qu'on pourra faire exister du legacy (en java) avec du tout beau tout neuf (peut être du scala). Ce n'est pas le cas de cobol ou autre dinosaurerie qui n'a pas de socle (comme la JVM) pour interagir avec le reste du monde. En résumé: vive la JVM, vivement que java rattrape son retard sur le C#.
On est bien d'accord. Avec en 5.0 des trucs extraordinaires comme l'asynchronisme. Ce qui m'étonne le plus, c'est que la VM de Microsoft n'ait pas plus pris. Mais c'est une autre histoire. En fait, le C# a pris le chemin inverse: un super langage, et une VM qui n'est pas standard. Dommage!
Je préfère préciser mes propos
Je pense que certains sont convaincus que ca arrivera un jour.
Je parle ni des développeurs, ni de "majorité". Juste qu'il y a un certains nombre de personne qui évoquent le sujet. Et comme je le précisai juste avant, je ne partage pas cet avis bien au delà des processus de standardisation requis.
Utiliser Scala comme langage principal est une chose, en faire le langage officiel en est une autre !
Quand la VM coulera, Scala suivra. L'un de ne va pas s'en l'autre. Et concernant Java, au pire, comme toutes les technologies Java, il restera une implémentation de référence d'un langage pour générer du bytecode comme l'est Glassfish pour les serveurs J2EE.
Par ailleurs, je pense que l'idée d'obligation d'une implémentation de référence pour toutes les JSRs est une grande force de Java.
Il y a déjà un grand nombre de langage alternatif pour la JVM : List of JVM languages
Java ne rattrapera jamais son retard sur C# car toute nouvelle fonctionnalité est longuement discutée avant d'être implémentée. Donc C# continuera à évoluer plus vite que Java ; sauf s'il est abandonné ou qu'on arrête l'innovation.
Pas tellement, non. La seule question, c'est la proportion de gens qui s'en servent. Que scala devienne un standard de fait, ou un langage officiel, ça ne change rien: la communauté va demander un paquet d'innovations, voire les réaliser. Oracle, s'ils sont normalement cablés, va courir aprèsl'argentses clients potentiels et suivre le marché. Si c'est Scala, même de manière pas officielle, peu importe!
Non plus. Quand la JVM d'oracle coulera, il existera une alternative open source pleinement compatible avec Scala. Et si Scala n'est qu'un effet de mode, Java ou un autre reprendra le devant de la scène. Ce qui, avec Spark, me parait peu probable, mais passons.
On est d'accord sur la pauvreté de l'innovation en Java. Microsoft suivant ses clients, je ne crois pas du tout, par contre, à un abandon sec du C#.
Sauf qu'Oracle n'est que propriétaire des marques et du (peu de ?) code qui reste encore "close source". Sachant qu'une majorité du code non ouvert n'est même pas la propriété d'Oracle mais de tiers ayant cédé le droit d'utilisation (protocole, compression, algorithme, etc.).
Tout ce qui concerne la JVM fait l'objet d'un processus piloté par un comité. Donc peu importe que la populace demande l'inférence de type, si le comité ne suit pas, cela n'arrivera pas. Après le comité représente la dite populace (éditeurs, JUGs, etc.). Donc pour devenir un langage officiel, il faudra passer par une JSR et ensuite cela imposera que toute évolution passe également par là.
Cela implique également que les propriétaires actuels de la technologie Scala (langage, compilateur, API, documentation, etc.) renoncent à leurs droits et acceptent de s'engagent dans ce processus ; ce dont je doute.
Que ce soit Scala, les applications qui se basent dessus et les librairies qui tournent autour (à base de Scala ou non) tous reposent sur la JVM (bytecode, JavaSE API, memory model, etc.). Donc la mort de la JVM signera également la mort de tout ce qui repose dessus.
Des langages ayant les mêmes fonctionnalités que Scala, cela existe.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager