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.