Projet Coin : Les nouveautés dévoilées à la Java Community Conference d'Anvers

[sroux]

Bonjour,

Java 7 apporte t-il des nouveautés du côté de Swing et IHM?

Je suis loin d'être un expert Java, mais malgré les nouvelles versions Java reste toujours un langage très complexe pour les nouveaux venus, sans parler de la partie interface graphique complexe et qui n'est pas toujours très aidée par les IDE disponibles sur le marché - j'ai flirté Eclipse, et son pauvre Visual Editor Swing/SWT (ça existe encore VE d'ailleurs?), et Matisse sous Netbeans qui déchire mais reste cependant à des années lumière de la simplicité d'un VB6 ou Visual Studio.

Je dis ça sans être un pro MS ou VB et je suis conscient qu'il n'y a pas les mêmes budgets/priorités/cibles derrière tout ça... mais c'était juste une observation. Après il est vrai que j'ai fait mes débuts en VBA ...

[Baptiste Wicht]

Envoyé par sroux

Java 7 apporte t-il des nouveautés du côté de Swing et IHM?

Il n'y a pas beaucoup de fonctionnalités de ce côté-là, mais on compte tout de même :

• Un nouveau composant pour le choix de date qui vient de SwingX
• Remise à jour du JColorChooser
• Intégration du JXLayer sous la forme de JLayer

[pseudocode]

Envoyé par Gordon Fowler

Citons (en vo) l'arrivée du :

Est-ce à dire que le package "java.dyn" est abandonné (ce qui ne serait pas un mal, de mon point de vue) ?

[_skip]

Comment ça *encore plus*?
C'est un peu ce qui était annoncé par le post au début de ce topic non? Enfin si on enlève les binary litterals dont 950 pour mille des programmeurs java n'ont rien à cirer.

[adiGuba]

Envoyé par Baptiste Wicht

Il n'y a pas beaucoup de fonctionnalités de ce côté-là, mais on compte tout de même :

• Un nouveau composant pour le choix de date qui vient de SwingX
• Remise à jour du JColorChooser
• Intégration du JXLayer sous la forme de JLayer

Les deux dernières sont déjà intégré dans le derniers build de Java 7 (milestone 5).

