Date: Sun, 20 Jun 1999 19:11:04 -0400 From: Uncle George <gatgul@voicenet.com> To: Jeff Galyan <talisman@anamorphic.com> Cc: java-linux@java.blackdown.org, java@freebsd.org, axp-list@redhat.com Subject: Re: [off-topic] stop bashing! Message-ID: <376D7508.B09894F4@voicenet.com> References: <199906171425.HAA10515@shell.accesscom.com> <376A353F.AD76951F@voicenet.com> <376C3667.4AD168F1@anamorphic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Actually i pay attention quite well, and observe quite well. The example(s) that i have presented to u dont seem to impress u at all. I am very sorry for u. Can I presume that u havent looked at the diffs provided by the java-linux-porting folks. I guess u'd be perplexed with the modest '.java' changes, of which u say could not happen. Before u stated that changing the core api was prohibited, now u state all of '.java' is encompassed in the edict. oh well, we all cant be consistent in our convictions. I am not a company. Nor a commercial entity. I just port the java linux JDK on the Digital Alpha computers. Since u are unable to state what a reasonable fee would be to provide the Alpha linux community with a fairly complete and working JDK, I am also unable to do so. Since Non-commercial licensing for JDK1.2 is curerntly not available, The alpha-linux port for JDK1.2 will cease after my non-commercial license expires. I am also sorry u dont care enough for the other linux communities. I'm sorry u dont understant these porting issues. A 64 bit address just cant (be returned and ) fit into a 32bit java int. gat Sorry about my improper english. i guess that sorta explains why u are unable to comprehend my socratic quiries. BTW, there is really no need to read the community license. I do not forsee myself paying for the JCK, nor do I forsee myself paying for a distribution license Just to be a good linux citizen. Maybe, eventually, u'd realize that Sun's support of the (entire) linux community is at best a form of propaganda, at worst a form of verbal placation. Jeff Galyan wrote: > First off, this business of replacing "you" with "u" is really annoying. > Please use proper English in your posts. > > Secondly, you do NOT have to change the .java files, and such changing > is *strictly prohibited* by Sun in both the commercial and community > source licenses. You are simply *never* to modify the .java files. > Period. > > How you represent an int data type internally to the JVM is your > business. That's platform-dependent code which you are allowed to modify > - NOT .java code. You are ONLY permitted to modify C/C++ source files in > porting Java to other platforms. PERIOD. So, if you want to be able to > store a 64-bit value in a 32-bit int (why you wouldn't use a double or a > long to do that is beyond me, since those data types already have the > capacity for it on all platforms), you would modify the C or C++ header > file that defines the types on your system, so that the internal storage > of ints became 64-bits. You DO NOT do it in the .java source files for > the core Java libraries, which your license specifically prohibits > modifying in ANY way. > > As far as fees go, why are you so concerned about whether Sun charges > your company a fee to distribute your port of Java? How else do you > expect Sun to be able to have any control over cross-platform > compatibility otherwise? You've already said that you modify the sources > to the core Java libraries for your own amusement, so why are you so > insistent that Sun somehow "owes" you a free license to distribute > something that may not even pass the JCK? > > You need to re-read the SCSL again and again and again, as many times as > it takes for you to finally actually understand what it says. Then, if > you still think that Sun owes you a free license to distribute, you can > contact Sun. I'm tired of trying to explain this to you; you're not > paying attention to any of it. > > Uncle George wrote: > > > > 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 > > -- > Jeff Galyan > http://www.anamorphic.com > http://www.sun.com > jeffrey dot galyan at sun dot com > talisman at anamorphic dot com > Sun Certified Java(TM) Programmer > ====================================================================== > Linus Torvalds on Microsoft and software development: > "... if it's a hobby for me and a job for you, why are you doing such a > shoddy job of it?" > > The views expressed herein do not necessarily reflect those of my > employer. > > Sun Microsystems, Inc., has no connection to my involvement with the > Mozilla Organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?376D7508.B09894F4>