[news.eclipse.platform.swt] Re: Running SWT Outside Eclipse Instructions

[David Wegener <wegener@xxxxxxxxxxxxxx>]

Robert B wrote:
> > If you insist on having your application corrupt the JRE by placing SWT in
> > it, please post the name of your product so the rest of us can avoid it. 
> > I
> > would be extremely upset if I found that a third party software package
> > added something to the JRE.  SWT does not belong in the JRE.  If I'm 
> > running
> > an SWT application that depends on a different version of SWT than your
> > product, instalation of your product will break my other application.
>
> You should expect people add SWT, JDBCs, and many other commonly
> used package into JRE. The lib/ext is exactly designed for it!
The lib/ext directory allows you to place options jar files there if you 
chose.  However, this decision should be left up to the local 
administrator.  It shouldn't be forced by a package distributor since it 
could potentially break other applications.

You also need to consider multi user environments where a single jre is 
shared by all users of the system.  Adding something to /lib/ext forces 
everyone on the system to use it.  Administrators in these environments 
have to be very careful about what they allow in the lib/ext directory. 
 The directory will most likely be locked out from user modification. 
If you application installation depends on putting swt.jar in lib/ext, 
it will fail on these systems.

> Your programs
> should run smoothly all the time on all versions. If you don't do that, your 
> managers
> and users won't  be happy. Making them work is always developers' 
> responsibility.
You are naive if you think this is possible.  At some point, you have to 
set minimum requirements for your application.  If you write to version 
1.0 of a particular API, you need to have version 1.0 available.  If a 
different application installs version 0.9 in lib/ext, your application 
will not work.  If version 2.0 changes the behavior of an API call that 
you depend on and it gets installed to lib/ext your application again 
breaks.  You can't code around these situations.

You also don't have control over the applications that other people 
write.  Installation of your application shouldn't break someone else's. 
 If you drop version 3.4 of SWT into lib/ext when another application 
only works on 3.2 or 3.3 you break their application.

> If SWT can cause problems as you claim, no one will use SWT.
This isn't a problem specific to SWT it is the reality of any third 
party library.  APIs change and there are going to be incompatibilities 
between versions.  You need to provide your users with an installation 
plan that protects their systems from breaking.

The SWT developers have made the process much easier with recent 
versions.  The newer jar files just need to be added to the classpath of 
the application.  The classes in the jar file take care of making sure 
that the dependent dll files are extracted as necessary when an 
application is first run.

This provides the user the greatest flexibility in installing 
applications from different vendors.

> Regards.