JavaFX - Revision history

JaroslavTulach at 07:28, 15 July 2014

JaroslavTulach — Tue, 15 Jul 2014 07:28:18 GMT

←Older revision		Revision as of 07:28, 15 July 2014
Line 57:		Line 57:
	</source>		</source>

-	The only problem is that this change has been integrated only for [[OS X]] toolkit! I am not sure what the [[Swing]] guys were smoking? Why they didn't integrate the behavior into all AWT ~~toolkit~~?	+	The only problem is that this change has been integrated only for [[OS X]] toolkit! I am not sure what the [[Swing]] guys were smoking? Why they didn't integrate the behavior into all AWT toolkits?

	But who cares about [[JavaFX]] anymore, when the future is in [[DukeScript]], right?		But who cares about [[JavaFX]] anymore, when the future is in [[DukeScript]], right?

	<comments/>		<comments/>

JaroslavTulach at 07:27, 15 July 2014

JaroslavTulach — Tue, 15 Jul 2014 07:27:32 GMT

←Older revision		Revision as of 07:27, 15 July 2014
Line 57:		Line 57:
	</source>		</source>

-	The only problem is that this change has been integrated only for [[~~MacOSX~~]] toolkit! I am not sure what the [[Swing]] guys were smoking? Why they didn't integrate the behavior into all AWT toolkit?	+	The only problem is that this change has been integrated only for [[OS X]] toolkit! I am not sure what the [[Swing]] guys were smoking? Why they didn't integrate the behavior into all AWT toolkit?
		+
		+	But who cares about [[JavaFX]] anymore, when the future is in [[DukeScript]], right?

	<comments/>		<comments/>

JaroslavTulach at 07:18, 15 July 2014

JaroslavTulach — Tue, 15 Jul 2014 07:18:58 GMT

←Older revision		Revision as of 07:18, 15 July 2014
Line 56:		Line 56:
	}		}
	</source>		</source>
		+
		+	The only problem is that this change has been integrated only for [[MacOSX]] toolkit! I am not sure what the [[Swing]] guys were smoking? Why they didn't integrate the behavior into all AWT toolkit?

	<comments/>		<comments/>

JaroslavTulach at 07:12, 15 July 2014

JaroslavTulach — Tue, 15 Jul 2014 07:12:32 GMT

←Older revision		Revision as of 07:12, 15 July 2014
Line 41:		Line 41:
	public static void main(String... args) {		public static void main(String... args) {
	System.setProperty("javafx.embed.singleThread", "true");		System.setProperty("javafx.embed.singleThread", "true");
-	SwingUtilities.invokeLater(new Runnable() {	+	SwingUtilities.invokeLater(new Runnable() {
-	@Override	+	@Override
-	public void run() {	+	public void run() {
-	JFrame frame = new JFrame("FX");	+	JFrame frame = new JFrame("FX");
-	final JFXPanel fxPanel = new JFXPanel();	+	final JFXPanel fxPanel = new JFXPanel();
-	frame.add(fxPanel);	+	frame.add(fxPanel);
-	frame.setVisible(true);	+	frame.setVisible(true);

-	// Swing and JavaFX threads are the same	+	// Swing and JavaFX threads are the same
-	Scene scene = createScene();	+	Scene scene = createScene();
-	fxPanel.setScene(scene);	+	fxPanel.setScene(scene);
-	}	+	}
-	});	+	});
	}		}
	</source>		</source>

	<comments/>		<comments/>

JaroslavTulach at 07:11, 15 July 2014

JaroslavTulach — Tue, 15 Jul 2014 07:11:31 GMT

←Older revision		Revision as of 07:11, 15 July 2014
Line 41:		Line 41:
	public static void main(String... args) {		public static void main(String... args) {
	System.setProperty("javafx.embed.singleThread", "true");		System.setProperty("javafx.embed.singleThread", "true");
-	~~java.awt.EventQueue~~.invokeLater(() -> {	+	SwingUtilities.invokeLater(new Runnable() {
-	// ~~and now show your~~ Swing and ~~FX UI~~	+	@Override
-	});	+	public void run() {
		+	JFrame frame = new JFrame("FX");
		+	final JFXPanel fxPanel = new JFXPanel();
		+	frame.add(fxPanel);
		+	frame.setVisible(true);
		+
		+	// Swing and JavaFX threads are the same
		+	Scene scene = createScene();
		+	fxPanel.setScene(scene);
		+	}
		+	});
	}		}
	</source>		</source>

	<comments/>		<comments/>

