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, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
