Classification: |
Java |
Category: |
JNI |
Created: |
06/29/99 |
Modified: |
09/02/2001 |
Number: |
FAQ-0239 |
Platform: |
ER5 |
|
Question: In the PowerInfo example in the SDK, a TInt64 variable is the return variable to the TimeOnPower() method. This is explicitly
cast to a jlong before it is returned. Yet the JNI documentation from Sun indicates that no such casting should be necessary
for a long variable in C or C++. Why is the cast used? And is such a cast necessary for other basic types?
Answer: The cast is needed because TInt64 is a class, whereas jlong is a primitive type similar to int or double. There is no TInt64 constructor which takes a jlong, nor any TInt64 function which returns a jlong, but the representations in memory are identical so the cast allows us to treat either value as though it is the other. jlong jvalue; TInt64 int64value;
int64value = jvalue; // illegal - no suitable constructor int64value = *REINTERPRET_CAST(jlong*,&jvalue); // nasty, but works
All of the other Java arithmetic types are simple typedefs for standard C++ primitive types, and have corresponding EPOC typedefs:
Further information about jlong
EPOC does not currently have a name for the primitive 64-bit integer type, and in fact the ANSI C and C++ standards do not
include 64-bit integers. Both MSVC and GCC support 64-bit integers as non-standard extensions and the EPOC Runtime for Java
makes use of that support where possible.
In particular, the compilers will be able to support code such as
jlong j1=100; jlong j2=37; j1 = j1+j2; // MSVC and GCC compilers generate appropriate inline assembler
but not
j1 = j1/j2; // OK with MSVC, fails with GCC
because the GCC compiler will assume the existence of a helper function which EPOC does not provide. The problem will show
up as a link-time error in MARM builds, similar to the problem with certain operations on TReal32 and TReal variables - see "What is __fixunssfsi?" in the EPOC C++ Knowledgebase.
|