>>>>> Cees de Groot writes:
Cees> Uncle George:
>> Actually u do have to change the '.java' files ( simply for
>> practicable convience ). Having extensive experience in porting
>> sun's JDK, I find it rather difficult to store 64bits into a
>> 32bit java int. Maybe u can review the java-linux-porting
>> diffs of their 1.2 port. I'd like to know, for example, how
>> the solaris printer 'queue' switches was changed to be
>> compatable with linux printer 'queue' commands.
Cees> Where do 32/64bit differences on the platform bubble up to
Cees> the java.* level that you would need to change this? If
Cees> there are such locations, these should be reported as bugs
Cees> because on the java level you shouldn't be able to determine
Cees> the native wordsize of the underlying platform.
I'll agree with you on that, but not all of the java code in the JDK
source code is platform independent and there are situations where the
Solaris specific java source code (these are the .java files Uncle
George is talking about) has be changed for Linux ports (even for
32bit ports). Note that this does not affect the public java.*
APIs/classes.
The printer 'queue' commands are one example where a Solaris-specific
java file has to be changed in order to work on Linux.
Cees> Changing the wordsize of standard API level interfaces
Cees> during a port would completely defeat the purpose of the
Cees> virtual machine, and I for one are very glad that Sun
Cees> wouldn't allow this. If your Alpha port has changed ints and
Cees> longs in API .java files it's just as much Java as
Cees> Microsoft's stuff is...
As long as he doesn't change java files in the platform independent
source code everything should be OK. This is one of the reason why
nobody should use the sun.* classes.
Juergen
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
