harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depends.xml)
Date Fri, 06 Oct 2006 12:15:39 GMT
Hi Oleg,

> On the other hand, why don't we allow Harmony to accept invalid names
> and provide a default replacements for them if there is a set/get/is
> method for the specified property? It seems to me more user-friendly
> then throw IntrospectionException in this situation. It looks like the
> specification doesn't require PropertyDescriptor to throw an exception
> in this case.

Well, the specification states here:

<==
public PropertyDescriptor(String propertyName,
                          Class<?> beanClass,
                          String readMethodName,
                          String writeMethodName)
                   throws IntrospectionException
...
Parameters:
...
    readMethodName - The name of the method used for reading the
property value. May be null if the property is write-only.
    writeMethodName - The name of the method used for writing the
property value. May be null if the property is read-only.
Throws:
    IntrospectionException - if an exception occurs during introspection.
<==

So we have the description of the valid parameter case, null parameter
case and the exception that can be thrown. IMHO the natural conclusion
from that is that the exception will be thrown in case of invalid
parameter. Moreover, if the implementation does not validate method
names it will never throw IntrospectionException. But it is described
by the spec.
BTW, PropertyDescriptor(String, Method, Method) validates both methods
and throws IntrospectionException if something is wrong.

> This will also prevent us from breaking applications
> that uses this RI behavior.

Actually I don't belive they exist in our world. :) May be we can
leave the current functionality for now and get back to this if
encounter one of such apps?

Regards,

2006/10/5, Oleg Khaschansky <oleg.v.khaschansky@gmail.com>:
> Alexey,
>
> Agree. I haven't noticed that RI doesn't accept invalid write method.
> Then its behavior looks illogical. Actually, I asked about comments
> especially because I expected a feedback from beans authors. Thank
> you.
>
> On the other hand, why don't we allow Harmony to accept invalid names
> and provide a default replacements for them if there is a set/get/is
> method for the specified property? It seems to me more user-friendly
> then throw IntrospectionException in this situation. It looks like the
> specification doesn't require PropertyDescriptor to throw an exception
> in this case. This will also prevent us from breaking applications
> that uses this RI behavior.
> What is your opinion?
>
> On 10/5/06, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
> > Oleg,
> >
> > > + we need to fix in beans the fact that the following code:
> > > new PropertyDescriptor(propertyName, c.getClass(), "1", null);
> > > will throw IntrospectionException on Harmony, but will return the
> > > valid property descriptor with the getter method on RI.
> > > Any thoughts on this? Or should I proceed with a patch for the both issues?
> >
> > I've already written my thoughts about this issue in [1]. In short: I
> > don't think we should follow the RI behavior since it is inconsistent.
> > Why it accepts invalid read method and throws exception on invalid
> > write method? No logic.
> >
> > [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/%3c2c9597b90609190451g74fec356k2270f515dc5e7ef6@mail.gmail.com%3e
> >
> > Thanks,
> >
> > 2006/10/4, Oleg Khaschansky <oleg.v.khaschansky@gmail.com>:
> > > I found the reason of this failure. It is an IntrospectionException
> > > while executing a following method from the TransferHandler class:
> > >
> > >    private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
> > >        PropertyDescriptor result = null;
> > >        try {
> > >            result = new PropertyDescriptor(propertyName, c.getClass());
> > >        } catch (IntrospectionException e) {
> > >
> > >        }
> > >        return result;
> > >    }
> > > It tries to get the PropertyDescriptor for the class JButton and
> > > property name "insets", but fails because there's no setInsets method.
> > > So, flavors array stays uninitialized and getTransferDataFlavors
> > > method returns null which is a cause of a NPE.
> > >
> > > The quick fix for this issue could be changing this method to the following:
> > >
> > >    private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
> > >        PropertyDescriptor result = null;
> > >        try {
> > >            return result = new PropertyDescriptor(propertyName, c.getClass());
> > >        } catch (IntrospectionException e) {
> > >        }
> > >        try {
> > >            return result = new PropertyDescriptor(propertyName,
> > > c.getClass(), "1", null);
> > >        } catch (IntrospectionException e) {
> > >        }
> > >        return result;
> > >    }
> > >
> > > + we need to fix in beans the fact that the following code:
> > >
> > > new PropertyDescriptor(propertyName, c.getClass(), "1", null);
> > >
> > > will throw IntrospectionException on Harmony, but will return the
> > > valid property descriptor with the getter method on RI.
> > >
> > > Any thoughts on this? Or should I proceed with a patch for the both issues?
> > >
> > > Thanks,
> > >  Oleg
> > >
> > > On 10/4/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> > > > 2006/10/4, Mark Hindess <mark.hindess@googlemail.com>:
> > > > >
> > > > > On 4 October 2006 at 15:41, Tim Ellison <t.p.ellison@gmail.com>
wrote:
> > > > > > Excuse the change in subject line...
> > > > >
> > > > > No problem.  I was just cursing myself for having forgotten to change
> > > > > it.
> > > > >
> > > > > > Mark Hindess wrote:
> > > > > > > With this change, the awt dependencies should now be automated
for
> > > > > > > windows and at least fairly trivial (installing a few packages
on
> > > > > > > Linux[0]).  I think it is time we removed the with.awt.swing
flag.
> > > > > > > Anyone object?
> > > > > >
> > > > > > To the contrary, ditch it.
> > > > > >
> > > > > > > Please test the current setup with -Dwith.awt.swing=true
and report any
> > > > > > > problems.
> > > > > >
> > > > > > Problem 1:  My machine is too slow running all these tests.
> > > > >
> > > > > Mine too.  And I have wondered if the hourly builds will finish within
> > > > > the hour now.  We really should see if we can avoid the need to fork
> > > > > for every test.
> > > >
> > > > I've run the tests on my XP machine, 1 failed
> > > >
> > > > javax.swing.TransferHandlerTest#testCreateTransferable
> > > >
> > > > java.lang.NullPointerException at
> > > > javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140)
> > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > > > at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
> > > > at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at
> > > > java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88)
> > > > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at
> > > > java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at
> > > > java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
> > > > java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
> > > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
> > > >
> >
> > --
> > Alexei Zakharov,
> > Intel Middleware Product Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Alexei Zakharov,
Intel Middleware Product Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message