Description Richard Kulp 2003-12-11 15:03:27 EST

We really need to discuss this and finally decide what we are going to do.
The current way is not satisfactory because it can create invalid code.


When creating IJavaObjectInstances and setting the initialization strings
in parsing, currently it uses the type of feature being set as the type of
the IJavaObjectInstance in normal cases, and then proxy adapter morphs
it into the runtime value returned from evaluating the init string.

This is wrong because then the real type shows up on the Propertysheet,
but if somebody sets subproperties the casting could be wrong.

For example:

public class GetLay {

	/**
	 * Constructor for GetLay.
	 */
	public GetLay() {
		super();
	}
	
public static LayoutManager getLay() {
	return new BorderLayout();
}	

}

and:
in a separte class:

	private javax.swing.JPanel getJPanel() {
		if(jPanel == null) {
			jPanel = new javax.swing.JPanel();
			java.awt.BorderLayout layBorderLayout4 = GetLay.getLay();
			layBorderLayout4.setHgap(3);
			jPanel.setLayout(layBorderLayout4);
			jPanel.setSize(357, 76);
		}
		return jPanel;
	}

This gets produced because first we had:

   jPanel.setLayout(GetLay.getLay());

Then user set hgap on property sheet. So then the above code gets produced. 
This is actually a syntax error because getLay() does not return a BorderLayout
as its
type, it returns a LayoutManager.

Now we can go and cast the return from getLay to be a BorderLayout because if
someone
change getLay in the future to return a FlowLayout, then the cast will fail.

So we should never assume anymore knowledge then what is available to the compiler,
i.e. we know only that it is a LayoutManager. So the property sheet won't be
able to 
set BorderLayout properties on it, even though at this point in time it is a
border layout.

If instead someone did:

         jPanel.setLayout((BorderLayout) GetLay.getLay());

Then we should treat it as a BorderLayout (since the user's code explicitly said
I'm sure
it will stay a border layout.