Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Bytecode weaving and JRE classes

Wes,

Thanks for your reply and suggestions.

Let me summarize, what I think you're suggesting.

My original plan:
1) Provide a remote AWT layer that tees the rendering to a remote JVM
as well as the original AWT.
2) Install a shim AWT by setting the "awt.toolkit" System property.
3) Launch the real application

Your suggested plan:
1) Provide a remote AWT layer that tees the rendering to a remote JVM
as well as the original AWT.
2) Use aspects to modify applications so that they call my shim,
instead of the original AWT
3) Launch the real application

Let's leave aside the technical merits of either approach.
Wouldn't your suggested plan require bytecode weaving of the application?
If so, then applications that permitted bytecode weaving would
be remotable, and those that forbade it wouldn't.  That would force users
to know if an application permitted bytecode weaving before they
ran it remotely.  That seems harder to manage than saying these
"JREs allow bytecode weaving and so can run remotely".

I've pretty much decided that I'm going to punt the responsibility just
like AspectJ does.  Namely, notices like one or more of the following
will appear in the documentation:

- SwingAway uses bytecode weaving on the Java runtime classes.
- SwingAway uses bytecode weaving on applications run within it.

If that restricts the legal usefulness of SwingAway to running only certain AWT
applications under Classpath with Kaffe, that is quite unfortunate.

Thanks,
Curt






Back to the top