Repository files navigation

This repository contains the archived source code of the oldSunphoneME project, converted to git.

Additional links:

• Java ME on Wikipedia
• Archive of the java.net phoneME project
• Archive of the java.net phoneME wiki
• Archive of phoneme.dev.java.net

The original source was published as Subversion athttps://svn.java.net/svn/phoneme~svn. This server is long defunct, sinceApril 28, 2017, but the SVN sources were saved to Archive.org as a SVN dump athttps://archive.org/details/phoneme-svn.dump. I have taken this dump andmassaged it into a sort-of usable git repo. This was trickier than it sounds,due to the odd layout of the Subversion repo. For details on the repo layout,seePhoneMERepositoryStructure.

In short, I have imported each individual component (with tags and branches) asseparate roots in the git repo. I have also imported thelegal,builds andreleases sub-trees the same way. In general, the names of tags and brancheswere unique enough to not collide, but there were a few exceptions. For these,an arbitrary source tag/branch was chosen and the other(s) are lost. Seemissing references below for a list of such tags andbranches that is not 100% correctly mapped from SVN.

Finally, to get a default view of the repo which makes the most sense, I havecreated a master branch into which I have merged all the individual trunks fromthe components (andlegal, and the top level trunk withwww). In some sense,this is the most recent view of the original SVN repository.

I chose to put the individual components directly in the root directory (likecdc), and not in acomponents directory (likecomponents/cdc). While thelatter had better matched the original layout, the method I choose makes it easyto checkout a tag frombuilds orreleases and get a similar layout.

Initially, I created a separate git repository for each component, usinggit svn fortrunk,tags andbranches, like this:

git svn clone file://.../phoneME-svn --no-metadata -bcomponents/$1/branches -tcomponents/$1/tags -Tcomponents/$1/trunk $1

Similarly, I created repositories forbuild andrelease, but for these, Iinterpreted the subdirectories as git tags:

git svn clone file:///.../phoneME-svn --no-metadata -t$1 $1

Finally, I createdlegal, and the main trunk (containingwww) using just thetrunk import argument:

git svn clone file:///.../phoneME-svn --no-metadata -T$1 $1

For some reason I could not fully understand,git svn did not create propertags and branches, but instead only populated.git/info/refs. I could notfigure out a proper git way of converting these to real branches and tags, so Iran this script for each mini-repo:

addtag () {  git show-ref | grep refs/remotes/origin/tags/$1 | cut -d " " -f1 > .git/refs/tags/$1}addbranch () {  git show-ref | grep refs/remotes/origin/$1 | cut -d " " -f1 > .git/refs/heads/$1}git show-ref | grep refs/remotes/origin/ | grep -v refs/remotes/origin/tags/ | cut -d " " -f 2 | cut -d "/" -f 4- > BRANCHNAMESgit show-ref | grep refs/remotes/origin/tags/ | cut -d " " -f 2 | cut -d "/" -f 5-  > TAGNAMESwhile read p; do  addtag $pdone < TAGNAMESwhile read p; do  addbranch $pdone < BRANCHNAMES

After this, I re-joined all these separate git repos into one. I did this bystarting out with thetrunk repo, and then importing commits, tags andbranches from each individual mini-repo. I also merged the master (trunk) ofeach individual mini-repo into the master of the consolidated repository,placing it in a suitable location usinggit read-tree. In effect, this is whatI did per mini-repo:

git remote add $1 /.../$1git fetch $1git fetch $1 --tagsgit merge -s ours --no-commit $1/master --allow-unrelated-historiesgit read-tree --prefix=$1/ -u $1/mastergit commit -m "Merge in $1/"

Duplicated tags, where only one were kept

Java_ME_SDK_Mac_CLDC-Darwin-158midp-cdc-win32-gci-1midp-mr2-promo-b05phoneme_advanced-mr1-rel-b06phoneme_feature-mr1-rc-b04sdk-tt-cf1sdk-tt-pr1

Duplicated branches, where only one were kept

abstractions-cr-6678413cdc-112_02cdc-cr-6520657cdc-protocldc-cr-6779573-timecode-subm-davyp-20080812javacall-cr-6769974javacall-mr2-cr-6517470jc_perm_fixjmesdk-agui-oijsr120-cr-6551021jsr211-cr-6662559leto_r1leto_r1_mr1leto_r1_mr1_rotation3leto_r1_mr1-rt_l10nmidp-cdc-win32-gcimidp-cr-6714912-asyn_network_commit_fixmidp-mr2-cr-6508174-TCK-OpenRecordStore1midp-mr2-cr-6524911midp-mr2-ixc-fixpmea-mr2-ea1protocol-permissionspush-refactoringsdk-tt-cf1ui_service

For compiling the components on a Linux AMD64 system, you need a GCC able toemit i686 code as well as a JDK capable of emitting Java 1.4 bytecode such asJDK6.

Additionally you need the equivalents of the following dependencies for yourdistribution (the packages here are listed for Fedora 35):

• glibc-static.i686
• libstdc++-static.i686
• binutils.i686
• musl-devel.i686
• glibc-devel.i686
• gcc-c++.i686

To build the CDC VM follow these steps:

1. Change to cdc/build/linux-x86-suse.
2. Ensure the correct javac is on the $PATH, see comment above.
3. Runmake.

You will find thecvm VM executable in the bin/ subfolder.

To build the CLDC VM follow these steps:

1. Change to cldc/build/linux_i386
2. Set the JVMWorkSpace environment variable to the absolute path of the cldcdirectory.
3. Set the JDK_DIR environment variable to your JDK distribution (see commentabove).
4. Runmake ENABLE_COMPILATION_WARNINGS=true ROMIZING=false ENABLE_JNI=false.

You will find thecldc_vm executable in the target/bin subfolder. Please notethat the system classpath needs to be passed into the VM together with yourapplication classpath. You can find it in cldc/build/classes. Currently it isrequired to disable romizing and JNI due to build issues with these optionsenabled. The ENABLE_COMPILATION_WARNINGS option disables the use of -Werrorwhich causes the build to fail with modern compilers.

Also seehttps://phonej2me.github.io/content/mr2/cldc_feature.html.