sun-jdk15 and wireless toolkit v2.2

[stefano-35]

hello ,

i've installed sun's jdk/jre with linux emulation fro pkgsrc (
pkgsrc/lang/sun-sdk15 & sun-jre15 )
did all the things i think i had to do to make it work
like mount emul linux procfs , set env variables ( JAVA_HOME , CLASSPATH
) etc ,

so far java (with linux emulation) works fine ,

the problem started when i installed the j2me toolkit ,
(it is used to create java applications for mobile phones and some
embedded boards)
exact name : j2me_wireless_toolkit-2_2-linux-i386.bin  ( it's linux and
it will run with emulation as jdk)

everything went ok with installation and running , i could run
precompiled example applications ,
but ,
couldn't compile new ones ,
after a while a traced it down to , toolkit not being able to load and
use the  "javac" class

decompiled code from sun's toolkit

               try
                {
                        class1 =
toolLoader.loadClass("com.sun.tools.javac.Main");
                        method = class1.getMethod("compile", new Class[] {
                                java.lang.String[].class
                        });
                }

this error is easy reproduced if unset the CLASSPATH env  variable
and compile any java program that makes use of loadClass(".....javac.....")


i found out that the script to fire up the toolkit ( ktoolbar  )
actually uses :

javac -cp {location libraries of toolkit} other_options other_options

this way it overrides totally (i think) the CLASSPATH env which points
to the correct tools
and here is the problem ,
if i add javac -cp location_libraries_sdk15:location_libraries_wtk it
works ok ,

since i've recently switched from debian to netbsd at the computer where
i work ,
i digged a little at my back up tapes from linux , and didn't observed
anything
that could reproduce this problem on linux

a friend of mine (with more java background than me and mostly a freebsd
guy )
pointed out that this might be happening due to not having a "native"
installation of java

so ,
a) has anyone any thoughts on this ? could this be happening due to non
native java ( sun-jdk instead of scsl-source-jdk )

b) could someone reproduce this with a native java installation ?

