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 / February 2006

Tip: Looking for answers? Try searching our database.

Increasing code shared between J2ME and J2SE versions

Thread view: 
David N. Welton - 07 Feb 2006 22:08 GMT
Hi,

We've hit something of a stumbling block with Hecl
(http://www.hecl.org), and it's proving tricky. J2ME doesn't necessarily
have floating point. And since we'd like Hecl to run in as many places
as possible, this necessitates that the J2ME and J2SE versions contain
different code, but Java doesn't make this easy, because there are no
macros or other ways of conditionally compiling code.

The solution we've adapted so far is problematic because it's not very
fine grained: we have two separate directories, one for 'core' Hecl
(sans floats) and another that contains the exact same classes, but with
floating point. For instance:

http://cvs.sourceforge.net/viewcvs.py/hecl/hecl/core/org/hecl/BasicMathCmd.java?
rev=1.7&view=markup

(no floating point)

http://cvs.sourceforge.net/viewcvs.py/hecl/hecl/float/org/hecl/BasicMathCmd.java
?rev=1.6&view=markup

(floating point)

As you can imagine, this means that code is replicated in two places,
and each change has to be done twice, carefully, keeping track of the
actual differences between the two files. This can only get worse as the
code grows.

I've seen some hacky ways of doing macros and things like that, but they
don't look very satisfying. I'm too much of a Java novice to think of
anything better than what we've got, though.

Any thoughts from the experts?

Thankyou,
Signature

David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

Ferenc Hechler - 07 Feb 2006 22:31 GMT
> J2ME doesn't necessarily
> have floating point. And since we'd like Hecl to run in as many places
> as possible, this necessitates that the J2ME and J2SE versions contain
> different code, but Java doesn't make this easy, because there are no
> macros or other ways of conditionally compiling code.

You could define an Interface "IntOrDouble" which replaces all occurrences
of "int" and "double" in your methods.
There are two Classes implementing this Interface: "IntImpl" and
"DoubleImpl".
Which one is used depends on the runtime-environment (j2me / j2se). You
could use the "Factory"-Pattern to create environment-depending instances.
Only the Factory-Code and the "...Impl" Classes would be be environment
dependant.

On the other hand:
j2me applications normally should be quite small and careful in allocating
resources.
Using a Wrapper-Class for all "int" occurrences might bloat up your code in
some way.
Perhaps your idea about using some "macro-pre-processor" might be the right
way to avoid maintaining two code-bases?

Best regards,

   feri
David N. Welton - 07 Feb 2006 23:08 GMT
>>J2ME doesn't necessarily
>>have floating point. And since we'd like Hecl to run in as many places
[quoted text clipped - 3 lines]
>
> You could define an Interface "IntOrDouble"

> ...

> On the other hand:
> j2me applications normally should be quite small and careful in allocating
> resources.
> Using a Wrapper-Class for all "int" occurrences might bloat up your code in
> some way.

Yeah, I think in the end it would probably add some weight and make
things pretty inelegant in that portion of the code.  It would be a good
suggestion under different circumstances though, thanks.

> Perhaps your idea about using some "macro-pre-processor" might be the right
> way to avoid maintaining two code-bases?

Yes, as Daniel Byer mentions, there are a lot of things out there, but
many of them have sort of a hacky feel, to me at least.  If someone here
has had some experience with one or the other and can make
recommendations, I'd be curious to hear it.

Thanks,
Signature

David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

Roedy Green - 08 Feb 2006 08:09 GMT
On Tue, 7 Feb 2006 23:31:52 +0100, "Ferenc Hechler"
<ferenc.hechler@web.de> wrote, quoted or indirectly quoted someone who
said :

>You could define an Interface "IntOrDouble" which replaces all occurrences
>of "int" and "double" in your methods.

there is a class like that already called Number
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

David N. Welton - 08 Feb 2006 19:15 GMT
> On Tue, 7 Feb 2006 23:31:52 +0100, "Ferenc Hechler"
> <ferenc.hechler@web.de> wrote, quoted or indirectly quoted someone who
> said :
>
>>You could define an Interface "IntOrDouble" which replaces all occurrences
>>of "int" and "double" in your methods.

> there is a class like that already called Number

There is no Number in J2ME, or at least the version I'm dealing with.

Signature

David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

Daniel Dyer - 07 Feb 2006 22:40 GMT
> I've seen some hacky ways of doing macros and things like that, but they
> don't look very satisfying. I'm too much of a Java novice to think of
> anything better than what we've got, though.

You could perhaps do some templating with Velocity  
(http://jakarta.apache.org/velocity/).  There are also various Java  
pre-processors returned by Google.

Dan.

Signature

Daniel Dyer
http://www.dandyer.co.uk

Thomas Weidenfeller - 08 Feb 2006 08:32 GMT
> We've hit something of a stumbling block with Hecl
> (http://www.hecl.org), and it's proving tricky. J2ME doesn't necessarily
> have floating point. And since we'd like Hecl to run in as many places
> as possible, this necessitates that the J2ME and J2SE versions contain
> different code, but Java doesn't make this easy, because there are no
> macros or other ways of conditionally compiling code.

If you want that, just use a separate preprocessor. Some people are
happy with just using a stand-alone C preprocessor. I prefer the Unix m4
macro processor in case of emergency.

Add the preprocessor to your build system, so it is run automatically
when the input has changed, and possibly write the output to
version-specific (J2SE, J2ME) output directories, from which you than
compile as usual.

/Thomas
Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

Roedy Green - 08 Feb 2006 17:57 GMT
On Wed, 08 Feb 2006 09:32:33 +0100, Thomas Weidenfeller
<nobody@ericsson.invalid> wrote, quoted or indirectly quoted someone
who said :

>If you want that, just use a separate preprocessor. Some people are
>happy with just using a stand-alone C preprocessor. I prefer the Unix m4
>macro processor in case of emergency.

You might be interested in my Untouch utility. You would run it after
you have done your macro expansions to put the dates back on the
generated files if they have not really changed.  Other wise you
trigger a needless mass recompilation every time you build.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas Weidenfeller - 09 Feb 2006 08:47 GMT
> You might be interested in my Untouch utility. You would run it after
> you have done your macro expansions to put the dates back on the
> generated files if they have not really changed.  Other wise you
> trigger a needless mass recompilation every time you build.

A good build system doesn't have such problems. It only runs the macro
processor if the input to the processor has changed. And then you of
course want to re-compile the output of the macro processor, because it
is very likely that the output is different from the previous output. So
it is absolutely right that the file's time is newer.

/Thomas
Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

Roedy Green - 09 Feb 2006 11:43 GMT
On Thu, 09 Feb 2006 09:47:07 +0100, Thomas Weidenfeller
<nobody@ericsson.invalid> wrote, quoted or indirectly quoted someone
who said :

>A good build system doesn't have such problems. It only runs the macro
>processor if the input to the processor has changed

But you may be tinkering with your macro processor all the time, so
for safety, you have to regenerate everything.  Most of time, only a
little changes.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas Weidenfeller - 09 Feb 2006 12:21 GMT
> But you may be tinkering with your macro processor all the time, so
> for safety, you have to regenerate everything.  Most of time, only a
> little changes.

Why? A simple dependency rule in [cough] make, and you only run the
macro processor on things which have changed.

/Thomas
Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/



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.