Discussion :

[cormnsa]

Bonjour,

Je suis assez embêté par la situation suivante.
Afin de traiter des fichiers json avec beaucoup d'imbrication, j'utilise la libraire com.fasterxml.jackson.

Lorsque j'ai voulu compiler, j'ai eu une erreur car il ma manquait le module java.desktop
Donc, en cherchant un peu, j'ai découvert qu'il me fallait un fichier module-info.java et par la même je découvre une fonctionnalité du JDK 9 (plutôt une source d'emmerde pour moi).

Avec IntellJ idea, je fais créer le fichier et j'ajoute la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

requires java.desktop;

Mais après, le programme à commencer à me mettre des errors à certains endroits.
Ainsi, j'ai en rouge (erreur) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;

et aussi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
import org.json.JSONArray;
import org.json.JSONObject;
import org.json.JSONTokener;

J'ai par ailleurs du aussi rajouté

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

requires java.sql

Il y avait un troisème import en rouge : or.jdesktop.swingx.

POur éliminer ce package, j'ai du changer mon interface pour abonner JTaskPanel..

Mais, j'ai un autre package qui utilise JXTable..
Je peux changer vers JTable, mais je ne sais pas ce que je perd en fonctionnalité

Donc mes questions sont :
JXTable vs JTable
Comment faire pour que org.json & com.fasterxml.jackson ne soient pas considéré comme des modules.

Dans ce projet, j'utilise pas Gradle ou Grovy, c'est un programme qui à plus de 20 ans.
Je choisi d'abandonner org.jdesktop.swingx à cause qu'il n'est plus maintenu... merci Oracle

[cormnsa]

Passer à JavaFX va me couter un certain temps en terme de développement et en plus, j'ai l'impression que la licence n'est pas simple du tout.

[bouye]

JavaFX est en OpenSource et n'a pas ce soucis de license particulièrement gênant (contrairement au JDK d'Oracle). Par contre le support technique optionnel propose par Gluon est payant.
Mais la n'est pas le cœur du problème.

Tu peux généralement continuer a faire des applications non-modulaires avec les JDK 9 a 23, mais il faut souvent rajouter des lignes de commande supplémentaires pour compiler et exécuter genre, sauf erreur de ma part, --module-path qui liste les repertoires a rajouter pour la recherche des modules et --modules qui liste tous les modules utilises (séparés par des virgules).

Après, ca fait pas mal de temps que je me casse plus la tete et que je fais des applications modulaires, ce qui s'active automatiquement quand on rajoute un fichier module-info.java a la racine des sources. Cela ne règle pas tous les soucis bien sur, par exemple les libs anciennes non-modulaires ont leur pseudo nom de module qui est généré d’après le nom du fichier JAR mais parfois certains IDE ont des soucis avec des nom trop complexes. De plus certaines libs tierces aiment pas la modularisation car ca casse certains trucs (entre autre l'introspection ou l’accès a des ressources sur des JAR séparés, les accès a des classes qui JDK qui ne sont plus désormais accessibles publiquement, etc.).

java.desktop fait partie des modules standards du JDK, donc y a pas vraiment de raison que JTable soit pas accessible dans une app non-modulaire ou modulaire. Par contre pour ce qui est de SwingX la je sais pas trop.

Faudrait tester chaque partie qui pose soucis sur des exemples / projets simplifies avant de tenter de mettre le bazar dans le gros programme de 20 ans d'age.
Quelle version de SwingX et Jackson utilises-tu ?

[bouye]

Pour ce qui est de SwingX, j'ai recupere dans le stockage Maven le dernier JAR d'un des forks qui ont continue le projet, puis j'ai cree une application non-modulaire Swing avec le JDK 23 dans IDEA et j'ai pu mettre une JXTable dans un petite appli de test sans soucis.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
package test.jxtable;
 
import org.jdesktop.swingx.JXTable;
 
import javax.swing.*;
import java.awt.*;
 
public final class Main extends JFrame {
 
    Main() {
        // Columns.
        final var columns = new String[]{
                "Id", "Name", "Hourly Rate", "Part Time"
        };
 
        // Data.
        final var data = new Object[][]{
                {1, "John", 40.0, false},
                {2, "Rambo", 70.0, false},
                {3, "Zorro", 60.0, true},
        };
        final var table = new JXTable(data, columns);
        table.setShowGrid(true);
//        table.setColumnControlVisible(true);
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        setLayout(new BorderLayout());
        add(new JScrollPane(table), BorderLayout.CENTER);
        setTitle("Test");
        setPreferredSize(new Dimension(800, 600));
    }
 
    public static void main(final String... args) {
        SwingUtilities.invokeLater(() -> launch(args));
    }
 
    private static void launch(final String... args) {
        final var main = new Main();
        main.pack();
        main.setVisible(true);
    }
}

[cormnsa]

Pour la librairie Jackson, j'utilise la version : 2.18
Pour jdesktop.swingx, c'est une version de 2011..

[cormnsa]

EN fait, ce qui me dérange, c'est que Intellj Idea me donne des erreurs alors que la compilation et l'usage de l'application est OK.



En plus, j'ai des librairies externe dont une qui permet au programme de faire des modèles de calcul en programmation linéaire.
J'utilise aussi les librairies apache common ftp, jopendocument, ...

Et toutes ces librairies (excepté celle de programmatio linaire) sont stockées dans un répertoire libs, je sais pas du tout comment faire pour aussi du même "projet" faire des modules.
J'utilise pas non plus gradle.

