Commentaires

  1. Avatar de bouye
    • |
    • permalink
    Oui c'est assez surprenant je trouve

    Il est possible qu'ils aient assez de clients demandant un support commercial pour que ce soit viable. Ou alors ils ont du mal a adapter leurs autres produits a des versions plus récentes de Java... et je doute que leur SGBD puisse supporter une cadence de maj a vitesse grand V comme celle qu'ils nous imposent.
  2. Avatar de Mickael Baron
    • |
    • permalink
    Merci Fabrice pour ce retour.

    J'ai comme l'impression que Java 8 est encore très utilisé pour que Oracle recule la fin du support.

    Mickael
  3. Avatar de bouye
    • |
    • permalink
    Merci, je pensais qu'il s'agissait d'un soucis avec le lien dans ma news mais c'est en fait sur la page de garde de développez. Donc c'est du ressort de la rédaction / de l'équipe de publication et non pas du mien. Je vais transmettre au responsable de section.
  4. Avatar de jcarbaut
    • |
    • permalink
    Je confirme le problème de lien :

    Sur la page https://java.developpez.com/ on a dans les actualités « Microsoft rejoint l'OpenJDK, la société derrière Windows contribue au développement du langage Java pour sa plateforme cloud Azure », avec pour url https://java.developpez.com/index/re...e-cloud-Azure/.
    Quand je clique, j'arrive sur une page d'erreur qui me dit « Vous n'avez pas les droits nécessaires pour accéder à cette page ».

    J'ai dû chercher le titre avec Google pour tomber sur l'url correct https://java.developpez.com/actu/282...e-cloud-Azure/.
  5. Avatar de bouye
    • |
    • permalink
    Citation Envoyé par ionel.cerp
    Quand on clique sur le lien, on ne peut pas lire l'article directement.
    Aucun soucis pour moi.
  6. Avatar de ionel.cerp
    • |
    • permalink
    Quand on clique sur le lien, on ne peut pas lire l'article directement.
  7. 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.
  8. 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.
  9. 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 à 06h45 par Malick (correction de petites coquilles)
  10. 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
  11. Avatar de bouye
    • |
    • permalink
    Une interview de Vos sur Jaxenter indique bien que le support Android est aussi dans les cartons
  12. 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, ...
  13. 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
  14. 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
  15. 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
  16. 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
  17. Avatar de 4sStylZ
    • |
    • permalink
    Le monde merveilleux de Java / Oracle / Eclipse.
  18. 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)
  19. Avatar de ptyxs
    • |
    • permalink
    Quelque chose de neuf sur le développement en Java pour RPI, depuis 2015 ??? Merci pour tous liens, infos etc.
  20. 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.
Page 1 sur 6 12345 ... DernièreDernière