Re: [EclipseShell-developer] stdout discussion continued

[Lukasz S. <har...@op...>]

----- Original Message -----
From: "Lukasz Skowronski" <har...@op...>
To: <ecl...@li...>
Sent: Wednesday, March 15, 2006 2:10 AM
Subject: [EclipseShell-developer] stdout discussion continued


>
> ----- Original Message -----
> From: "Werner Schuster (murphee)" <wer...@gm...>
> To: <ecl...@li...>
> Sent: Saturday, March 11, 2006 5:26 PM
>
>
> > Other problem: code from an ExecutionEnvironment that gets executed on a
> different Thread; best example would be code that's called
> > from the UI thread; that's necessary for all GUI modifications in SWT
(and
> Swing), ie. as soon as you change anything in an SWT component,
> > you need to do it on the GUI EventDispatchingThread (using
> Display.syncExec(Runnable)).
> >
>
> This seems to be unsolvable in general - it will be very difficult (maybe
> even impossible) to mess with e.g. EventQueue.invokeLater(Runnable) -
> because it's in java.* hierarchy and cannot be loaded by class loader
other
> than bootstrap class loader. Hence we can't modify it's bytecode.
> We could try to apply some aspects on code which calls the EventQueue
> methods. If we have source code with calls to these methods then weaving
> shall be quite straightforward - I'm not sure what would be in case of
> weaving aspects into bytecode (when we don't have the sources) - would
this
> capture properly all invokations or not.
>
> On the other side - if the class being called wouldn't be in java
hierarchy
> (let it be javax.swing.SwingUtilities instead) then we can try to add an
> aspect to it which would be able to match Runnable classloader to the
proper
> console. Of course each Runnable instance would be created by custom
> classloader - we have to ensure that each ExecutionEnvironment will have
its
> own classloader to load Runnable class. Then we could take this
classloader
> in weaved invokeLater method, find the ExecutionEnvironment and then the
> actual console.
>
> When I'll have a little time I'll try to play with aspects..
>

After playing a little with AspectWerkz and AspectJ I believe that what I
wrote above is all true.
There is no easy way to modify classes from java.* hierarchy - there are
legal issues (because of the Sun license) and it requires mungling with
bootstrap classloader. Anyway modyfing java.* classes in the Eclipse
environment is not the best idea I think.

Well Murphee, what about integrating my idea of a fake PrintStream into the
EclipseShell?
I can prepare and send you the appriopriate code.

Regards,
Lukasz