JDK-8102633 : Separate javafx.embed.swt from jfxrt.jar
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: application-lifecycle
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-06-28
  • Updated: 2015-06-16
  • Resolved: 2013-10-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Relates :  
JDK-8102614 - Need to move jfxrt.jar from lib/ to lib/ext/
Description
When jfxrt.jar goes into the bootclasspath in the future. There is going to be a problem using the SWT embedding as they depend on swt.jar which can't be added to the bootclasspath. So I think we may need to separate out the javafx.embed.swt package into its own jar.
Comments
It was done. Close the issue.
30-12-2013
I verified that this file has gone missing. I filed RT-34169 to track this.
08-11-2013
I will check into this. It most certainly should not have disappeared from the JDK / JRE.
08-11-2013
This bug is not public visible. So where will it go? Is there a replacement?
08-11-2013
Kevin, do you know about this new jar file disappearing in b115? RT-34140
08-11-2013
Thanks for confirming the fix.
07-11-2013
e(fx)clipse has been update and things work like a charme!
07-11-2013
Tested-with: HelloFXCanvas Verified no regression in other test Verified that all javafx.embed.* classes are in jfxswt.jar and none are in jfxrt.jar Unit Tests: None.
22-10-2013
Yes, the builder class is part of FX 2.2 (else I would have nuked it as part of this JIRA). Anyway, it's trivial to just include it in jfxswt.jar along with the rest. The target build for this split is b113.
19-10-2013
jfxswt.jar sounds good. The builder is bogus but I expect that it is part of FX 2.2 so it can't be deleted.
18-10-2013
I note that there is also one builder class in the javafx.embed.swt package : CustomTransferBuilder. The safest thing to do is to just include that in the jfxswt.jar file, but I wonder if it is needed at all?
18-10-2013
I propose $JRE/lib/jfxswt.jar
18-10-2013
is there already a consensus on the name and location? I'd like to prepare efxclipse to understand the split for the release which might happen before the JDK-build has the split!
11-10-2013
I will go ahead and schedule this for 8 then per Steve's recommendation.
08-10-2013
RCP will always have to use sort of hack to get it working - I have no problem if you put the jar in the JRE and NOT on any default classpath
08-10-2013
I would lean towards 3)b). This would separate swt interop into a jar and ship it as part of the JDK lib directory where stand alone SWT applications and OSGi applications can reference it. This would break people who were putting SWT on the boot class path for JDK8 but those people are early adopters. JDK8 has not yet shipped. If we don't do this now, we will be in a situation where stand alone SWT applications can work (using the boot path), e(fx)clips applications can work (using Tom's hacks) but Eclipse RCP OSGi applications won't work. Is this correct? My feeling is that if we are going to break people, let's do it once when jfxrt.jar is moving anyway. Thoughts?
07-10-2013
Thanks, that makes sense to me, too.
05-10-2013
I would go with 1) for now - e(fx)clipse deals with the nasty details of classloading in the SWT & FX & OSGi case (only drawback is that in the SWT & FX case the ScenicView does not work), I hope equinox is not breaking us in the next release where I have rewritten the complete low level stack. I think 3)a) is not a viable solution even in the future, so the only long term one is 2 and 3)b)
04-10-2013
This question is mostly for Tom, but any OSGi or Eclipse user can chime in. It is quite late to be doing anything about this for FX 8. We really only have three choices that I see: 1) Leave the SWT embed classes in jfxrt.jar and defer this issue to FX 9 2) Remove the javafx.embed.swt classes entirely and let "somebody else" ship (where and how are the questions) as a separate jar file [this will break anyone who currently works around this issue by simply adding swt.jar to the boot classpath; also, as Tom notes above, FXCanvas uses non-public methods from FX...not a good answer] 3) Separate the javafx.embed.swt classes into a separate jar file, either leaving it in jre/lib/ext or putting in jre/lib (in which case it wouldn't be on the default classpath). This will require a CCC for the JDK (assuming they are even still accepting such for 8). [this may or may not break anyone who currently works around this issue by adding jfxrt.jar and swt.jar to the boot classpath since they won't know about the new jar. It also isn't clear that it solved anything?] My inclination is to do #1 since it seems the least risky, and anyone who is using SWT with JDK 8 is already working around the problem. I think #2 would be problematic because it really needs to be in sync with FX. What do you think?
04-10-2013
A problem with FXCanvas is that it uses none public FX-"API" ;-)
24-01-2013
I agree with the decision to put the SWT-dependent classes in their own JAR, preferrably with the OSGi meta data included. But I think the same should be done for the javafx.embed.swing.* classes. As far as I understand the goal is to use JavaFX with a Compact Profile where Swing wouldn't be available. http://openjdk.java.net/jeps/161 E.g. I considered that not all environments will have SWT or Swing on their classpath when I developed Drombler FX, which is why I excluded the javafx.embed.* packages from the OSGi meta data. http://sourceforge.net/p/drombler/drombler-fx/ci/e82071dc633c32da770ee600ac421f9bb89ad1d9/tree/drombler-fx-startup-main/src/main/resources/org/drombler/fx/startup/main/config.properties I think it would make things cleaner if all javafx.embed.* classes would be in their own JARs, preferrably with the OSGi meta data included.
24-01-2013
Just discussed this with Tom Watson from Equinox and the consensus of us was that: a) javafx.embed.swt has to be removed from the javafxrt.jar when put on the bootclasspath b) an extra jar should be provided for people to integrate javafx with swt (it should not be part of the VM-Install) c) Longterm: What about moving the SWT integration to Eclipse.org and ship it as part of SWT in future?
23-08-2012
Yes we'd need it in a extra jar at least so that we can repackage and add the OSGi meta data? Even better would be if the fx-swt.jar would hold the appropriate OSGI-Meta data which would free us from repackaging it? I guess 99% of the people use SWT in an OSGi env like Eclipse so it might be very good if we could use it out-of-the-box in OSGi without repackaging.
22-08-2012
Tom, will this fix the issues for you? SWT support will be in a separate jar that you can reference.
22-08-2012
If we put FX on the boot classpath in a 7u release, then this will need to be pulled into the corresponding 2.x release.
29-06-2012