Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / March 2006

Tip: Looking for answers? Try searching our database.

Serializable interface on J2ME MIDP 1.0 device

Thread view: 
jimi_usenet@hotmail.com - 29 Mar 2006 16:22 GMT
I am part of a small J2ME projekt that has both a server side (J2EE)
and a client side (J2ME, MIDP 1.0). Now I have found a small problem,
when we share code on both sides. I have an class Article, which is
needed on both the mobile phone application, and on the server side.
Now, on the server side I need it to be serializable, but when I write
"implements java.io.Serializable" it won't compile on the client side
(using Sun's Wireless Toolkit). Apperently the interface
java.io.Serializable doesn't exist in in MIDP 1.0. To work around this,
we currently have two different Article classes, one for each side. But
it feels really stupid to have two practically identical classes. The
*ONLY* difference is that one implements java.io.Serializable. Is there
a better way? We would like to use a single class file for both sides.

First I thought that we could simple create the package java.io on the
J2ME side, with the interface Serializable. But what would happen if
the application is run on a MIDP 2.0 phone, that already has the
java.io.Serializable interface? It seems that it could cause some
trouble...

Note: the server side doesn't use serialization when sending data to
the mobile (it uses simple http text only for that).

Regards
/Jimi
Thomas Hawtin - 29 Mar 2006 15:37 GMT
> I am part of a small J2ME projekt that has both a server side (J2EE)
> and a client side (J2ME, MIDP 1.0). Now I have found a small problem,
[quoted text clipped - 8 lines]
> *ONLY* difference is that one implements java.io.Serializable. Is there
> a better way? We would like to use a single class file for both sides.

The technique I've used is to use my own interface xyz.Serializable
instead of java.io.Serializable. The version of xyz.Serializable
compiled for J2SE/J2EE implements java.io.Serializable. The J2ME version
does not.

Alternatively you can use sed or something similar (there's a suitable
task in ANT) to remove the implements java.io.Serializable when
compiling for J2ME. Or equivalently, to add it when compiling for J2SE/J2EE.

> First I thought that we could simple create the package java.io on the
> J2ME side, with the interface Serializable. But what would happen if
> the application is run on a MIDP 2.0 phone, that already has the
> java.io.Serializable interface? It seems that it could cause some
> trouble...

If the phone already has java.io.Serializable, then it will just use its
own copy. However, if it doesn't have it, then it will probably complain
about loading classes into java.*.

Tom Hawtin
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

jimi_usenet@hotmail.com - 29 Mar 2006 20:50 GMT
> The technique I've used is to use my own interface xyz.Serializable
> instead of java.io.Serializable. The version of xyz.Serializable
> compiled for J2SE/J2EE implements java.io.Serializable. The J2ME version
> does not.

That worked like a charm. Thanks for the tip, Tom!

/Jimi


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.