[bouye]

Ok, reprenons autrement. Qu'est-ce qui t'oblige a faire une app modulaire ?

Si jamais tu veux vraiment faire une app modulaire, comme mentionné plus haut, généralement (= marche pas tout le temps), il y a un mécanisme nommé auto-module qui permet aux anciennes libs de se comporter en modules.

Par exemple, dans mon cas d'hier le fichier de SwingX 1.7.0 que j'ai DL via le fork se nomme swingx-all-1.7.0-complete.jar. Lorsque j'ai voulu ajouter cette dépendance dans mon projet, j'ai défini dams IDEA une bibliothèque locale au projet nommée "swingx-all-1.7.0-complete" qui pointe vers ce JAR. Mon application d'hier était non-modulaire donc pas ce soucis, ca marchait direct.

Aujourd'hui, j'ai fait un second projet, repris exactement le meme code Java et ait juste rajouté un fichier module-info.java a la racine des sources ce qui transforme le projet non-modulaire en projet modulaire. Immédiatement IDEA se plaint de ne plus trouver Swing ou SwingX et souligne les import en rouge. Je fais ALT-ENTREE sur les import fautifs et choisi l'action "Add required xxx to module-info..:".
Ce qui me donne la description de module suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
module test {
    requires java.desktop;
    requires swingx.all;
    exports test.jxtable;
};

Donc a partir du nom de mon JAR swingx-all-1.7.0-complete.jar, Java peut inférer un nom d'auto-module swingx-all, J'ai quand meme été lire le fichier manifeste de ce JAR, mais il ne définit aucun nom ni aucune autre info pour l’identifier, et l'archive ne contient non-plus de donnée modulaire...

Sur ton screen tu peux voir que IDEA te propose déjà d'ajouter un nom d'auto-module pour jackson.databind car tu utilises cet import directement, qui doit correspondre plus ou moins au nom du fichier JAR utilisé. La ou ca va se compliquer, c'est pour les dépendances des dépendances, car l'IDE ne va pas pouvoir t'aider a la compilation et c'est probablement a l’exécution que ca va foirer... Il va donc falloir faire un peu d'approche exploratoire, soit en tentant de trouver les nom des auto-modules par toi-même*, soit en important des classes de ces libs a mano, de voir ce que propose IDEA pour les auto-modules, et d'aller corriger le module-info, etc. Alternativement, tu peux aussi tenter de modifier les JAR des libs que tu emploies pour ajouter des elements supplémentaires manquantes dans leur fichier manifeste respectifs pour faciliter le nommage de l'auto-module.

* et je n'ai toujours pas trouvé a ce jour de descriptif clair et precis des règle de generation de noms pour les auto-modules a partir des noms de fichier.

Voir : https://dev.java/learn/modules/automatic-module/

EDIT - la résolution se fait en suivant les règles édictées dans la méthode java.lang.module.ModuleFinder.of(Path... entries)

EDIT 2 -

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
package test.testmodules;
 
import java.lang.module.ModuleDescriptor;
import java.lang.module.ModuleFinder;
import java.nio.file.Paths;
 
public class Main {
    public static void main(final String... args) {
        final var path = Paths.get("<chemin vers les JAR des libs non-modulaires>");
        final var moduleFinder = ModuleFinder.of(path);
        moduleFinder.findAll()
                .forEach(module -> {
                    final var descriptor = module.descriptor();
                    System.out.printf("%s %s%n", descriptor.name(), descriptor.version()
                            .map(ModuleDescriptor.Version::toString)
                            .orElseGet(() -> "<undefined>"));
                });
    }
}

[cormnsa]

En fait, je veux pas faire une app. modulaire, c'est IntellJ Idea & java c (temurin) qui me rend fou.

J'avais un ensemble de class java regroupé dans un package (un fichier jar).
Suite au précédent échange et au fait qu'une bonne partie du code présent dans ce projet n'était plus utilisé, je décide de faire plusieurs petit ensemble.

Ce qui fais que maintenant, j'ai trois petit fichier jar.

1 pour de la génération de code HTML (aucun import)
1 pour des trucs utilitaires
1 pour des composants graphique (qui utilise notamment JXTable 1.6.6 (la seul version qui est compilée java 8 car les versions supérieur sont compliée en Java 17)

J'importe "en classpath" ces librairies dans le projet principal (en supprimant le gros fichier jar), je fais du replace des imports, ...

Je compile (build module), il m'affiche des erreurs, je corrige, tout vas bien.
Je lance ANT et je me prend une volée d'erreur



J'ai aucun fichier module-info.java, dans aucun projets.

J'avoue que c'est très embêtant, surtout que là, je ne sais plus faire de mise en production du programme car compile pas.

[cormnsa]

En plus, si je voulais utiliser un module-onfo.java complet, il faudrait que je puisse spécifier où sont les modules (en double du classpath).
Et pour cela, il faudrait que ant supporte les modules, ce qui n'est pas le cas.

Et s'il faut vraiment que cela soit le cas, il faut que j'ajoute dans le projet, un jar And-contrib pour gérer les modules.

J'adapte le programme le plus et aussi le plus critique, ensuite, afin de faire un réalignement, j'aurais au moins 5 autres programmes à adapter...

[cormnsa]

SOLVED... il fait juste que je fasse un clean du répertoire build

[bouye]

Une bonne nouvelle en soit.
Du coup c'etait probablement l'info qu'il me manquait : il s'agissait d'un projet compilant avec ANT et non pas avec le système de build propre a IDEA.