Commentaires

  1. Avatar de chinagirl
    • |
    • permalink
    C'est une bonne nouvelle.
    Il faut que je trouve le temps d'essayer ça car j'ai commencé à porter des applis 8 en 12 et en 8 il y a le javapackager.

    Je trouve que fournir Java sans cela a été une erreur car dans le camp d'en face (Node), il y a des solutions qui fonctionnent (Electron) et choisies par Microsoft par exemple.
    Java devrait se mettre au moins au même niveau de façon à ne plus se poser 15000 questions quand on veut faire une appli desktop en Java.
  2. Avatar de Gugelhupf
    • |
    • permalink
    Nous avions eu quelques discussion avec la communauté à l'époque où la JEP 148 était créée, il était question d'avoir des applications Java ne nécessitant pas de machine avec une JRE pour fonctionner, et ne nécessitant pas d'embarquer un dossier contenant toute la JRE. GCJ étant obsolète, la JEP 148 semblait être une solution pouvant satisfaire ce besoin.

    Je sais bien qu'il n'y a aucun rapport entre Golang, jshell et jpackage (je pourrais presque me sentir offensé par ta réponse ), c'était à titre de comparaison entre Java et la concurrence.
  3. Avatar de bouye
    • |
    • permalink
    Salut,
    il n’y a aucun rapport entre les deux JEP, il suffit de lire leur descriptif. Le but de la JEP 343 est de créer des lanceurs et installleurs/désinstalleur natifs tandis que celui de la JEP 148 est de réduire la taille de la JVM (encore plus qu’actuellement et ce pour les machines embarquées - small devices est mentionné dans la description). À la rigueur la JEP 148 semble se rapporter aux fonctionnalités de jlink et serait une optimisation supplémentaire sur ce que cet outil peut faire actuellement. Après en combinant les deux ben ça permet d’avoir des applications plus légères à distribuer.

    Y a aucun rapport entre Golang, jshell et jpackage... ; le premier est un langage compilé, le deuxième est un environnement d’interprétation d’instructions écrites en Java et le troisième un outil de packaging... où as-tu bien pu chercher une telle idée...
    Mis à jour 07/09/2019 à 05h45 par Malick (correction de petites coquilles)
  4. Avatar de Gugelhupf
    • |
    • permalink
    Bonjour,

    Quels sont les différences entre la JEP 148: Small VM et la JEP 343: Packaging Tool ? Je pensais que la JEP 148 avait pour objectif de créer des applications Java natives.

    Est-ce que jpackage est une initiative pour concurrencer Golang ? (un peu comme comme jshell contre les langages de script)

    Merci pour le billet
  5. Avatar de bouye
    • |
    • permalink
    Une interview de Vos sur Jaxenter indique bien que le support Android est aussi dans les cartons
  6. Avatar de ScientificWare
    • |
    • permalink
    Il faut l'essayer !

    Il manque une plateforme dans la liste . J.V. ne la mentionne pas, ... j'espère qu'elle arrivera rapidement.
    J'avais testé le précédent plugin de Gluon sur Android mais, grosse déception, une partie de JavaFX-OpenJFX (Webkit) n'était pas opérationnelle.
    C'est le WebView d'Android qui remplaçait le navigateur (Webkit) de JavaFX-OpenJFX et il ne disposait pas d'interface JavaScript (non implémentée) ou du support MathML.
    Avec le nouveau plugin, c'est tout l'univers Java-OpenJDK/JavaFX-OpenJFX au complet qui arrive sur mobile. La version JavaFX-OpenJFX sera enfin la même pour toutes les plateformes.

    Mais pas seulement !
    Si je comprends bien c'est aussi tous les langages supportés par GraalVM, Java bien sûr, Python, ...
  7. Avatar de Mickael Baron
    • |
    • permalink
    Merci Fabrice pour la news.

    Ah si j'avais du temps pour tester, j'aimerais bien voir les possibilités de cette solution.

    Mickael
  8. Avatar de bouye
    • |
    • permalink
    Non ce tout premier billet a été fait sur fixe. Le second est en cours de rédaction sur mobile... et je crois bien que les suivants seront rédigés sur fixe à mon retour
  9. Avatar de Mickael Baron
    • |
    • permalink
    Merci @bouye pour ce retour.

    Tu veux dire que tu as écrit ce texte depuis un smartphone ? si c'est le cas respect ;-)

    En attendant la suite

    Mickael
  10. Avatar de PhilippeGibault
    • |
    • permalink
    Oracle aime emmerder son monde

    Tout ça fait que tous le monde va être perdant ... Oracle compris

    Bon, dans les solutions:
    JPA: Jakarta Persistence API
    JAX-RS:Jakarta API for RESTful Web Services

    si ça peut aider
  11. Avatar de 4sStylZ
    • |
    • permalink
    Le monde merveilleux de Java / Oracle / Eclipse.
  12. Avatar de bouye
    • |
    • permalink
    Citation Envoyé par ptyxs
    Quelque chose de neuf sur le développement en Java pour RPI, depuis 2015 ??? Merci pour tous liens, infos etc.
    Salut, c'est BellSoft qui distribue désormais les JDK les plus récents sur PI (https://www.bell-sw.com/java.html). Et pour le SDK de JavaFX pour ARM il faut aller voir chez Gluon (https://www.gluonhq.com)
  13. Avatar de ptyxs
    • |
    • permalink
    Quelque chose de neuf sur le développement en Java pour RPI, depuis 2015 ??? Merci pour tous liens, infos etc.
  14. Avatar de Rizzen
    • |
    • permalink
    Je suis pas fan, perso je n'en voie aucun intérêt à par que ça va devenir n'importe quoi. Surtout pour gagner 3 caractères en moins à écrire. #faignasse

    Quand je voie déjà comment sont utilisé des améliorations comme les lambda, qui apportent vraiment pas mal de souplesse. J'ai peur de voir des var partout et qu'on arrive plus du tout à comprendre et aussi avec des bugs à tour de bras car le compilateur décide d'un format différent de ce que croyait avoir le "dev". Je parle même pas de ceux qu'on appelle développeur en France mais qui ne connaissent rien à l'héritage ou au polymorphisme et pissent du code sans le comprendre T_T.
  15. Avatar de longbeach
    • |
    • permalink
    Dasoft: tout à fait.
    Merci à toi pour cette précision que je n'ai pas voulu apporter de peur qu'on m'accuse d'ajouter de l'huile sur le feu.
    De plus, je ne me serais pas amusé à faire cette comparaison avec C# s'il ne s'agissait pas aussi d'inférence de type.

    D'ailleurs, ce n'est pas une compétition : chaque langage s'inspire d'autre langage pour ajouter de nouvelles fonctionnalités et c'est très bien comme ça.
    C# a copié Java et Java a copié C#.
  16. Avatar de Dasoft
    • |
    • permalink
    Javascript implémente var parce que c'est un langage faiblement typé contrairement à C# et le langage Pascal a le mot clé var mais c'est pas du tout le même rôle donc hors sujet.
    Longbeach a raison de prendre le C# en exemple car il a été précurseur de l'inférence de type sur les langages fortement typé.
    Maintenant, vous pouvez vous serrer la main
  17. Avatar de longbeach
    • |
    • permalink
    Pas la peine de répondre de manière agressive.
    Ah mais je vois, c'est toi qui est l'auteur de ce billet. Je comprends mieux ta réaction ...
    Bon, comme d'habitude, vaut mieux se taire plutôt que d'essayer de participer sinon on obtient ce genre de réponse.
  18. Avatar de bouye
    • |
    • permalink
    Citation Envoyé par longbeach
    Le mot-clé VAR existe dans C# depuis 2007. Il y a donc plus de 10 ans.
    En Java, ça vient tout juste de pointer son bout du nez ...
    var existe en ECMA-Script depuis 1997 et C# a seulement attendu 2007 pour supporter ça ! Et ben dis donc.......................
    Mince ca existe en Pascal et d'autres languages depuis plus longtemps encore...

    Tu en as d'autres des remarques intéressantes et constructives ?
    Mis à jour 10/04/2018 à 00h35 par bouye
  19. Avatar de longbeach
    • |
    • permalink
    Le mot-clé VAR existe dans C# depuis 2007. Il y a donc plus de 10 ans.
    En Java, ça vient tout juste de pointer son bout du nez ...
  20. Avatar de bouye
    • |
    • permalink
    [Mise à jour le 02/03/2018]

    Jim Laskey a indiqué sur son compte Twitter que les résultats du sondage sont désormais disponibles.

    Source : Twitter
Page 1 sur 6 12345 ... DernièreDernière