JaroslavTulach at 07:10, 15 July 2014

JaroslavTulach — Tue, 15 Jul 2014 07:10:03 GMT

←Older revision		Revision as of 07:10, 15 July 2014
Line 36:		Line 36:
	When your code is running (handling a [[Swing]] event) how can you tell in which thread it is running? Of course, there is {{JDK\|java/lang\|Thread}}.getName(), but beyond that, there is no way for your code to see any differences between the old ''AWT-EventQueue-X'' thread and new {{FX\|javafx/application\|Platform}}.runLater thread. All event processing remains synchronized (no code runs in parallel), so how could your code tell it is running in different thread? No chance, that is why I believe this change is completely safe.		When your code is running (handling a [[Swing]] event) how can you tell in which thread it is running? Of course, there is {{JDK\|java/lang\|Thread}}.getName(), but beyond that, there is no way for your code to see any differences between the old ''AWT-EventQueue-X'' thread and new {{FX\|javafx/application\|Platform}}.runLater thread. All event processing remains synchronized (no code runs in parallel), so how could your code tell it is running in different thread? No chance, that is why I believe this change is completely safe.

-	The change has been integrated as http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ae4683a6b860 and ~~will be~~ available in [[JDK]]8. ~~I am looking forward, as that will~~ greatly improve life for guys trying to mix [[Swing]] with [[JavaFX]].	+	The change has been integrated as http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ae4683a6b860 and is available in [[JDK]]8. To greatly improve life for guys trying to mix [[Swing]] with [[JavaFX]] just do following before instantiating your AWT and FX objects:
		+
		+	<source lang="java">
		+	public static void main(String... args) {
		+	System.setProperty("javafx.embed.singleThread", "true");
		+	java.awt.EventQueue.invokeLater(() -> {
		+	// and now show your Swing and FX UI
		+	});
		+	}
		+	</source>

	<comments/>		<comments/>

JaroslavTulach at 11:56, 10 December 2013

JaroslavTulach — Tue, 10 Dec 2013 11:56:26 GMT

←Older revision		Revision as of 11:56, 10 December 2013
Line 1:		Line 1:
-	[[wikipedia:JavaFX\|JavaFX]] is new, modern UI toolkit for rendering [[Java]] UIs. The idea is tempting - instead of bloated [[wikipedia:Abstract_Window_Toolkit\|AWT]] with [[Swing]] on top, one can use a completely independent UI and lightweight library instead. However, as usual when offering [[AlternativeBehaviour]], the problem is [[co-existence]] - there are tons of [[Swing]] applications around and they need to migrate to [[JavaFX]] in an incremental fashion. Unless such migration is smooth, people will rather stick with what they have right now.	+	[[wikipedia:JavaFX\|JavaFX]] is new, modern UI toolkit for rendering [[Java]] UIs. The idea is tempting - instead of bloated [[wikipedia:Abstract_Window_Toolkit\|AWT]] with [[Swing]] on top, one can use a completely independent UI and lightweight library (which can for example be deployed to [[iOS]]) instead. However, as usual when offering [[AlternativeBehaviour]], the problem is [[co-existence]] - there are tons of [[Swing]] applications around and they need to migrate to [[JavaFX]] in an incremental fashion. Unless such migration is smooth, people will rather stick with what they have right now.

	=== Dispatch Threads ===		=== Dispatch Threads ===

JaroslavTulach at 08:55, 19 June 2013

JaroslavTulach — Wed, 19 Jun 2013 08:55:03 GMT

←Older revision		Revision as of 08:55, 19 June 2013
Line 36:		Line 36:
	When your code is running (handling a [[Swing]] event) how can you tell in which thread it is running? Of course, there is {{JDK\|java/lang\|Thread}}.getName(), but beyond that, there is no way for your code to see any differences between the old ''AWT-EventQueue-X'' thread and new {{FX\|javafx/application\|Platform}}.runLater thread. All event processing remains synchronized (no code runs in parallel), so how could your code tell it is running in different thread? No chance, that is why I believe this change is completely safe.		When your code is running (handling a [[Swing]] event) how can you tell in which thread it is running? Of course, there is {{JDK\|java/lang\|Thread}}.getName(), but beyond that, there is no way for your code to see any differences between the old ''AWT-EventQueue-X'' thread and new {{FX\|javafx/application\|Platform}}.runLater thread. All event processing remains synchronized (no code runs in parallel), so how could your code tell it is running in different thread? No chance, that is why I believe this change is completely safe.

