Extending Layer: bug?

I just found out that even with the API Javadocs leading you to believe it is possible to subclass layer by saying “Layer subclasses must implement a paint(Graphics) method so that they can be rendered”, the class cannot be subclassed by MIDP 2 developers.

The constructor of class Layer has default visibility, meaning that only classes within the same package can see the constructor.

I really believe it’s a bug. I see no reason for it to be this way. If they wanted the developers not to be able to extend Layer functionality, they would also make Sprite and TiledLayer final classes. As of today, the only way to extend a Layer is by subclassing one of those, wich is very ackward if what you intend is to create a diferent kind of a layer.

What are your soughts about that? I have found nothing on Sun about it.

I think it’s deliberate that Layer can’t be subclassed: the idea is that you should subclass Sprite or TiledLayer. This allows the API’s implementation to assume that all Layers are either Sprites or TiledLayers, which might simplify the implementation.

I agree, it should be made clearer. I remember being puzzled about this when I first noticed it.

While we’re on the subject - do you know of a zip/jar or other type of archive that I can download to view the source of the J2ME MIDP2.0 classes. I’ve got the API, but I’d like to look a little deeper as to what exactly is happening when I call certain methods.

Also, on the subject of subclassing can someone confirm that it is also not possible to create a subclass of Image?

[quote]While we’re on the subject - do you know of a zip/jar or other type of archive that I can download to view the source of the J2ME MIDP2.0 classes. I’ve got the API, but I’d like to look a little deeper as to what exactly is happening when I call certain methods.
[/quote]
Just reverse compile the libs.

[quote]Also, on the subject of subclassing can someone confirm that it is also not possible to create a subclass of Image?
[/quote]
The Image class has no constructor, only factory methods - it is therefor impossible to subclass it.

[quote]While we’re on the subject - do you know of a zip/jar or other type of archive that I can download to view the source of the J2ME MIDP2.0 classes. I’ve got the API, but I’d like to look a little deeper as to what exactly is happening when I call certain methods.
[/quote]
The API is the only thing that’s standard - the implementation will vary between phones. Even if you got hold of the source for Sun’s reference implementation or some manufacturer’s own implementation, you couldn’t rely on what you learn being true for other implementations.

I was just hoping that I could learn some commonly used methods of optimisation by looking at the API reference source code.

I think the code from the reference implementation is not optimized at all. For instance, TiledLayer is painfully slow. Its faster to draw the scene with clipping and drawImage().

The Nokia implementation, though, is quite fast. On the game I’m working on, a screen composed of 15x12 tiles, each tile 16x16 pixels, runs at 21 FPS on Sun’s implementation. On Nokia emulator it jumps to 62 FPS. Almost 3 times faster.

Other emulators (Sony Ericsson for instance) is just a diferent face for the sun wtk. They use the same, slow, code. I’m eager to test my app on a real device to see how it performs.