[sip-comm-dev] ImageIO in Sip Communicator


#1

Hello all
As I'm almost done with implementing support for favicons in
Sip-Communicator RSS plugin, I found myself facing a quite unexpected
problem. Calls to various ImageIO classes and methods yields a
NoClassDefFoundError (namely ImageIO and ImageIcon).
Does anyone have any idea why this happends or how can it be avoided?
I doubt that it has to do with the library I'm using for ICO reading,
as the problems appears even without it being included or used.
Is there anything that I'm missing?

By the way, having to return a byte[] in the getImage() method of the
ContactXXXImpl seems at least cumbersome to me. Shouldn't the protocol
writer take care of everything *including* the eventual contact image
(not passing over just a binary dump of the image but a more useful
representation of the image - like an Image, or IconImage)? Because
for now it seems to me that this aspect is further delegated to
ChatContact in the net.java.sip.communicator.impl.gui.main.chat . What
if it doesn't have a proper decoder?

I hope it make at least a little sense :slight_smile:

Thanks for your time,
Mihai

···

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


#2

Hi Mihai,

Mihai Balan wrote:

Hello all
As I'm almost done with implementing support for favicons in
Sip-Communicator RSS plugin, I found myself facing a quite unexpected
problem. Calls to various ImageIO classes and methods yields a
NoClassDefFoundError (namely ImageIO and ImageIcon).
Does anyone have any idea why this happends or how can it be avoided?
I doubt that it has to do with the library I'm using for ICO reading,
as the problems appears even without it being included or used.
Is there anything that I'm missing?

I think that you already resolved that as you already send your patch on the mailing list, but just for the record the problem is probably that you haven't added the import for javax.imageio in your manifest.mf file.

By the way, having to return a byte[] in the getImage() method of the
ContactXXXImpl seems at least cumbersome to me. Shouldn't the protocol
writer take care of everything *including* the eventual contact image
(not passing over just a binary dump of the image but a more useful
representation of the image - like an Image, or IconImage)? Because
for now it seems to me that this aspect is further delegated to
ChatContact in the net.java.sip.communicator.impl.gui.main.chat . What
if it doesn't have a proper decoder?

I hope it make at least a little sense :slight_smile:

Emil will correct me if I'm wrong, but I think that the idea of having a byte[] return type is to have no dependencies between the protocol provider implementation and gui packages. One of the reasons for this is I guess the fact that the awt package is not included in the J2ME CLDC/MIDP for example, so this would automatically make all ProtocolProvider-s unusable with it. Hope this make sense.

Regards,
Yana

···

Thanks for your time,
Mihai

---------------------------------------------------------------------
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

Hi Yana,
Yup, it was a missing import. Sorry for spamming the mailing list with
that problem :frowning:

Emil will correct me if I'm wrong, but I think that the idea of having a
byte[] return type is to have no dependencies between the protocol
provider implementation and gui packages. One of the reasons for this is
I guess the fact that the awt package is not included in the J2ME
CLDC/MIDP for example, so this would automatically make all
ProtocolProvider-s unusable with it. Hope this make sense.

I thought about the dependencies issue too, but IMHO SIP-Communicator
is too heavyweight to think about porting it to J2ME (I know, it's a
little far fetched, and I do understand why things are how they are)

Regards,
Yana

All the best,
Mihai

···

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


#4

Hey Mihai,

You are right that returning plain bytes is indeed a bit clumsy, and Yana had actually brought up the same issue some time ago (even though she was playing devil's advocate in her previous post :wink: ). The thing is that so far we simply haven't found a satisfactory solution.

(-more inline-)

Mihai Balan wrote:

I thought about the dependencies issue too, but IMHO SIP-Communicator
is too heavyweight to think about porting it to J2ME (I know, it's a
little far fetched, and I do understand why things are how they are)

Indeed, SIP Communicator is far too heavy to be ported to J2ME in its current form. However this doesn't mean that no one would ever try to do it, and when they do they should be able to achieve this by simply replacing or modifying implementations of the various services and not the services themselves.

Other reasons that were brought out during previous discussions included:

Concerning java.awt.Image:
1. What do we gain by returning java.awt.Image since its only method is getBytes()?

Concerning javax.swing.ImageIcon:
2. Adds a dependency on Swing so it would be annoying for SWT implementations of the UI.

3. In case the protocol returns a image in a format that is not supported by AWT or Swing (sth. like SVG, AI, or WMF), this would make it impossible for other modules to display the image even if they know how to handle the format.
...

One other way to resolve the situation would be to define a simple Image interface in the protocol service, that in addition to a getBytes() method would also define a getMimeType() one.

Personally this is the one I prefer, but it could bring other problems.

For example: what if the protocol itself does not deliver information on the mime type and simply expects the application to discover it by parsing the image (which is what we are currently doing). In this case a getMimeType() method in our protocol Image interface would oblige protocol implementors to actually do a first parsing themselves in order to discover their mime type. Do we really want this? Personally, I'd try to avoid it, though others might argue that if the protocol has such a behaviour it is the job of the ProtocolProvider implementation to handle it. (I am wondering whether such a protocol really exists, by the way).

So, to sum up, we had already been through this problem and decided to temporarily bury it in the back yard until someone (like you for example :slight_smile: ) shows up with an elegant solution!

In the mean time, we are returning a plain byte array ...

Hope this makes more sense now.

Cheers
Emil

Cheers
Emil

···

Regards,
Yana

All the best,
Mihai

---------------------------------------------------------------------
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,
Yup, I understand now. Thanks for the very clear explanation :slight_smile:

Cheers,
Mihai

···

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