Avec le report de la version finale en septembre il se murmure que Swing Application Framework pourrait peut-être être finalement intégré (mais bon il n'y a rien de vraiment sûr)

Envoyé par pseudocode

Est-ce à dire que le package "java.dyn" est abandonné (ce qui ne serait pas un mal, de mon point de vue) ?

Non il n'est pas abandonné : il est lui aussi déjà intégré

Et c'est loin d'être une mauvaise chose (même s'il ne concerne pas directement forcément beaucoup de monde).

Envoyé par _skip

Comment ça *encore plus*?
C'est un peu ce qui était annoncé par le post au début de ce topic non? Enfin si on enlève les binary litterals dont 950 pour mille des programmeurs java n'ont rien à cirer.

Les binary-litterals étaient déjà annoncé également.
Cette news n'est qu'une confirmation des travaux du projet Coin donné lors de la conférence Devoxx il y a quelques jours

a++

[pseudocode]

Envoyé par adiGuba

Non il n'est pas abandonné : il est lui aussi déjà intégré

Et c'est loin d'être une mauvaise chose (même s'il ne concerne pas directement forcément beaucoup de monde).

hum... Je ne remet pas en cause le InvokeDynamic dans le bytecode.

Mais son utilisation dans le langage Java me parait horriblement compliquée, ce qui est en totale contradiction avec la "simplification du langage" voulue par Java7.

[_skip]

Et justement puisque notre ami parle de GUI, le successeur de swing me semble du côté de javaFX, quelques progrès annoncés de ce côté?

[Baptiste Wicht]

Envoyé par _skip

Et justement puisque notre ami parle de GUI, le successeur de swing me semble du côté de javaFX, quelques progrès annoncés de ce côté?

JavaFX n'est pas Java

Les versions de JavaFX ne sont pas liées aux versions de java.

[_skip]

Il me semblait avoir vu passé un exemple d'UI javafx backée par du code java. Enfin ok, pardon pour ce HS

[Baptiste Wicht]

Envoyé par _skip

Il me semblait avoir vu passé un exemple d'UI javafx backée par du code java. Enfin ok, pardon pour ce HS

On peut effectivement faire des ponts entre les deux, dans les deux sens, mais ça reste des langages différents

[jahbromo]

Oui String dans switch est une tres bonne fonctionnalité. Ils doivent aussi essayer d'alleger AWT et SWING.

[adiGuba]

Envoyé par pseudocode

Mais son utilisation dans le langage Java me parait horriblement compliquée, ce qui est en totale contradiction avec la "simplification du langage" voulue par Java7.

En fait la simplification est indirecte : la majeure partie des développeurs ne vont pas y toucher directement.

Par contre cela va simplifier et optimiser l'implémentation de langage de script en Java, sans avoir à faire des manipulation de bytecode.

a++

[pseudocode]

Envoyé par adiGuba

En fait la simplification est indirecte : la majeure partie des développeurs ne vont pas y toucher directement.

Pas si sur. L'absence du "delegate" de C# se fait cruellement sentir en Java.

En particulier avec Swing et son obligation de créer des classes distinctes pour gérer chaque événement, ou ses problèmes de dispatch EDT/Thread.

C'était l'occasion de solutionner plusieurs problèmes d'un coup pour "simplifier" tout ca. Dommage.

[adiGuba]

Envoyé par pseudocode

Pas si sur. L'absence du "delegate" de C# se fait cruellement sentir en Java.

Je ne maitrise pas exactement le rôle des delegates, mais il me semble que cela pourrait être inclut dans la proposition des closures (même si le scope précis de cette proposition reste assez vague).


a++

[pseudocode]

Envoyé par adiGuba

Je ne maitrise pas exactement le rôle des delegates, mais il me semble que cela pourrait être inclut dans la proposition des closures (même si le scope précis de cette proposition reste assez vague).

Oui, c'est plus du ressort des closures... Mais il faudra alors "fusionner" les modifs du langage pour les closures avec celle des méthodes dynamiques. Alors que tout cela se ressemble furieusement au niveau de l'utilisation pour un développeur (en gros = des pointeurs de méthodes).

[joseph_p]

Envoyé par pseudocode

Pas si sur. L'absence du "delegate" de C# se fait cruellement sentir en Java.

En particulier avec Swing et son obligation de créer des classes distinctes pour gérer chaque événement, ou ses problèmes de dispatch EDT/Thread.

C'était l'occasion de solutionner plusieurs problèmes d'un coup pour "simplifier" tout ca. Dommage.

Hum, tu dis en substance qu'InvokeDynamic aurait pu aider là ? Ou tu parles juste des closures ?

Concernant les delegates C# et leur équivalent Java, j'avais dans l'idée que des anonymous inner class pouvaient faire l'affaire. Je me trompe ?

[adiGuba]

Pour le moment il n'y a rien de précis sur le contenu exact des closures de Java 7. Mais la proposition Closures for Java 0.6a se présente comme un compromis des différentes propositions et est considéré comme le document de travail pour leurs intégrations.

Dans cette proposition on peut obtenir une closure depuis la référence d'une méthode, c'est à dire approximativement quelque-chose comme cela :

Code :

1
2
3
4
5
6
// l'objet "this" doit contenir une méthode myMethod(ActionEvent)
// On affecte alors la référence de la méthode à la closure :
#void(ActionEvent) myClosure = this#myMethod(ActionEvent);
 
// Ceci est alors équivalent à : this.myMethod(event);
myClosure.invoke(event);

Mais une closure peut également être convertie en une interface compatible, donc on pourrait également écrire ceci :

Code :

1
2
3
4
ActionListener myListener = this#myMethod(ActionEvent);
 
// Ceci est alors équivalent à : this.myMethod(event);
myListener.actionPerformed(event);

Du coup, on devrait pouvoir écrire quelque chose comme cela :

Code :

this.addActionListener( this#myMethod(ActionEvent) );

Et je peux me tromper puisque je ne retrouve pas la source, mais il me semble avoir vu des discussions indiquant que les MethodHandles pourraient alors être utilisé de manière totalement transparente pour faire cela.

Envoyé par ZedroS

Concernant les delegates C# et leur équivalent Java, j'avais dans l'idée que des anonymous inner class pouvaient faire l'affaire. Je me trompe ?

Oui mais c'est vraiment très verbeux


a++

[pseudocode]

Envoyé par adiGuba

Oui mais c'est vraiment très verbeux

Tu m'étonnes. Sans parler de la "lourdeur" du code généré (des xx$yy.class partout) et de l'execution (creation, appel de méthode, garbage collection ...).

Par exemple, un clic bouton qui doit déclencher un calcul long :

Java 6:

Code java :

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
public class TestSwing {
 
	public static void createAndShowGUI() {
		// in EDT thread
		JFrame frame = new JFrame("---test---");
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.setContentPane(new JPanel());
		final JLabel label = new JLabel();
		JButton button = new JButton("START");
 
		button.addActionListener(new ActionListener() {
 
			@Override 
			public void actionPerformed(ActionEvent e) {
 
				label.setText("please wait..."); // in EDT thread
 
				new SwingWorker<String, Object>() {
 
					@Override
					protected String doInBackground() throws Exception {
						return doLongComputation(); // in background thread
					}
 
					@Override
					protected void done() {
						try {
							String result = this.get();
							label.setText("result is : "+result); // in EDT thread
						} catch (Exception e) {
							e.printStackTrace();
						}
					}
				}.execute();
			}
		});
 
		frame.add(button);
		frame.add(label);
		frame.setSize(200, 100);
	    frame.setVisible(true);
	}
 
	private static String doLongComputation() {
		try { Thread.sleep(1000); } catch (InterruptedException e) {}
		return "ok";
	}
 
	public static void main(String[] args) {
		SwingUtilities.invokeLater(new Runnable() {
		    public void run() {
		        createAndShowGUI();
		    }
		});
	}
}

Ce que ca pourrait donner avec les closures + appels dynamiques

Code java :

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
Public class TestSwing {
 
	@Background
	public static void buttonClick(JLabel label) {
		Swing.executeInEDT(label.setText, "please wait...");
		String result = doLongComputation();
		Swing.executeInEDT(label.setText, "result is : "+result);
	}
 
	private static String doLongComputation() {
		try { Thread.sleep(1000); } catch (InterruptedException e) {}
		return "ok";
	}
 
	public static void createAndShowGUI() {
		JFrame frame = new JFrame("---test---");
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.setContentPane(new JPanel());
		JLabel label = new JLabel();
		JButton button = new JButton("START");
 
		button.addActionListener( buttonClick, label );
 
		frame.add(button);
		frame.add(label);
		frame.setSize(200, 100);
	}
 
	public static void main(String[] args) {
		Swing.executeInEDT(createAndShowGUI);
	}
}

Perso, je préfère la seconde option.

[joseph_p]

A propos des anonymous inner class :

Envoyé par adiGuba

Oui mais c'est vraiment très verbeux

clair, mais elles font leur job et mon IDE est très bon pour cacher ce que je ne veux pas voir.

ceci dit, je ne remets pas en cause l'utilité des delegate, j'dis juste que, tout de même, le langage java a déjà des fonctionnalités similaires. Bref, ce serait un gain, pas une révolution.

[remoteberrada]

quelqu'un as il un lien vers le site officiel de java 7 ou il y as la liste des nouveauté apporté au language cvp ?