It is useful to define a Java beans aspect (beans aspect)
for Demeter/Java programs
which allows to define events which are visible outside the program.
This will allow other beans to interact with Demeter/Java produced beans.
We would like to define a beans aspect for Demeter/Java itself.
The discussion below applies to this.

I would like to make a COM3360 project out of this. 
Here are my initial thoughts.

Bean info:
http://splash.java-soft.com/beans/spec.html

http://www.digitalfocus.com/faq

Java beans are loosely coupled components which use events for coordination.
Each bean is supposed to have a set of methods, such as access methods.
What those methods do is defined through naming conventions, like getA()
retrieves the A property.
The reflection (introspection) methods in java.lang.Class are used to query a bean.
For example, you can get an array of Method objects and you use the
invoke method of Method to call a specific method.

Working with beans means to work with event models. You can create your
own event models or use existing ones. All collaborating beans
must adhere to a specific event model.

The AWT 1.1 event model is an example of a bean event model.

A rough sketch of a beans aspect is:

beans aspect description
  event model
    event classes
      // use classes derived from java.util.EventObject
    event listener interfaces
  bean info 
    // gives info about each class which is a bean 
    // (one BeanInfo object per bean class)
  event generation
    // specifies how and where in the program the events are produced
    // e.g. at visitor class X before method y() generate event 
    //  (@ details of event object generation @)
  // etc.
end 

Implementation: use Josh's generic aspect weaver.
The weaver will enforce the Java beans conventions regarding naming
of methods etc.

-- Karl

>From gef-users-request@ics.uci.edu Tue Sep 16 23:05:42 1997
>To: Priya Balasubramanian <pbalasub@mailbox.syr.edu>
>cc: gef-users@ics.uci.edu
>Subject: Re: GEF help 
>Date: Tue, 16 Sep 1997 13:09:31 -0700
>From: Jason Elliot Robbins <jrobbins@liege.ics.uci.edu>
>X-Loop: gef-users@ics.uci.edu
>
>>I am a student from Syracuse University. Out here, we are currently
>>working on a project to convert GEF into JAVA BEANS. I need some help in
>>the same. I will give further details when I get a response for this mail.
>
>Hi Priya,
>
>  Thanks for your interest in GEF. I am very interested in a beans
>version of GEF. I have several thoughts on how to do it, any you must
>have some ideas also. Here are my initial ideas.
>
>After we discuss this on the gef-users list for a few messages, let us
>narrow the discussion to just those users interested in working toward
>a beans implementation.
>
>First of all, there multiple things that could make GEF work with
>beans. One idea is to make all the parts of GEF be beans which could
>then be reused outside of GEF. Another is to make GEF one big bean. A
>third is to make GEF into a BeanBox that can contain other beans.
>
>The design of GEF relies on using subclasses to specialize the
>behavior of the frameowrk to the needs of a specific application.
>Beans, on the otehr hand, simplifies the OO paradign down to a
>resuable component model: inheritance is still available, but users
>shuold be able to use beans without doing any subclassing. GEF's
>components could be used without subclassing, but I think there may be
>a lot of design work needed to define all the needed parameters. For
>example, if your application is a corporate OrgChart, you will need to
>define nodes for peolpe and arcs for the worksFor relationship. Doing
>this in Java code by subclassing NetNode and NetArc is fairly
>straightforward and very flexible, but it is somewhat of a hassle. The
>ideal beans solution would require that new clases of nodes need not
>be defined, instead, users should be able to simply enter parameter
>values that identify the kind of node, how it looks, what
>relationships it can participate in, how it respoinds to user input,
>etc. Customizing the editor would also have to be done in a decarative
>way, maybe with a state-machine of modes and tables of actions or mode
>transitions caused by various events. This is a great project, but it
>will take some work to redesign GEF or define a parameter-only set of
>leaf classes in the GEF framework.
>
>Another very interesting thing to do would be to extend GEF so that
>beans can be used as Figs in a GEF diagram. If tis were done then
>programmers using GEF could define a node's perspective to include a
>radio button or a slider or calendar widget. Doing this would require
>aligning the GEF way of handling diagrams with the AWT way of doing
>window layouts. GEF's class Layer would need to be merged with AWT's
>class Container, and GEFs DiagramElement would need to be merged with
>AWTs Component class. Support for multiple views might not be easy to
>maintain since AWT does not provide for multiple views, but I think we
>could come up with something. I am also very interested in doing this.
>
>What are your ideas and requirements for integrating GEF with JavaBeans?
>What do you want to do with GEF after it is integrated with beans?
>
>
>jason!
>
>BTW, I was at Syracuse University last year for the Knowledge-Based
>Software Engineering Confernece (now called Automated Software
>Engineering). I enjoyed visiting there. The architecture of campus
>buildings was a nice change of pace from UC Irvine's "lunar modules."
>
>