-	~~I am not sure in which version of [[JavaFX]] this improved interoperability~~ will be available ~~(it requires changes on the [[JDK]] side as well), but I hope that it lands at least~~ in [[JDK]]8. I am looking forward, as that will greatly improve life for guys trying to mix [[Swing]] with [[JavaFX]].	+	The change has been integrated as http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ae4683a6b860 and will be available in [[JDK]]8. I am looking forward, as that will greatly improve life for guys trying to mix [[Swing]] with [[JavaFX]].

	<comments/>		<comments/>

JaroslavTulach: /* Dispatch Threads */

JaroslavTulach — Wed, 23 May 2012 10:37:49 GMT

Dispatch Threads

←Older revision		Revision as of 10:37, 23 May 2012
Line 3:		Line 3:
	=== Dispatch Threads ===		=== Dispatch Threads ===

-	Up until today (e.g. May 2012) mixing [[Swing]] and [[JavaFX]] was not easy because each of these two systems used its own dispatch thread. Whenever one needed to operate with [[Swing]] one had to enter the dispatch thread by using {{JDK\|java/awt\|EventQueue}}.invokeLater({{JDK\|java/lang\|Runnable}}). As soon as there was a need to manipulate with [[JavaFX]] components one had to use {{FX\|javafx/application\|Platform}}.runLater({{JDK\|java/lang\|Runnable}}). As [[Java]] is not very good at this kind of [[wikipedia:Actor_model\|actor]] based coding, the result was completely unreadable code full of deeply nested {{JDK\|java/lang\|Runnable}}s:	+	Up until today (e.g. May 2012) mixing [[Swing]] and [[JavaFX]] was not easy because each of these two systems used its own dispatch thread. Whenever one needed to operate with [[Swing]] one had to enter the dispatch thread by using {{JDK\|java/awt\|EventQueue}}.invokeLater({{JDK\|java/lang\|Runnable}}). As soon as there was a need to manipulate with [[JavaFX]] components one had to use {{FX\|javafx/application\|Platform}}.runLater({{JDK\|java/lang\|Runnable}}). As [[Java]] is not very good at this kind of [[wikipedia:Actor_model\|actor]] based coding, the result was completely unreadable code full of deeply nested {{JDK\|java/lang\|Runnable}}s. Here is very simple example:

	<source lang="java">		<source lang="java">

JaroslavTulach at 10:27, 23 May 2012

JaroslavTulach — Wed, 23 May 2012 10:27:13 GMT

←Older revision		Revision as of 10:27, 23 May 2012
Line 1:		Line 1:
-	[[wikipedia:JavaFX\|JavaFX]] is new, modern UI toolkit for rendering [[Java]] UIs. The idea is tempting - instead of bloated [[wikipedia:Abstract_Window_Toolkit\|AWT]] ~~and~~ [[Swing]] on top, one can use a completely independent UI and lightweight library instead. However, as usual when offering [[AlternativeBehaviour]], the problem is [[co-existence]] - there a tons of [[Swing]] applications around and they need to migrate to [[JavaFX]] in an incremental fashion. Unless such migration is smooth, people will rather stick with what they have right now.	+	[[wikipedia:JavaFX\|JavaFX]] is new, modern UI toolkit for rendering [[Java]] UIs. The idea is tempting - instead of bloated [[wikipedia:Abstract_Window_Toolkit\|AWT]] with [[Swing]] on top, one can use a completely independent UI and lightweight library instead. However, as usual when offering [[AlternativeBehaviour]], the problem is [[co-existence]] - there are tons of [[Swing]] applications around and they need to migrate to [[JavaFX]] in an incremental fashion. Unless such migration is smooth, people will rather stick with what they have right now.

	=== Dispatch Threads ===		=== Dispatch Threads ===
