Jeff Galyan wrote:
> Actually, you don't need to modify the .java files, and in fact, modifying the .java
>files is strictly prohibited in the license (as such modifications could potentially
>be misconstrued by the licensee as permission to change the apis). The license does
>permit personal use of your own port. If you are a company doing the port for your
>company's use, rather than you as an individual porting for your own personal use,
>then you are correct in your interpretation of the license. You would be required to
>pass the JCK and pay a license fee, etc. As an individual, you would not have to do
>this unless you intended to release your port over the Internet, on CDROM, or
>otherwise "distribute" it.
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.
There are many ways in which u can program in order to not change the '.java'
files. There are also many ways u can program so u dont have to change the
'.c'/'c++'/'.s' files. To an extreme, u dont even have to do a port, just build an
i86 emulator, or a solaris emulator.
Cant imagine why anyone would attempt to bother to port to a foreign machine, just so
u can use it at home. Probably along the same reasons as why one would write a book,
and only publish it just for yourself, for ur own personal reading.
>
>
> Now, I'm not a lawyer, nor am I in charge of licenses for Sun, but I'm sure they
>would be willing to work out a fair license fee for an individual who wanted to
>distribute their port. You would still be required to pass the JCK before you could
>distribute, though.
I believe thats what they do now. Jck not so free, and distribution not so free, as i
stated twice before. What would a fair license fee be, if u dont mind me asking, for
my Linux/Redhat/Alpha of the Sun JDK port be ? And what if it become an impossible
port because the JCK is skewed towards 32bit excentricity's ( as per JCK, u may not
change it at all )
>
>
> Back to modifying the .java files - the only modifications you should ever need to
>make (even for the .java files that call native methods) is in the .c, .cpp and .s
>(asm) files. The header files for the native VM code is where you would want to make
>your changes for internal type representation (i.e., is a long a 64-bit value, or is
>an int a 64-bit value kinds of things). Any mapping between native types and Java
>types is handled by jni_md.h for purposes of JNI. If you can think of good reasons
>why you would absolutely have to change the .java files, then you may want to bring
>that up to Sun. I personally can't think of any reason to change the .java files at
>all unless you were adding new methods or otherwise changing the apis - which results
>in a version of the Java core apis which depends on one specific port of the VM.
>Again, that is strictly prohibited by the license.
Say take the address of an X window, X gives back a long/64bit address/reference
value. u pass it back to '.java' . ur unmodifiable '.java' expects an int which is 32
bits. This mapping is for 'like' types. Getting truncated longs, is just a part of
java life on an alpha.
There is no reason to change the API's, if they are not system/os specific. Having
to change/alter the API's on a per OS would also violate the notion of write once, run
everywhere concept. There is a set of win32 '.java" files to interface to the win32
native functions. There is also a set of solaris "unix" '.java' files to interface to
the solaris unix native functions. Porting would mean altering the solaris unix
'.java' files to be linux unix '.java' files, and the same for os specific native
functions.
My heart also goes out to ibm's as400 porting folks who have 48 byte ( i thinks
its bytes ) addresses. I reported the problems of 64bit addresses to the bug list, as
well as this one that IBM has submitted.
>
>
> So, the "free for personal use" hasn't been thrown out the window.
I believe it effectively has been thrown out the window. Ur not allowed to share
(distribute ) ur personal efforts with others for personal uses. With the
Non-commercial licence, one was able to 'restrictivly' distribute ur efforts. This is
still true with JDK1.1.x, but no longer with JDK 1.2.x.
> It's just that the language of the license is a little obtuse (but lawyers tend to
>write that way
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
