Uncle George wrote:
> 
> u really r stupid.

No, actually, I'm not. 

> The topic was porting issues, and ur notion that the .java jdk/source code cannot be 
>altered to fit the port. Do i really need to say more.
> gat

I only said the platform-independent portions of the jdk source code
cannot be modified to fit the port. Java's int data type is considered
platform-independent, and therefore, you may not modify it. I admit I
spoke too hastily in my initial post that "none of the .java files may
be altered"; nonetheless, I spoke in response to your complaints about
having to change the size of Java's int data type from 32-bit to 64-bit.

Section 4.2 of the Java Language Specification, which I quoted earlier,
specifies int as being 32-bits. Not 64-bits. Not 8-bits. 32-bits.
Changing the size of the data types is changing the core of the
language. Deviations from the JLS are *not permitted*. Yet you say you
have to change the size of int for your port to Alpha. You also refuse
to explain *why*. The size of int is *not* considered
"platform-dependent", it is, in fact, part of the core of the Java
language. To be sure I wasn't blowing hot air on this, I asked Mr.
Austin about it. Here is what he told me:
"They are allowed to change 4 packages that are shared which includes
java.lang where the object definition is, but not where int is."
                                          ^^^^^^^^^^^^^^^^^^^^^
(emphasis mine)

I'd say that is pretty definitive, since it came from Sun.

Let's take a look at your sample code for a minute, and the explanatory
comments you included after the code:
"5) In the land of alpha longs are 64bits as well as
address pointers =>

        .java
                 int    lets_store_a_32_bit_address;
                 private native    int wheres_my_window();
                 lets_store_a_32_bit_address = wheres_my_window();

                 ......

        Native .c
                 int    wheres_my_window(blah*,blah ){
                      long    addr;
                      addr = (Window) w;
                      return(addr);

                 }
"This particular example results in the truncation of a returned 64 bit
'c' address, into a 32bit '.java' variable/storage. u can of course
change the 'c' routine to return all 64bits, but that will be,
eventually, truncated by the jvm to 32bits. In the Land of "OSF/true64"
for the Dec Alpha, u can convince the compiler to produce 32bit pointer
arithemetic, where long == 32bits. But the currently available
linux/alpha compilers a long==pointer==64bits."

Well, as I've been saying all along, in the world of Java, long==64bits,
just like Alpha long==64bits, which is why your example is flawed. So,
your example could be rewritten like so:

NativeCExample.java:

public class NativeCExample {
        static {
                System.loadLibrary("native_c_example");
        }
        public NativeCExample() {
                long addr = wheresMyWindow();
                System.out.println(addr);
        }
        public static void main(String[] args) {
                NativeCExample example = new NativeCExample();
        }
        private native long wheresMyWindow();
}


                .......

native.c:

#include <jni.h>
#include "NativeCExample.h"
#include <stdio.h>
JNIEXPORT jlong JNICALL Java_NativeCExample_wheresMyWindow (JNIEnv *env,
jobject
 obj)
{
        jlong addr;
        addr = 9223372036854775807L;
        return addr;
}


Note that the value I'm assigning 'addr' here is the maximum value of
the Java long range. Also, 'addr' could have its value assigned to it
from any function which returns a 64-bit value.

Here's the output:
[jgalyan@talisman Jeff]$ java NativeCExample
9223372036854775807

Now everyone's happy. Your platform's native typedef for jlong can be
found in <java>/include/linux/jni_md.h -- and jlong is defined as 64-bit
on Intel platforms, too, by the way. I'm attaching the actual source
files I used for this so you can see I haven't changed them for the
post. Another thing - all the .java files which call native methods use
JNI, which means the appropriate types are being used (jlong, jint,
etc.).

You can see that you really don't have to change the size of int.

--Jeff

> 
> Jeff Galyan wrote:
> 
> > Why do you insist you *must* store the pointer in an int? Why can't you
> > use a long? If it's your application code, you *are* free to do as you
> > please, you know.
> >
> > However, the point remains that you are not legally permitted to change
> > the size of Java's int data type, as it is defined in the Java Language
> > Specification as 32-bits.
> >
> > --Jeff
> >
> > Uncle George wrote:
> > >
> > > Please return a long/64 bits Window address. Lemme know what gets stored in in 
>the java int valiable "lets_store_a_32_bit_address", which has the capacity to store 
>32 bits. I'm sorry, I thought a fairly simply program sample would demonstrate it 
>best.
> > >
> > > While ur pondering this porting delima, may u can figure out the other points 
>that I was attempting, but failed to make to u. Again I'm sorry for my failure.
> > >
> > > Jeff Galyan wrote:
> > >
> > > > Uncle George wrote:
> > > > > 5) In the land of alpha longs are 64bits as well as address pointers =>
> > > > >
> > > > >         .java
> > > > >                 int    lets_store_a_32_bit_address;
> > > > >                 private native    int wheres_my_window();
> > > > >                 lets_store_a_32_bit_address = wheres_my_window();
> > > > >                 ......
> > > > >
> > > > >         Native .c
> > > > >                 int    wheres_my_window(blah*,blah ){
> > > > >                      long    addr;
> > > > >                     addr = (Window) w;
> > > > >                     return(addr);
> > > > >                 }
> > > > > This particular example results in the truncation of a returned 64 bit 'c' 
>address, into a 32bit '.java' variable/storage. u can of course change the 'c' 
>routine to return all 64bits, but that will be, eventually, truncated by the jvm to 
>32bits. In the Land of "OSF/true64" for the Dec Alpha, u can convince the compiler to 
>produce 32bit pointer arithemetic, where long == 32bits. But the currently available 
>linux/alpha compilers a long==pointer==64bits.
> > > >
> > > > Your example is flawed in that you assume you should return an int from
> > > > wheres_my_window(blah*, blah). If you return a long, everything is fine,
> > > > since in the land of Java, long is defined as a 64-bit data type.
#include <jni.h>
#include "NativeCExample.h"
#include <stdio.h>

JNIEXPORT jlong JNICALL Java_NativeCExample_wheresMyWindow (JNIEnv *env, jobject obj) 
{
        jlong addr;
        addr = 9223372036854775807L;
        return addr;
}


/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class NativeCExample */

#ifndef _Included_NativeCExample
#define _Included_NativeCExample
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     NativeCExample
 * Method:    wheresMyWindow
 * Signature: ()J
 */
JNIEXPORT jlong JNICALL Java_NativeCExample_wheresMyWindow
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif

public class NativeCExample {

        static {
                System.loadLibrary("native_c_example");
        }

        public NativeCExample() {
                long addr = wheresMyWindow();
                System.out.println(addr);
        }

        public static void main(String[] args) {
                NativeCExample example = new NativeCExample();
        }

        private native long wheresMyWindow();

}
        

Reply via email to