(from what i have tried on my system it's enough  to just visit
http://www.javaworld.com/javatips/jw-javatip131.html?page=2
download the simple example ,
and compile with out specifying "-cp" at the command line.

if we find a good solution ,
we can fix wip/sun-j2me package which has set PKG_FAIL_REASON
for quite a while now i think ,

thanks in advance

stefano _a_t_ arx.gr/net

[matthew sporleder]

On 6/20/07, stefanos mparas <stefano@...> wrote:

> hello ,
>
> i've installed sun's jdk/jre with linux emulation fro pkgsrc (
> pkgsrc/lang/sun-sdk15 & sun-jre15 )
> did all the things i think i had to do to make it work
> like mount emul linux procfs , set env variables ( JAVA_HOME , CLASSPATH
> ) etc ,
>
> so far java (with linux emulation) works fine ,
>
> the problem started when i installed the j2me toolkit ,
> (it is used to create java applications for mobile phones and some
> embedded boards)
> exact name : j2me_wireless_toolkit-2_2-linux-i386.bin  ( it's linux and
> it will run with emulation as jdk)
>
> everything went ok with installation and running , i could run
> precompiled example applications ,
> but ,
> couldn't compile new ones ,
> after a while a traced it down to , toolkit not being able to load and
> use the  "javac" class
>
> decompiled code from sun's toolkit
>
>                try
>                 {
>                         class1 =
> toolLoader.loadClass("com.sun.tools.javac.Main");
>                         method = class1.getMethod("compile", new Class[] {
>                                 java.lang.String[].class
>                         });
>                 }
>
> this error is easy reproduced if unset the CLASSPATH env  variable
> and compile any java program that makes use of loadClass(".....javac.....")
>
>
> i found out that the script to fire up the toolkit ( ktoolbar  )
> actually uses :
>
> javac -cp {location libraries of toolkit} other_options other_options
>
> this way it overrides totally (i think) the CLASSPATH env which points
> to the correct tools
> and here is the problem ,
> if i add javac -cp location_libraries_sdk15:location_libraries_wtk it
> works ok ,
>
> since i've recently switched from debian to netbsd at the computer where
> i work ,
> i digged a little at my back up tapes from linux , and didn't observed
> anything
> that could reproduce this problem on linux
>
> a friend of mine (with more java background than me and mostly a freebsd
> guy )
> pointed out that this might be happening due to not having a "native"
> installation of java
>
> so ,
> a) has anyone any thoughts on this ? could this be happening due to non
> native java ( sun-jdk instead of scsl-source-jdk )
>
> b) could someone reproduce this with a native java installation ?
>
> (from what i have tried on my system it's enough  to just visit
> http://www.javaworld.com/javatips/jw-javatip131.html?page=2
> download the simple example ,
> and compile with out specifying "-cp" at the command line.
>
> if we find a good solution ,
> we can fix wip/sun-j2me package which has set PKG_FAIL_REASON
> for quite a while now i think ,
>
> thanks in advance
>
> stefano _a_t_ arx.gr/net

So you have two versions of java installed?  If so, just remove the
one that doesn't work.

If not, a lot of java programs startup with the -cp command line
getting defined in a config file (something.properties) file, or from
a shell script (startup.sh, etc).

As far as fixing the native jvm, that's a little beyond me.  Sorry.  :)

[stefano-35]

matthew sporleder wrote:

> On 6/20/07, stefanos mparas <stefano@...> wrote:
>> hello ,
>>
>> i've installed sun's jdk/jre with linux emulation fro pkgsrc (
>> pkgsrc/lang/sun-sdk15 & sun-jre15 )
>> ---------------------------------------[big
>> snip]---------------------------------------------------
>> thanks in advance
>>
>> stefano _a_t_ arx.gr/net
>
> So you have two versions of java installed?  If so, just remove the
> one that doesn't work.
>
> If not, a lot of java programs startup with the -cp command line
> getting defined in a config file (something.properties) file, or from
> a shell script (startup.sh, etc).
>
> As far as fixing the native jvm, that's a little beyond me.  Sorry.  :)
>

no , i have only one installed ( sun-jdk15)
as far as i know , if i installed scsl-jdk15 from pkgsrc
( or i tried from http://www.duh.org/NetBSD/java2/ )
i would clarify for "native" java install

unfortunately , due to the fact that this machine is my production
computer at work , it's difficult to arrange power down hours ,
and install new jdk

that why i asked if someone with such a "native" java
could try and see if this behavior is similar or not ,

if this behavior is different then it could be from a simple
script file post-installed with sun-j2me package
to something deeper on suse_linux emulation

thanks for you time

stefano _a_t_ arx.gr/net

[Brian de Alwis]

I downloaded the Sun WTK 2.5 and managed to get a WTK demo project
to build using both a native JDK as well as a manually extracted
a Linux JDK (jdk-1_5_0_11-linux-i586.bin).  [The preverify binary
fails as it is linked against GLIB 2.6 though.]

So I suspect this problem has something to do with the directory
layout resulting from installing sun-jdk15/sun-jre15.

Doing a ktrace, it looks like the ktoolbar program tries to automatically
load tools.jar, but looks in the wrong place when using sun-j{dk,re}15:

 28802      1 java     CALL  stat64(0xb7649b78,0xb63fe6ac)
 28802      1 java     NAMI  "/emul/linux/usr/pkg/java/lib/tools.jar"
 28802      1 java     NAMI  "/usr/pkg/java/lib/tools.jar"
 28802      1 java     RET   stat64 -1 errno -2 No such file or directory

It's almost as if it's doing some test for whether some directory
contains a JRE, and manipulating the path otherwise (in this case,
stripping out `sun-1.5').  But I can't see anything in the ktrace
to indicate any tests.

Brian.

--
  Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/
      "Amusement to an observing mind is study." - Benjamin Disraeli

[Brian de Alwis]

On 2007.06.20 15:08:59 -0600, Brian de Alwis wrote:
> So I suspect this problem has something to do with the directory
> layout resulting from installing sun-jdk15/sun-jre15.

Looking into this further, the problem is indeed caused by conflicts
in assumptions in the layouts by the WTK's compilation code.

  * The WTK code assumes that the System property "java.home"
    points to a JRE directory contained within a JDK directory,
    and replaces the last with "/lib/tools.jar".  This is true
    for the pkgsrc-wip/jdk15 package and a manually installed
    Linux JDK; it is not true for lang/sun-j{re,dk}15.
    (See com.sun.kvem.ktools.ToolLoader defined in ktools.zip)

  * The JVM computes "java.home" by finding the path to libjvm.so
    and lopping off the last four '/'-delimited components.
    Unfortunately the sun-jre15 package installs the libjvm.so in
    /usr/pkg/java/sun-1.5/lib/<arch>/<vmtype>/libjvm.so.
    So java.home=/usr/pkg/java/sun-1.5, and hence why lib/tools.jar
    isn't found.

The solution is for sun-jre15 to preserve the layout of the JRE
when installing: replacing the jre directory with a symlink no
longer works.  It's ugly, but unfortunately seems to have become
necessary.

Brian.

--
  Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/
      "Amusement to an observing mind is study." - Benjamin Disraeli

[stefano-35]

Brian de Alwis wrote:

> On 2007.06.20 15:08:59 -0600, Brian de Alwis wrote:
>  
>> So I suspect this problem has something to do with the directory
>> layout resulting from installing sun-jdk15/sun-jre15.
>>    
>
> Looking into this further, the problem is indeed caused by conflicts
> in assumptions in the layouts by the WTK's compilation code.
>
>   * The WTK code assumes that the System property "java.home"
>     points to a JRE directory contained within a JDK directory,
>     and replaces the last with "/lib/tools.jar".  This is true
>     for the pkgsrc-wip/jdk15 package and a manually installed
>     Linux JDK; it is not true for lang/sun-j{re,dk}15.
>     (See com.sun.kvem.ktools.ToolLoader defined in ktools.zip)
>
>   * The JVM computes "java.home" by finding the path to libjvm.so
>     and lopping off the last four '/'-delimited components.
>     Unfortunately the sun-jre15 package installs the libjvm.so in
>     /usr/pkg/java/sun-1.5/lib/<arch>/<vmtype>/libjvm.so.
>     So java.home=/usr/pkg/java/sun-1.5, and hence why lib/tools.jar
>     isn't found.
>
> The solution is for sun-jre15 to preserve the layout of the JRE
> when installing: replacing the jre directory with a symlink no
> longer works.  It's ugly, but unfortunately seems to have become
> necessary.
>
> Brian.
>
>  

i have only installed lang/sun-jdk15 ( it depends on lang/sun-jre15 )
and the WTK (linux binary),
jre is symlinked to :

"Jun 19 16:09 /usr/pkg/java/sun-1.5/jre -> ."

based on your remarks , doing just a :

"ln -s /usr/pkg/java/sun-1.5/lib /usr/pkg/java/lib"

its enough for me to build ( compile , preverify , package )
successfully now
 
i wonder if this behavior ( filesystem layout , emulation , java-linux )
is "stable" enough so as to have patches for package sun-j2me to install ,
( or on the other hand set a pkg_fail_reason if it detects a non-native
java install )

thanks for your help ,

stefano