I run into the outofmemory wall quite often on my app that has different screens. One screen users a parser to read data from a file. I’d much rather instanciate the objects as I need them, and then be really clean with my de-referencing to make sure garbage collection works well. With the approach of just instantiate everything once, you end up having stuff reside in memory when it isn’t needed.

Mindin.: I wasn’t referring to standard preprocessing (polish shud be the standard ;-). I’m hinting at some kind of code optimizer that would convert multiple classed midlets into a one classed “Netbeans Visual Midlet” style midlet.

I think we’ll all be old and grey by the time that surfaces.

Tom: What r ur thoughts on using a DisplayManager class with public members used for requesting Displayables in midlets? This currently ensures that displayable objects will only ever be instanciated once.

And I agree, that most of these “tricks” slowly tends to disappear. However, there is still always some “tricky” cases from time to time

Charl: you are right, it’s another option too. But one of the issue with this approach, is then it’s very hard to debug on someplatform, and this could generate some more complex problem to debug if your tools does not do exactly what is expected.

I think good compilers to should also be able to inline methods that are declared static and final.

And with regard to the comment:

Most of these “Assembly Java” tricks are very bad for code maintanance and nowadays are really not needed since most phones have plenty of memory and processing power.

As a developer, I try to always push the perfomance of my code. If I can find anyway to decrease startup and increase performance, I will put it into the code.

-s4111

As I said, this is changing with time. In recent phones, this is quite useless, but on older, or very constrained devices, some are still valids, believe me.

And doing “search and replace” on a file is like preprocessing, no?

I give you an example: on J2ME, supporting both Floating point on CLDC1.0 and on CLDC1.1. Of course, I could use a Float class for both, and wrap CLDC1.1 float type on an object.

But then I have a HUGE penalty of creating a lot of interim Float object, and loose benefit of natives float. This is obvious on some devices like blackcberry, where garbage collection is very costly…

But may be there is another option?

(and yes, I do use an obfuscator, don’t worry!)

There is this little known trick to use “static final boolean USE_JSR = true” and wrap all JSR calls with that. To remove all of that from the code, just set this variable to false. You must use an obfuscator because the obfuscator does remove code that is not used and by defining “static final” it knows that code has got to go.

Using this technique you can easily setup different builds from the same source code without preprocessing directives. You can arrange “static finals” into one class/file and have only that file preprocessed or simply modified by an Ant script (for example - simple search and replace will do it).

Most of these “Assembly Java” tricks are very bad for code maintanance and nowadays are really not needed since most phones have plenty of memory and processing power. A lot of times the bottleneck is at a completely different place than anticipated and you can only find out by using profilers and disassembler (for decreasing .class size).

Carlos.