Line 30:		Line 30:
	I am proud to announce that the mutual [[Swing]] and [[JavaFX]] interoperability has been greatly simplified during May 2012. No need for massive amount of asynchronous {{JDK\|java/lang\|Runnable}}s! Your [[Swing]] code can directly talk to [[JavaFX]] data structures and your [[JavaFX]] code can do the same to [[Swing]] objects. This is a [http://source.apidesign.org/hg/jdk/rev/4ed8674de305 small change], but huge step forward for [[Swing]]+[[JavaFX]] interoperability!		I am proud to announce that the mutual [[Swing]] and [[JavaFX]] interoperability has been greatly simplified during May 2012. No need for massive amount of asynchronous {{JDK\|java/lang\|Runnable}}s! Your [[Swing]] code can directly talk to [[JavaFX]] data structures and your [[JavaFX]] code can do the same to [[Swing]] objects. This is a [http://source.apidesign.org/hg/jdk/rev/4ed8674de305 small change], but huge step forward for [[Swing]]+[[JavaFX]] interoperability!

-	The basic idea is to share the [[Swing]] and [[JavaFX]] dispatch threads. Trivial implementation would keep the ''AWT-EventQueue-X'' and just ~~made~~ sure one will always use {{FX\|javafx/application\|Platform}}.runLater to dispatch the [[Swing]] events. More advanced implementation can even eliminate the need for ''AWT-EventQueue-X'' thread completely (as the [http://source.apidesign.org/hg/jdk/rev/4ed8674de305 patch] shows). By running the event processing in the same thread, it is safe to access [[Swing]] as well as [[JavaFX]] [[API]]s directly which greatly simplifies the coding model.	+	The basic idea is to share the [[Swing]] and [[JavaFX]] dispatch threads. Trivial implementation would keep the ''AWT-EventQueue-X'' and just make sure one will always use {{FX\|javafx/application\|Platform}}.runLater to dispatch the [[Swing]] events. More advanced implementation can even eliminate the need for ''AWT-EventQueue-X'' thread completely (as the [http://source.apidesign.org/hg/jdk/rev/4ed8674de305 patch] shows). By running the event processing in the same thread, it is safe to access [[Swing]] as well as [[JavaFX]] [[API]]s directly which greatly simplifies the coding model.

-	I've send my patch to Artem (Oracle's [[JavaFX]] guru) as a sketch of what could be done and the news from Artem are really great. The basic interoperability seems to work fine. Originally I was slightly afraid whether processing of events in different thread will work seamlessly, but now (when it has been experimentally verified) I think the ~~changes~~ have always been high for this system to work well.	+	I've send my patch to Artem (Oracle's [[JavaFX]] guru) as a sketch of what could be done and the news from Artem are really great. The basic interoperability seems to work fine. Originally I was slightly afraid whether processing of events in different thread will work seamlessly, but now (when it has been experimentally verified) I think the chances have always been high for this system to work well.

-	When your code is running (handling a [[Swing]] event) how can you tell in which thread it is running? Of course, there is {{JDK\|java/lang\|Thread}}.getName(), but beyond that, there is no ~~other~~ way for your code to ~~find out that now, it runs in~~ {{FX\|javafx/application\|Platform}}.runLater thread. All event processing remains synchronized (no code runs in parallel), so how could your code tell it is running in different thread? No chance, that is why I believe this change is completely safe.	+	When your code is running (handling a [[Swing]] event) how can you tell in which thread it is running? Of course, there is {{JDK\|java/lang\|Thread}}.getName(), but beyond that, there is no way for your code to see any differences between the old ''AWT-EventQueue-X'' thread and new {{FX\|javafx/application\|Platform}}.runLater thread. All event processing remains synchronized (no code runs in parallel), so how could your code tell it is running in different thread? No chance, that is why I believe this change is completely safe.

	I am not sure in which version of [[JavaFX]] this improved interoperability will be available (it requires changes on the [[JDK]] side as well), but I hope that it lands at least in [[JDK]]8. I am looking forward, as that will greatly improve life for guys trying to mix [[Swing]] with [[JavaFX]].		I am not sure in which version of [[JavaFX]] this improved interoperability will be available (it requires changes on the [[JDK]] side as well), but I hope that it lands at least in [[JDK]]8. I am looking forward, as that will greatly improve life for guys trying to mix [[Swing]] with [[JavaFX]].

	<comments/>		<comments/>