better preprocessor for eclipse

[Serethos]

currently im using antenna for using preprocessor statements. but it is really annoying that eclipse cant handle them and displays errors for name-collisions etc.
is there any (good) preprocessor out there, which has a full implementation to eclipse ?

[gangrel-br]

Thats a good question, and not specific to Eclipse. I use Antenna with NetBeans and have exactly the same problem. But I think a better solution would be a plugin for these IDEs to make then understand Antenna preprocess directives, instead of a completly new preprocessor. Is there such a tool

(Did you noticed I like Antenna?  )

[Serethos]

im very disappointed about antenna. theres another problem which gets more and more annoying:

i really need preprocessor statement which can compare to a value, like

<code>
//# if( ${used.api} == midp2 )
</code>

antenna does not support such thing yet. and if you look into the todo list of the antenna author you will notice that he plans to realize this, but he seems to be not the fastest creating new versions...

perhaps someone of you have a better idea how to solve my problem mentioned above.
currently im using dummy properties this way:


<code>
<condition property="res_176x208" value="true">
   <equals arg1="${res_images}" arg2="176x208"/>
</condition>
</code>

{res_images} contains an identifier for the resource-folder for the images ("176x208"). but because i cant test these values in the preprocessor statements i create a dummy property (whose value is without sense).
then i can test like this

<code>
//#ifdef res_176x208
</code>

i hate that ... really ..

Games published by our own members! Check 'em out!

[Matzon]

your resource stuff looks like it could be handled by polish:
http://www.j2mepolish.org/index.html

[shmoove]

They way I handle it is with ifdefs in the code:

1   2   3   4   5   6   7

//#ifdef NOKIAUI  // use DirectGraphics //#elifdef MIDP2  // use MIDP 2.0 features //#else  // use MIDP 1.0 features //#endif

The build script has the following two properties right at the beginning:

1   2

<property name="model" value="" /> <property file=".\properties\${model}.properties" />

That file property (the second one) means that properties will be loaded from a file.
Then I have property files for each device class I develop for with the properties for the preprocessor, for example one for the Nokia 6230 might look like this:

1   2   3

pp_symbols=NOKIA,MIDP2,MMAPI gfx_class=128x128 snd_class=MIDI

And my preprocess task looks like this:

1   2   3   4

<target name="preprocess" depends="initialize">   <echo message="Preprocessing with the following symbols: ${pp_symbols}" />   <wtkpreprocess  srcdir="${ppsrc.dir}"  destdir="${src.dir}" symbols="${pp_symbols}" /> </target>

Now anything in the pp_symbols part of the file is defined, so the preprocessor knows what parts to put in and what to leave out.

As for the resources, it's similar. I have a property in the build script to define the directory from where resources should be taken:

1   2

<property name="gfx.dir" location="${gfx_class}"/> <property name="snd.dir" location="${snd_class}"/>

In the package task I add a fileset property to include the appropiate directories:

1   2

<fileset dir="${gfx.dir}"/> <fileset dir="${snd.dir}"/>

So that the appropiate directories get packaged with the jar.

Now all I have to do is run ant with a -Dmodel={the name of the appropiate property file}, and everything from then on is automatic.

shmoove

[MOHK]

