It would be great to have cover some swt.jar for native operating system such as Linux 32 and 64 and window 32 and 64. To load the right swt.jar based on the user machine OS and JVM bits
Because of the way classloaders and classpath work, there are several scenarios to consider:
- in a JNLP-based applet or Web Start application, resource tags allow to specify OS-specific resources to load.
- in an OSGi container, SWT library to load can be specified.
- in a NetBeans RCP application, there is a way to create modules and load the appropriate one depending on the OS.
- in a plain Java application, a custom launcher has to be created.
For the latter case, the purpose of the launcher is to detect the platform, forge the classpath and invoke the application setting the classpath correctly.
There are mechanisms in recent SWT versions that allow to detect whether an SWT version can work on the current platform, which such launcher could use.
In any case, there is no real way of automating that. What is your take on this in light of these explanations?
-Christopher
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have addressed this issue in the context of an application we're building. Basically along the following lines:
Download all the SWT native libraries for the environments (Windows, Linux, 32-bit, 64-bit), etc from the eclipse.org/swt site,
Include all of these JARs as resources within the runnable JAR for the app.
At runtime, determine the environment, open the runnable JAR, find the correct SWT library JAR for this environment (or Abort), copy the correct SWT Jar to a temp directory on the current machine.
Diddle with the current Classpath to add /tempdir/swt.xxx.jar to the Classpath (a bit kludgy since it uses reflection to access a protected method in the classloader)
Begin normal execution.
Step (3) is optimized to see if the SWT library already exists in the temp directory and skips the copy step. The first time the app runs it adds 10-15 seconds of delay for the copy. If the SWT jar is already present, then there is minimal delay.
It isn't pretty, but has been shown to work successfully on Windows, Linux (Fedora), and Mac OSX for 32-bit and 64-bit machines (note: have not tested all possible combinations).
Not exactly what you need since you would need to handle this within the initialization of your library, but would be glad to share the setup code if it would be helpful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If it is WebStart, then you can include all the SWT JAR files with the "os" and "arch" attributes set appropriately. As for 32 bit or 64 bit SWT, I would rather use 32 bit all the time to maximize compatibility of plugins in the embedded instance.
If the application is standalone, then you can just make a launcher. In fact, if your application is shipped with an installer, then that installer can install the right JAR depending on the detected platform.
Hope this helps,
-Christopher
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-Sammy Guergachi
On 4/19/2014 4:53:55 AM, Christopher Deckers chrriis@users.sf.netwrote:
Hi Sammy,
What is your use case?
If it is WebStart, then you can include all the SWT JAR files with the "os" and "arch" attributes set appropriately. As for 32 bit or 64 bit SWT, I would rather use 32 bit all the time to maximize compatibility of plugins in the embedded instance.
If the application is standalone, then you can just make a launcher. In fact, if your application is shipped with an installer, then that installer can install the right JAR depending on the detected platform.
Status: open Group: Next_Release_(example) Created: Wed Sep 26, 2012 05:34 PM UTC by Alan Mehio Last Updated: Fri Apr 18, 2014 11:27 PM UTC Owner: nobody
It would be great to have cover some swt.jar for native operating system such as Linux 32 and 64 and window 32 and 64. To load the right swt.jar based on the user machine OS and JVM bits
Thanks
Alan M
Sent from sourceforge.net because you indicated interest in
To unsubscribe from further messages, please visit
Hi Alan,
Because of the way classloaders and classpath work, there are several scenarios to consider:
- in a JNLP-based applet or Web Start application, resource tags allow to specify OS-specific resources to load.
- in an OSGi container, SWT library to load can be specified.
- in a NetBeans RCP application, there is a way to create modules and load the appropriate one depending on the OS.
- in a plain Java application, a custom launcher has to be created.
For the latter case, the purpose of the launcher is to detect the platform, forge the classpath and invoke the application setting the classpath correctly.
There are mechanisms in recent SWT versions that allow to detect whether an SWT version can work on the current platform, which such launcher could use.
In any case, there is no real way of automating that. What is your take on this in light of these explanations?
-Christopher
I have addressed this issue in the context of an application we're building. Basically along the following lines:
Step (3) is optimized to see if the SWT library already exists in the temp directory and skips the copy step. The first time the app runs it adds 10-15 seconds of delay for the copy. If the SWT jar is already present, then there is minimal delay.
It isn't pretty, but has been shown to work successfully on Windows, Linux (Fedora), and Mac OSX for 32-bit and 64-bit machines (note: have not tested all possible combinations).
Not exactly what you need since you would need to handle this within the initialization of your library, but would be glad to share the setup code if it would be helpful.
This feature would be amazing, its the only issue I have that prevents me from using this amazing project.
Hi Sammy,
What is your use case?
If it is WebStart, then you can include all the SWT JAR files with the "os" and "arch" attributes set appropriately. As for 32 bit or 64 bit SWT, I would rather use 32 bit all the time to maximize compatibility of plugins in the embedded instance.
If the application is standalone, then you can just make a launcher. In fact, if your application is shipped with an installer, then that installer can install the right JAR depending on the detected platform.
Hope this helps,
-Christopher
I guess that makes sense. Thanks!
-Sammy Guergachi
On 4/19/2014 4:53:55 AM, Christopher Deckers chrriis@users.sf.netwrote:
Hi Sammy,
What is your use case?
If it is WebStart, then you can include all the SWT JAR files with the "os" and "arch" attributes set appropriately. As for 32 bit or 64 bit SWT, I would rather use 32 bit all the time to maximize compatibility of plugins in the embedded instance.
If the application is standalone, then you can just make a launcher. In fact, if your application is shipped with an installer, then that installer can install the right JAR depending on the detected platform.
Hope this helps,
-Christopher
[feature-requests:#12] Checks the OS and JVM and load the right swt.jar
Status: open
Group: Next_Release_(example)
Created: Wed Sep 26, 2012 05:34 PM UTC by Alan Mehio
Last Updated: Fri Apr 18, 2014 11:27 PM UTC
Owner: nobody
It would be great to have cover some swt.jar for native operating system such as Linux 32 and 64 and window 32 and 64. To load the right swt.jar based on the user machine OS and JVM bits
Thanks
Alan M
Sent from sourceforge.net because you indicated interest in
To unsubscribe from further messages, please visit
Related
Feature Requests: #12