Reproducing this bug is difficult unless you have the AT-SPI/Java bridge for GNOME up and running. I'll try to give you as much information as possible here.

When querying gtk using AT-SPI, we get a result with a proper interface on it already. For instance, if "d" is the desktop accessible:

>>> d.getChildAtIndex(0)
<CORBA.Object 'IDL:Accessibility/Application:1.0' at 0x8d06608>

When querying a Java, we always initially get an object that appears to be null:

>>> d.getChildAtIndex(1)
<CORBA.Object '(null)' at 0x95158b0>

On inspection of this object, it certainly is just a dummy CORBA object:

>>> j = d.getChildAtIndex(1)
>>> dir(j)
['__class__',
 '__cmp__',
 '__delattr__',
 '__doc__',
 '__getattribute__',
 '__hash__',
 '__init__',
 '__new__',
 '__reduce__',
 '__reduce_ex__',
 '__repr__',
 '__setattr__',
 '__str__',
 '__typecode__',
 '_duplicate',
 '_hash',
 '_is_a',
 '_is_equivalent',
 '_is_nil',
 '_narrow',
 '_non_existent']

But watch what happens when I invoke _narrow explicitly giving it Accessibility.Application interface:

>>> k = j._narrow(Accessibility.Application)
>>> k
<CORBA.Object '(null)' at 0x95158b0>

Still looks dead, right? But guess what:

>>> dir(k)
['__class__',
 '__cmp__',
 '__del__',
 '__delattr__',
 '__doc__',
 '__getattribute__',
 '__getitem__',
 '__hash__',
 '__init__',
 '__iter__',
 '__len__',
 '__module__',
 '__new__',
 '__nonzero__',
 '__reduce__',
 '__reduce_ex__',
 '__repr__',
 '__setattr__',
 '__slots__',
 '__str__',
 '__typecode__',
 '_duplicate',
 '_get_childCount',
 '_get_description',
 '_get_id',
 '_get_name',
 '_get_parent',
 '_get_toolkitName',
 '_get_version',
 '_hash',
 '_icache',
 '_is_a',
 '_is_equivalent',
 '_is_nil',
 '_mix___new__',
 '_mix___str__',
 '_mix_description',
 '_mix_getApplication',
 '_mix_getIndexInParent',
 '_mix_getRoleName',
 '_mix_name',
 '_narrow',
 '_non_existent',
 '_set_description',
 '_set_id',
 '_set_name',
 'childCount',
 'description',
 'getApplication',
 'getAttributes',
 'getChildAtIndex',
 'getIndexInParent',
 'getLocale',
 'getLocalizedRoleName',
 'getRelationSet',
 'getRole',
 'getRoleName',
 'getState',
 'id',
 'isEqual',
 'name',
 'parent',
 'pause',
 'ref',
 'registerObjectEventListener',
 'registerToolkitEventListener',
 'resume',
 'toolkitName',
 'unImplemented2_',
 'unImplemented3_',
 'unImplemented_',
 'unimplemented',
 'unref',
 'version']
>>> k.name
'Notepad'

Now it's a truly functioning Application object.

Why doesn't pyorbit properly narrow to the correct interface like it does for other toolkits? Is this a bug in pyorbit or Java?