huh preprocessor 'Fcource ArcanumX2
Platform indepentend ...
try it + ECLIPSE ( don't get adicted )

[Anon666]

I suggest steering well clear of preprocessors.

There are publishers whose coding standards explicitly prohibit the use of them, and for good reason too.

In my personal experience preprocessed code becomes unmaintainable in a very short space of time,

Trivial examples such as :-

1   2   3   4   5   6   7

//#ifdef NOKIAUI // use DirectGraphics //#elifdef MIDP2 // use MIDP 2.0 features //#else // use MIDP 1.0 features //#endif

Already begin to show the problem of preprocessors.
For example, apply the above example to the area of Sound playback.
You will need different code for :-

- Nokia midp1,
- Nokia midp2, (with subtle but critical differences between 6600, 7650, 6230i, and a host of others)
- O2,
- Samsung, (both using the Samsung API, and using midp2. Again, both implementations will require subtle differences for various devices)
- Vodafone,
- Siemens,
- Motorola, (several different variants would be required)
- NEC,
- LG,
- Sagem,
- SonyEricsson, (atleast 2 variants would be required)

The list goes on and on!

And this is covering just the single aspect of sound playback!
Move onto any of the other areas that require changes when porting a game,
or address API bugs that appear on a per-device (or even per-firmware) basis
and the numbers of preprocessor statements balloons enormously.

I have seen games where there are more lines of preprocessor statements than lines of game code!!
At this stage, the code might as well be junked, as it has no value what-so-ever.

Basically, preprocessors are not scalable. They appear to be an adequate solution when you have to worry about just ~3 tiers of device -
but when the reality appears that you need to support upward of 100 devices, preprocessors are completely useless.


I wish I could elaborate on the alternative, but I would be in breach of my contract and would almost certainly get fired

[OverKill]

Exactly the reason my comp does not use Antenna, Eclipse or Netbeans.
We require a preproccessor and since they (along with other problems) stand in conflict to above we just don't use them.
Not pretty but UltraEdit and GNU work great.

[OverKill]

I suggest steering well clear of preprocessors.

There are publishers whose coding standards explicitly prohibit the use of them, and for good reason too.

You have a publisher for J2ME games?
Or do you mean Java-Verified?

In my personal experience preprocessed code becomes unmaintainable in a very short space of time,

Unless the person knows what they are doing, definetly not so.
While there are problems in the j2me landscape they will be there no matter what system you use.
F.i. my comp supports 60+ device groups ... I'd hate to imagine how it would be without a precompiler.
Not to mention the size, as using a precompiler will simply remove code so it is never passed to the compiler.

Trivial examples such as :-

1   2   3   4   5   6   7

//#ifdef NOKIAUI // use DirectGraphics //#elifdef MIDP2 // use MIDP 2.0 features //#else // use MIDP 1.0 features //#endif

1. can you 'define' stuff with antenna or use includes?
2. using 'features' is a sure path to getting yourself into a LOT of problems.

Already begin to show the problem of preprocessors.
For example, apply the above example to the area of Sound playback.
You will need different code for :-

- Nokia midp1,
- Nokia midp2, (with subtle but critical differences between 6600, 7650, 6230i, and a host of others)
- O2,
- Samsung, (both using the Samsung API, and using midp2. Again, both implementations will require subtle differences for various devices)
- Vodafone,
- Siemens,
- Motorola, (several different variants would be required)
- NEC,
- LG,
- Sagem,
- SonyEricsson, (atleast 2 variants would be required)

The list goes on and on!

Same problems you have with or without preprocessors.

And this is covering just the single aspect of sound playback!
Move onto any of the other areas that require changes when porting a game,
or address API bugs that appear on a per-device (or even per-firmware) basis
and the numbers of preprocessor statements balloons enormously.

Once the system is setup porting is quite easy.

I have seen games where there are more lines of preprocessor statements than lines of game code!!
At this stage, the code might as well be junked, as it has no value what-so-ever.

And I have seem games that were so horribly bloated it is a wonder they actually got the game in the jar!

The problem often lies with the programmers and not with the tools.
Anyone can write horrible code! But we do not blame Java for it do we?

Basically, preprocessors are not scalable. They appear to be an adequate solution when you have to worry about just ~3 tiers of device -
but when the reality appears that you need to support upward of 100 devices, preprocessors are completely useless.

Wrong!
You simply need to do some software engineering. Preprocessors are very flexible and powerfull.
Again, programmers are mostly at fault. I know my share of people that take the easy way and do exactly as you say. It is missleading to blame the tool for the user screwing up!

I know other companies that have other interresting ways of porting.
They copy the project and then change what needs to be changed.
So for every game they have, in case of 100 devices, 100 different versions!

I wish I could elaborate on the alternative, but I would be in breach of my contract and would almost certainly get fired

Hehe same here.

[Anon666]

I know other companies that have other interresting ways of porting.
They copy the project and then change what needs to be changed.
So for every game they have, in case of 100 devices, 100 different versions!

hehe, that sounds like jamdat's porting strategy.

Not to mention the size, as using a precompiler will simply remove code so it is never passed to the compiler.

A solution without a preprocessor does not imply an increase in code size.
Infact, size *reductions* are typically the case.
An optimal MIDlet should not have more than 2 classes. (except where there is a device limitation on max. class file size e.g. some of the Panasonics)

Wrong!
You simply need to do some software engineering. Preprocessors are very flexible and powerfull.

It is clear we differ in opinion, and the only way to convince you otherwise would be to expose corporate knowledge - so we will have to agree to differ.

Once the system is setup porting is quite easy.

Suffice to say, the ultimate aim is to make porting a zero effort task.

Games published by our own members! Check 'em out!

[OverKill]

I wish I could elaborate on the alternative, but I would be in breach of my contract and would almost certainly get fired

Rapid-M?
The ever mysterious software everyone has heard about but no one knows a thing?

[Anon666]

Exactly the reason my comp does not use Antenna, Eclipse or Netbeans.
We require a preproccessor and since they (along with other problems) stand in conflict to above we just don't use them.
Not pretty but UltraEdit and GNU work great.

What do you use for a runtime debugger?
Do you have code completion?
or code navigation?
or refactoring?
How about syntax checking?

Are you saying you go without all the features of modern IDEs?

The impact in productivity from not using an IDE such as Eclipse or Netbeans is beyond calculation.

[OverKill]

Exactly the reason my comp does not use Antenna, Eclipse or Netbeans.
We require a preproccessor and since they (along with other problems) stand in conflict to above we just don't use them.
Not pretty but UltraEdit and GNU work great.

What do you use for a runtime debugger?

Mostly the command line but we also eclipses debugger.
Though the debugger is a little pain because it uses preproccessed code.

Do you have code completion?

UE has a basic system but nothing more.
The problem is that code completion relies on a library but, like you said earlyer, we have multiple libs.
Classes available in one lib might not be available in another lib, or be a little different or be elsewhere (siemens loves to do that).
I doubt any IDE 'out of the box' would support multiple libraries with an appropriate interface and whatnot.

or code navigation?

UE supports that more or less.

or refactoring?

nothing beyond a search&replace, which seems to be quite enough.

How about syntax checking?

Nothing, that is not really a problem.

Are you saying you go without all the features of modern IDEs?

Well UE does support a lot of stuff.

The impact in productivity from not using an IDE such as Eclipse or Netbeans is beyond calculation.

If we were in a regular programming environment I'd agree. (I use Eclipse at home mainly)
But this is J2ME + vendor libs.
Actually if anything I'd say the biggest loss would be the debugger. But we have made changes to our tools to compensate that.