The purpose of this proposal is to assess the demand and determine the best way to deliver a Java SE - runtime for Fremantle / Maemo 5.

Java SE is the runtime intended for Desktop systems, but implementations for Mobile Devices do exist. The possible target audience for a Java SE runtime on Fremantle is considerably smaller than for a Java ME implementation, but many business applications still provide Java interfaces for legacy compatibility. Providing the possibility to run these business applications might lower the barrier for corporations to consider using Maemo 5 in a corporate environment.

Ideally, this brainstorm proposal results in a Java SE Package available in the Fremantle-Repositories for easy distribution through the Maemo 5 App Manager.

The thread that sparked this proposal:
Java for Maemo 5

This is not supposed to be yet another "Nokia should do it" proposal - if you want an implementation, please vote not only for the "Nokia-option", but place a 2nd vote on your favourite community solution so we will know where to invest our time first, should Nokia really decide not to buy an official License.

Currently there doesn’t seem to be an easy way to start developing in Qt for Maemo 5. Yes, Qt Creator is available for Windows and it works well. But if you want to develop for Maemo 5, most of the solutions seem to point at Linux. While this makes sense to a certain extent – after all, Maemo is based on Linux – Qt should be cross platform, thus one should be able to use Windows in a relatively painless way.

The fact is that Windows is the most used OS in the world, no matter how bad or good it is. Therefore there are a lot of Windows developers in our planet. Some of these might find it interesting to try to develop something for Maemo. And since Qt seems to be the future for Maemo platform, at least according to Nokia, it would make sense to have something to make it possible.

While for the professional developer it might be enough to just have some documentation how to set up a VM developing environment, this could be too complicated for an occasional coder. Let us not forget how easy it is to set up Visual Studio.

A MIDP - compatible Java ME runtime is present on most of today's smartphones, nearly all of the latest Nokia devices are delivered with Java ME available.

It is an established technology with a big developer base, there are many Applications and Games available, but currently there is no easy way for endusers to be able to run their MIDlets on the new Maemo 5 Platform.

Ideally, this brainstorm proposal results in a Java ME Package available in the Fremantle-Repositories for easy distribution through the Maemo 5 App Manager.

The thread that sparked this proposal:
Java for Maemo 5

This is not supposed to be yet another "Nokia should do it" proposal - if you want an implementation, please vote not only for the "Nokia-option", but place a 2nd vote on your favourite community solution so we will know where to invest our time first, should Nokia really decide not to buy an official License.

Disscuss here:

http://talk.maemo.org/showthread.php?p=419695

Example: if I want to correct a bug or add a features in Maemo OS, where I go? Where I get the source code? To who I send my contribution?

The original authors/porters may or may not be interested (or be even around any more) in porting it to Fremantle.  Their needs to be some way for developers who are willing to just port existing applications, and/or take ownership and revamp the interface to be consistant with the new UI.

Talk Thread: http://talk.maemo.org/showthread.php?p=357594

Forum discussion:

http://talk.maemo.org/showthread.php?t=39756

OpenCL was mentioned.

respective thread: http://talk.maemo.org/showthread.php?t=35950

ANT+ homepage

Some Linux software already works with the protocol using a USB adaptor that is basically an ANT+ to serial adaptor:

Garmin ANT+ data downloader

another ANT+ utility

Garmin ANT+ decoder

Talk thread here.

The root directory of Maemo5 is limited to 256MB on the N900. This is a serious limitation, and users often and easily fill it up (especially if using the extras-devel repository). It is unfortunate in other ways too. For example, the standard Debian distro officially supports Arm7, so with a better partitioning, much of Debian would be directly usable through apt-get. We could use the full gamut of GNU/Linux commands instead of the settling for the Busybox replacements - imagine, "less" and "man" included by default!

The current solution is "optification". However, that solution is brittle since it requires active adaptation of all packages so that they are placed in /opt instead of in their usual locations. This means added burden on developers and makes packages slower to move into stable repositories.

As far as I know, the total set of mass storage available for the N900 is:

* 256MB Root partition (in a fast 256MB flash)

* 768MB Swap

* 2GB /home

* 27GB FAT32 USB storage

(Swap, /home and USB storage are all in a 32GB slow flash)

If I understood this correctly, the main reason for the small root partition is that it is in a faster flash than the home partition. To keep the device responsive, the speed sensitive stuff is placed in that flash, and other stuff is placed in /opt (/opt in turn is mounted in /home).

There are a few more constraints, in summary:

1) There is a fast 256MB flash and a slow 32GB flash

2) The device needs to be capable of getting to a guaranteed stable functioning state from a reflash

3) A reflash should not delete the user's document data (i.e. pics, music, etc) in the large flash storage

4) A reflash will always replace the entire contents of a flash memory.

Right now I am using a home grown solution, but it breaks each time the distro has an upgrade, forcing me to spend days rebuilding and moving everything again. And newbies end up having to reflash just because they tried out a few beta-level apps and filled the root partition to a point where booting fails. We need a better standard solution!

There is a related Brainstorm about re-partitioning the 32GB internal flash, though that doesn't solve the root directory problem.

Discus this brainstorm in the forums

There has also been some previous discussion in the Wikis