On Tue, 29 Jun 1999 22:02:09 -0700 (PDT), Gerald wrote: > >Hi all. > >Alright. In order to gain a good understand of the issues that have >arisen during the port of Java2 on Linux, I have read over the past >messages regarding technical difficulties in the port. There seem to >be several main ones: > >- Linux threads are screwy and the Java2 source (J2S) uses Solaris threads > rather than pthreads. The two don't mix well. > >- J2S is written for 64-bit Solaris. > >- J2S uses system calls that are incompatible with Linux. > >- Memory management is "tough to port". > >- AWT is also somehow hard to port. > > >The first point makes a lot of sense. > >I don't know enough to accept the second point. Yes Solaris 7 is a >"64-bit OS", even though it might run on a 32-bit processor. But what >about 2.6 and 2.5? Are those 64-bit OSs too? Well, this point is not really an issue - that is, the 64-bit-ness of Solaris is not the problem. Solaris in general is. >For the third point I can only interpret it to mean that J2S does not >use POSIX calls but some non-standard ones for if they use POSIX >calls, they must be the same on Linux if they are implemented. So, you actually believe that POSIX calls means it will work anywhere? For most simple things that is true. But once you push the edges and do either pthreads or green threads work (poll/select/signals/etc) you get into some strange behaviors. Some of this is C-library related (glibc vs what Sun has) and some of this is OS related (Linux vs Solaris) >The fourth point I can't understand at all. It's standard C. C >provides only the malloc/free pair for dynamic memory. I find it hard >to believe that there could be any sort of shared memory usage. I >suppose there could be some use of thread local storage. Of all these, >I can only see possible problems with the latter. Everything else >should just "compile". What's the problem with memory management? Well, the problem is memory management within the JVM. GC is tricky to start with. Add in not-quite-perfect threading constructs (by perfect, I mean a match to what a JVM neads) and you get rather tricky problems of having the GC run correctly and not cause memory corruption within the JVM and not run into deadlocks with respect to the threads. This really goes back to the threading model (for the most part) and the internal allocation model (sub-allocations within the JVM memory pool) >The fifth one I also can't understand. Isn't Java2 built on top of >Motif/X? Aren't X and Motif calls "standardized"? Well, a standard is great. There are so many of them :-) X is X. However, interactions with the window manager (which is what lets you move/size/arrange your windows) are very tricky - especially when doing a toolkit type application (such as Java/AWT) since you have a defined set of calls that do certain things (open a non-sizeable window, for example) and yet some window managers want hints or behaviors that are different (you have to say it is non-sizeable before opening or you have to say so after or if you say so after the window goes away or...) It becomes a game of side-effects. The AWT (and Swing) API provides a set of behaviors that then have to be mapped to the many various window managers and their side-effects. Just doing the testing alone is a major undertaking. (How many of you have tried to run multiple different window managers with all of their various configuration possibilities?) >If anyone can shed some light, it would be great. Please CC a copy to >[EMAIL PROTECTED] directly. I've been trying to subscribe to the >mailing list and I get these success responses from the mailing list >program but I don't get any messages from the list itself. Will do. Like I said in the past on this list, the devil is in the details. Getting the rough cut running was some work. However, you all should know that the last 5% of a project takes 90+% of the effort. Polishing and making stable are rather tricky and very difficult for something as complex as the JVM. Michael Sinz -- Director of Research & Development, NextBus Inc. mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com My place on the web ---> http://www.users.fast.net/~michael_sinz ---------------------------------------------------------------------- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
