[sip-comm-dev] Class cast exception jdic


#1

Lubo,

I've seen that you tried to fix a problem (issue #502). When perfoming
a SIP account modification I get the following trace (it's a snippet):

      [java] ERROR: EventDispatcher: Error during dispatch. (java.lang.ClassCastException: net.java.sip.communicator.impl.systray.jdic.StatusSelector cannot be cast to java.awt.MenuComponent)
      [java] java.lang.ClassCastException: net.java.sip.communicator.impl.systray.jdic.StatusSelector cannot be cast to java.awt.MenuComponent
      [java] at net.java.sip.communicator.impl.systray.jdic.StatusSubMenu.removeAccount(StatusSubMenu.java:144)

The Revision is 4841 for the relevant classes.

System is Java 6, Linux with KDE 3.5

Regards,
Werner

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Werner,

Thank you once again! I'm sorry about the regression. I think 4844 fixes the ClassCastException (though it doesn't make the whole switching between Swing JPopupMenu/JMenu/JMenuItem and AWT PopupMenu/Menu/MenuItem any less error prone).

Best regards,
Lubo

···

On 12/12/2008 8:23 PM, Werner Dittmann wrote:

Lubo,

I've seen that you tried to fix a problem (issue #502). When perfoming
a SIP account modification I get the following trace (it's a snippet):

[java] ERROR: EventDispatcher: Error during dispatch.
(java.lang.ClassCastException:
net.java.sip.communicator.impl.systray.jdic.StatusSelector cannot be
cast to java.awt.MenuComponent)
[java] java.lang.ClassCastException:
net.java.sip.communicator.impl.systray.jdic.StatusSelector cannot be
cast to java.awt.MenuComponent
[java] at
net.java.sip.communicator.impl.systray.jdic.StatusSubMenu.removeAccount(StatusSubMenu.java:144)

The Revision is 4841 for the relevant classes.

System is Java 6, Linux with KDE 3.5

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Lubo,

looks good. Thanks for the fast responses and fixes.

BTW, please excuse my ignorance (I'm not a GUI expert at all) - what
is the reason to switch between AWT and Swing?

Regards,
Werner

Lubomir Marinov schrieb:

···

Werner,

Thank you once again! I'm sorry about the regression. I think 4844 fixes the ClassCastException (though it doesn't make the whole switching between Swing JPopupMenu/JMenu/JMenuItem and AWT PopupMenu/Menu/MenuItem any less error prone).

Best regards,
Lubo

On 12/12/2008 8:23 PM, Werner Dittmann wrote:

Lubo,

I've seen that you tried to fix a problem (issue #502). When perfoming
a SIP account modification I get the following trace (it's a snippet):

[java] ERROR: EventDispatcher: Error during dispatch.
(java.lang.ClassCastException:
net.java.sip.communicator.impl.systray.jdic.StatusSelector cannot be
cast to java.awt.MenuComponent)
[java] java.lang.ClassCastException:
net.java.sip.communicator.impl.systray.jdic.StatusSelector cannot be
cast to java.awt.MenuComponent
[java] at
net.java.sip.communicator.impl.systray.jdic.StatusSubMenu.removeAccount(StatusSubMenu.java:144)

The Revision is 4841 for the relevant classes.

System is Java 6, Linux with KDE 3.5

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Werner,

JDIC causes multiple problems in SC. For example. prevents SC from running on Mac OS X 64-bit Java 6, doesn't correctly display characters in the non-system character set on Windows Vista, causes a deadlock on particular OpenJDK versions on Linux.

Because Java 6 introduced a SystemTray API similar to JDIC, it seemed that we could resolve the above issues by switching to the Java 6 API. Moreover, due to this new API, future development of the JDIC SystemTray API has been discontinued.

However, SC should run on Java 1.5 i.e. it should continue using JDIC when running on Java 1.5 and employ the Java 6 API when it's available.

The JDIC API is Swing-based i.e. it works with JPopupMenu, JMenu and JMenuItem while the Java 6 API works with AWT i.e. PopupMenu, Menu and MenuItem. Unfortunately, the JPopupMenu/JMenu/JMenuItem and PopupMenu/Menu/MenuItem hierarchies only converge on Object and the .impl.systray classes heavily relied on the mentioned Swing components...

I hope that the above description makes sense in most of its parts and that I've been able to, at least partially, convey the reasons for switching between Swing and AWT at runtime in the systray-related SC code.

Best regards,
Lubo

···

On 12/12/2008 9:38 PM, Werner Dittmann wrote:

Lubo,

looks good. Thanks for the fast responses and fixes.

BTW, please excuse my ignorance (I'm not a GUI expert at all) - what
is the reason to switch between AWT and Swing?

Regards,
Werner

Lubomir Marinov schrieb:

Werner,

Thank you once again! I'm sorry about the regression. I think 4844
fixes the ClassCastException (though it doesn't make the whole
switching between Swing JPopupMenu/JMenu/JMenuItem and AWT
PopupMenu/Menu/MenuItem any less error prone).

Best regards,
Lubo

On 12/12/2008 8:23 PM, Werner Dittmann wrote:

Lubo,

I've seen that you tried to fix a problem (issue #502). When perfoming
a SIP account modification I get the following trace (it's a snippet):

[java] ERROR: EventDispatcher: Error during dispatch.
(java.lang.ClassCastException:
net.java.sip.communicator.impl.systray.jdic.StatusSelector cannot be
cast to java.awt.MenuComponent)
[java] java.lang.ClassCastException:
net.java.sip.communicator.impl.systray.jdic.StatusSelector cannot be
cast to java.awt.MenuComponent
[java] at
net.java.sip.communicator.impl.systray.jdic.StatusSubMenu.removeAccount(StatusSubMenu.java:144)

The Revision is 4841 for the relevant classes.

System is Java 6, Linux with KDE 3.5

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi,

···

On Fri, Dec 12, 2008 at 10:18:14PM +0200, Lubomir Marinov wrote:

JDIC causes multiple problems in SC. For example. prevents SC from
running on Mac OS X 64-bit Java 6, doesn't correctly display
characters in the non-system character set on Windows Vista, causes
a deadlock on particular OpenJDK versions on Linux.

Because Java 6 introduced a SystemTray API similar to JDIC, it
seemed that we could resolve the above issues by switching to the
Java 6 API. Moreover, due to this new API, future development of the
JDIC SystemTray API has been discontinued.

However, SC should run on Java 1.5 i.e. it should continue using
JDIC when running on Java 1.5 and employ the Java 6 API when it's
available.

Btw, why is this Java 1.5 compatibility needed? Are there some
particular platforms where 1.6 is not available? I mean, 1.5 is an
end-of-life product which will soon be unsupported, so why bother?

Cheers,

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hey Seb,

Sébastien Mazy wrote:

Btw, why is this Java 1.5 compatibility needed? Are there some
particular platforms where 1.6 is not available?

It's not only a matter of what's supported but also what is generally
deployed. I believe Java 5 is still widely used out there. Macs for
example ship with it by default and (I believe) Java 6 for Mac OS X is
still in beta. Making sure that we are still compatible with Java 5
gives these people the possibility to use SC and this is what matters most.

I mean, 1.5 is an end-of-life product which will soon be unsupported,

I had your private message where you said that Sun would stop supporting
it after October 2009. If it turns out to be true then I guess we could
probably start thinking about removing the J5 compatibility constraint
as soon as next October.

Note that the fact that Sun would stop releasing J5 updates does not
mean that people would stop using it and automatically switch to J6.
Quite often users are not even aware that they have java running on
there computer, so we shouldn't count on a lot of reactivity.

so why bother?

Well, in addition to the above I don't really see any compelling reason
not to. The difference between J5 and J6 is not as big as it was between
4 and 5 so it's easy to use J6's advantages without breaking backward
compatibility. The jdic problems were, I believe, the first that were
caused by it and that was mostly because of the weird systray support in
J6 rather than anything in J5.

Does this answer your question?

Emil

···

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Emil,

It's not only a matter of what's supported but also what is generally
deployed. I believe Java 5 is still widely used out there. Macs for
example ship with it by default and (I believe) Java 6 for Mac OS X is
still in beta. Making sure that we are still compatible with Java 5
gives these people the possibility to use SC and this is what matters most.

We could also tell them to update, have the installer trigger an
optional update or bundle Java 6 with SC package (ugly). If we really
wanted to, we could always find solutions.

I had your private message where you said that Sun would stop supporting
it after October 2009. If it turns out to be true then I guess we could
probably start thinking about removing the J5 compatibility constraint
as soon as next October.

Anyway, this possible end of support would be for post 1.0, of course.

Note that the fact that Sun would stop releasing J5 updates does not
mean that people would stop using it and automatically switch to J6.
Quite often users are not even aware that they have java running on
there computer, so we shouldn't count on a lot of reactivity.

IMHO we shouldn't encourage people to usea broken (yes, unmaintained is
broken) Java. It's a vicious circle: I don't update my Java because my
software won't demand it, the sofware don't require a new version of
Java because a part of the user base still uses the old version.

Well, in addition to the above I don't really see any compelling reason
not to. The difference between J5 and J6 is not as big as it was between
4 and 5 so it's easy to use J6's advantages without breaking backward
compatibility. The jdic problems were, I believe, the first that were
caused by it and that was mostly because of the weird systray support in
J6 rather than anything in J5.

If the code in SC doesn't diverge depending of the version of the JRE,
this "free" backward compatibility is no problem. Otherwise, it'll
double the platforms to test and make the work for the maintainer of
that code harder.

That said, I don't even know the amount of changes needed to switch
between JDIC and the Java 6 API, and I never wrote a single line of code
for that part of SC, so I can't tell if it's really a problem in this
very case. I just used the occasion to discuss this topic.

Does this answer your question?

Yes, thanks for this comprehensive answer.

Cheers,

···

On Sat, Dec 13, 2008 at 12:41:05AM +0200, Emil Ivov wrote:

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net