Skip to main content

Cannot find symbol toURI() while trying to compile CDC Foundation

6 replies [Last post]
Joined: 2007-04-10

Hello all,

I am trying to compile cross-compile CDC with the foundation profile for linux-arm-generic. I get the following error message when compiling build-time classes:

if [ -s /home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/build/linux-arm-generic/./.btclasses.list ] ; then \
echo "Compiling build-time classes..."; \
/usr/lib/jvm/java-6-sun/bin/javac -g:none -J-Xms32m -J-Xmx128m -encoding iso8859-1 -source 1.4 -target 1.4 \
-d /home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/build/linux-arm-generic/./btclasses \
-bootclasspath /home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/build/linux-arm-generic/./btclasses: \
-classpath -none- \
-sourcepath /home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/src/share/javavm/classes:/home/mmorissette/dev/workspace/phoneme-8d/8d/src:/home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/src/share/foundation/classes:/home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/src/share/classes:/home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/src/linux/classes:/home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/src/share/classes/cldc:/home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/build/linux-arm-generic/./generated/classes \
@/home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/build/linux-arm-generic/./.btclasses.list ; \
touch /home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/build/linux-arm-generic/./.btclasses; \
Compiling build-time classes...
/home/mmorissette/dev/workspace/phoneme-8d/phoneme_svn/cdc/src/share/foundation/classes/sun/security/provider/ cannot find symbol
symbol : method toURI()
location: class
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
make: *** [.compile.btclasses] Error 1
There where some errors while invoking make, please see above for errors

I have tried using both a JDK1.4 and the latest JDK6u10 as compile tools but both are failing.
I have also tried compiling both the latest phoneME Advanced MR2 b97 release as well as an up-to-date checkout from SVN.

Looking at the Java API documentation, the File.toURI() method has been present since JDK4 and therefore should be found by phoneME's build environment.

Here are my build option variables"
"CVM_AGENTLIB=false\n" \
"CVM_AOT=false\n" \
"CVM_CREATE_RTJAR=false\n" \
"CVM_DEBUG=false\n" \
"CVM_DUAL_STACK=false\n" \
"CVM_GCCHOICE=generational\n" \
"CVM_GCOV=false\n" \
"CVM_GPROF=false\n" \
"CVM_HOST=i686-Debian-linux\n" \
"CVM_IAI_OPT_ALL=true\n" \
"CVM_INSPECTOR=false\n" \
"CVM_JAVAC_DEBUG=false\n" \
"CVM_JIT=true\n" \
"CVM_JIT_CODE_SCHED=false\n" \

"CVM_JIT_DEBUG=false\n" \
"CVM_JIT_PMI=false\n" \
"CVM_JIT_PROFILE=false\n" \
"CVM_JVMPI=false\n" \
"CVM_JVMTI=false\n" \
"CVM_JVMTI_ROM=false\n" \
"CVM_KNI=false\n" \
"CVM_LVM=false\n" \
"CVM_MP_SAFE=false\n" \
"CVM_MTASK=false\n" \
"CVM_OPTIMIZED=true\n" \
"CVM_PRELOAD_LIB=true\n" \
"CVM_PRODUCT=premium\n" \
"CVM_REFLECT=true\n" \
"CVM_SPLIT_VERIFY=false\n" \
"CVM_SYMBOLS=false\n" \
"CVM_TEST_GC=false\n" \
"CVM_TRACE=false\n" \
"CVM_TRACE_JIT=false\n" \
"CVM_USE_MEM_MGR=false\n" \
"CVM_VERIFY_HEAP=false\n" \
"CVM_XRUN=false\n" \
"J2ME_CLASSLIB=foundation\n" \
"OPT_PKGS=\n" \
"USE_AAPCS=true\n" \
"USE_CDC_COM=\n" \
"USE_GCI=false\n" \
"USE_JUMP=false\n" \
"USE_MIDP=false\n" \

Is this a bug in the phoneME build environment or did I miss something?


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-10-16

The Foundation version of contains toURI(), and this is what should be used for a J2ME_CLASSLIB=foundation build. The CDC version of does not contain toURI(). It sounds like you are doing a foundation build, but for some reason the makefiles are picking up the CDC version of To prove this, edit the following two files, introducing some sort of build error in each, and see which one is being built:


It should be picking up the 2nd one. Before doing this I would advise doing a "make clean" and rebuild. It's possible that an old version of the CDC File.class is lying around from a J2ME_CLASSLIB=cdc build (which is the default), and for some reason was not deleted when you switched to J2ME_CLASSLIB=foundation.


Joined: 2007-04-10

It turns out it was picking the cdc version of (src/share/classes/java/io/

After doing a little bit more digging, I found a potential bug in phoneME's makefiles. To simplify automated builds of phoneME for our target hardware platform, here at work, I was using a custom main.mkfl file that contained the folowing:

CVM_TARGET_TOOLS_PREFIX = arm-linux-gnueabi-

J2ME_CLASSLIB = foundation
USE_AAPCS ?= true

JDK_HOME ?= /usr/lib/jvm/java-6-sun

CVM_JIT ?= true
USE_GCC2 ?= false

include build_time_env.mkfl

*The other build_time_env.mkfl only contains a version number.

Looking at the output of the log file, I found out that either the J2ME_CLASSES variable was being overridden in some makefile in the build process or a some included makefile is making an invalid check on the variable's value. This conclusion became obvious to me when I noticed that for some included makefile it was using the proper value for CVM_TARGET_TOOLS_PREFIX and the default value in others.

The only workaround I found to this issue was to pass my variables explicitly as arguments to make as MAKEFLAGS:
> make -f main.mkfl J2ME_CLASSLIB=foundation CVM_TARGET_TOOLS_PREFIX=arm-linux-gnueabi-

I think this is a bug in phoneME's build process and should be addressed as so.

Any opinions?

Joined: 2006-10-16

Your not showing everything. I assume that somewhere in main.mkfl you have an "all" rule that invokes the CDC GNUmakefile. If so, the problem is that you are not exporting any of the variables in main.mkfl. If you want them passed to the submake, you need to put "export" in front of them. For example:

export J2ME_CLASSLIB = foundation

Joined: 2007-04-10

You are right, I did omit a very piece of information, build_time_env.mkfl includes ../shared/ Therefore, when I call make -f main.mkfl, it runs the "all" default rule from ../share/

I designed my main.mkfl based on the example GNUMakefile file in linux-arm-generic that comes with phoneME's source tree thinking that setting variables without exporting them was the right way to go. Why would I need to export the variables in order for the build process to work? I should simply have to assign the desired value to my variables and they should be handled by the build process.

Should I really be exporting my variables or should I be able to set them in my calling makefile (i.e. main.mkfl in my case) ? Can we still consider this a bug in the build process?

Thanks for the help,

Joined: 2006-10-16

You need to include last. When I add "J2ME_CLASSLIB=foundation" to the GNUmakefile before it includes, then it works. If I do it after including, then it does not work.

Joined: 2007-04-10

Hi cjplummer, thanks for the reply.

I am already including last. The very last line of my custom makefiles (build_time_env.mkfl) includes ../share/

My work around to the problem is to have a shell script that parses my file and passes J2ME_CLASSLIB as an argument when calling make -f

It's definitely weird but it works!