Bug 26982 - Easy way of using the Java Application launcher and having the JVM find the swt.dll
Summary: Easy way of using the Java Application launcher and having the JVM find the s...
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0.1   Edit
Hardware: PC Windows 2000
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2002-11-22 12:00 EST by Joe Winchester CLA
Modified: 2002-11-27 03:20 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Winchester CLA 2002-11-22 12:00:14 EST
Right now if you write a class that uses SWT you have to visit the launcher VM 
arguments and add the line
-Djava.library.path=C:\devEclipse_01\eclipse\plugins\org.eclipse.swt.win32_2.0.1
\os\win32\x86.  
This is covered in the documentation on SWT, but because the DLL directory 
structure gets renamed between releases and varies across operating systems it 
is hard to keep the docs up to date and also for people to get the string 
exactly correct.
A nice feature would be to have a checkbox tab on the Java Application launcher 
that simply says "Use SWT".  When you check this it'll update the VM arguments 
with the required string.  As an analogy when you start a VM in debug mode you 
can don't have to remember the -Xdebug -Xrunjdwp, etc... arguments, the launcher 
hides all of this from you.  
As an even nicer enhancement would be that the launcher can pre-select the use 
SWT box if the build path of the project actually pre-reqs SWT.  This way you 
could do Run As-> Java Application and get the DLL added automatically without 
having to manually create a new configuration and enable it for SWT before using 
it.




This will simplify the task of running an SWT application from 
within eclipse, as the DLL often moves between release so documentation that 
points to its location quickly becomes out of date.  As an analogy when you 
start a VM in debug mode you often have a debug check box which does of the 
necessary -Xdebug -Xrunjdwp:, etc... arguments without you having to remember 
them every time.
Comment 1 Dirk Baeumer CLA 2002-11-25 05:56:26 EST
Good suggestion, but

- this requires a special SWT launcher and there are no plans to provide such 
  a launcher for 2.1.

- indeed, such a launcher should be provided by a sparate plugin since 
  extending the library path doesn't make sense for normal Java applications. 

Since writing a launcher became quite easy with the new launching API this 
seems to be a good third party opportunity.

Joe, are you interested in providing such a launcher ?
Comment 2 Joe Winchester CLA 2002-11-25 06:23:15 EST
Sure - I'd love to do my bit for coding for the Eclipse community.
However ... rather than have a totally separate launcher I'd like to suggest 
that the current launcher be extended so I can plug into it.
Rather than the user having Run As-> Java Application and Run As->SWT 
Application it would make more sense for the current launcher to be used by the 
developer as there is no real difference in their mind - they both get launched 
through their main(String[]) method which I think is the separation between 
having separate launchers.
For the extension point I think on the arguments tab there could be a two column 
check box list that is based on reading an extension point.  In the list could 
be a check list so the user could check and uncheck items.  The second column 
in the list would allow an editor to be present.  Each item in the list would  
be able to have a class that implements an interface that lets it be given the 
program and VM arguments, and also manipulate them.  In the checkbox 
This way anyone can write a plugin to make use of this extension point.  As well 
as the SWT one I want, anyone could make use of this for program arguments.  It 
is often hard to know what program arguments show be, so people could put these 
in the list with nice editors with combo boxes of the allowable values.  Also, 
lots of other VM arguments like the locale and stuff could be in the list with 
drop down editors to help get the values and arguments correct.
If you want I could try and mock up some ideas for this and how it would look 
visually and how the extension point would work ?
Comment 3 Dirk Baeumer CLA 2002-11-27 03:20:12 EST
There isn't any support to extend an existing launcher and given our current 
schedule I think this will not happen even if we get external support. You can 
only provide a new launcher. But of course this new launcher could provide all 
the extensions points and editing feature you described.

Also a "generic" application launcher is posssible I would still tend to 
implement a specific SWT launcer: Here are my reasons

- easier to implement and to maintain.
- you only have to define the lauch configuration once (the Run->Run As->SWT
  application step). After doing so the lauch config is in the list of the 
  last executed application and you can start the application by simply
  selecting it in the drop down box. You can even define your favorite launch
  configs which will not be removed from the history.

A good starting point might be the JUnit launcher which only contributes a new 
main tab to the launcher. The main tab could have an addition that might look 
like this:

SWT library 
  o use SWT library from workspace
  o use SWT library from file system
    [Text Input filed] [Browse button]

Then the launcher can be used even if the swt.dll is not part of the workspace.

Let me know if this makes sense to you.