Java Forum / General / February 2006
Increasing code shared between J2ME and J2SE versions
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 MagazinesGet 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 ...
|
|
|