Increasing code shared between J2ME and J2SE versions

[David N. Welton]

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,
--
David N. Welton
- http://www.dedasys.com/davidw/

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

 

[Ferenc Hechler]

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

 

[Daniel Dyer]

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.

 

[David N. Welton]

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,
--
David N. Welton
- http://www.dedasys.com/davidw/

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

 

[Roedy Green]

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

 

[Thomas Weidenfeller]

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

 

[Roedy Green]

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.

 

[David N. Welton]

there is a class like that already called Number

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

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

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

 

[Thomas Weidenfeller]

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

 

[Roedy Green]

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.

 

[Thomas Weidenfeller]

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