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 ?

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

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:

{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

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,MMAPIgfx_class=128x128snd_class=MIDI

And my preprocess task looks like this:

1 2 3 4

<targetname="preprocess"depends="initialize"> <echomessage="Preprocessing with the following symbols: ${pp_symbols}" /> <wtkpreprocesssrcdir="${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:

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) basisand 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

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.

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?

Quote

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.

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.

Quote

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.

Quote

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) basisand the numbers of preprocessor statements balloons enormously.

Once the system is setup porting is quite easy.

Quote

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?

Quote

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!

Quote

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

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.

Quote

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)

Quote

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.

Quote

Once the system is setup porting is quite easy.

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

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.

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.

Quote

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.

Quote

or code navigation?

UE supports that more or less.

Quote

or refactoring?

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

Quote

How about syntax checking?

Nothing, that is not really a problem.

Quote

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

Well UE does support a lot of stuff.

Quote

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org