home *** CD-ROM | disk | FTP | other *** search
/ Freelog 2 / Freelog002.iso / Linux / Slackware / contrib / java / README-1.1.6v5.txt < prev   
Encoding:
Text File  |  1999-02-08  |  12.4 KB  |  266 lines
  1. README.linux for JDK 1.1.6, Version 5
  2. 09/29/98
  3.  
  4. This is the Blackdown Java-Linux port of JDK 1.1.6 to Linux. 
  5.  
  6. Fixes in this release (from the v4a release) include: 
  7.     - automatically check for incompatible shared libraries, and selectivly
  8.       use the supplied libc and libdl when necessary.
  9.     - fix for bad pararmeter in multicast sockets (SOLINGER)
  10.     - fix for seg-faults in getHostName
  11.     - contributed sound fix
  12.     - fix for disappearing frames when set non-resizable
  13.     - fix for rmiregistry to reflect $DYN_JAVA and $NS_JAVA, as well as
  14.       most of the other executables like appletviewer, serialver, etc.
  15.     - fix for JNI seg-faults for glibc RedHat 5.1 systems
  16.  
  17. SPECIAL NOTE: Starting with 1.1.6v5, we are building with Metro Link's 
  18. "Motif Complete!" product, which was GENEROUSLY DONATED by Metro Link to the
  19. Java-Linux porting team.  This was an amazingly generous gesture from a
  20. commercial company in support of the Linux community.  The Java-Linux porting
  21. team is extremely grateful for Metro Link's contribution to our work!
  22.  
  23. Fixes in this release (from the V2 release) include:
  24.     - Bad or Missing KeyPressed events are fixed (a Sun bug)
  25.     - X11GraphicsdrawString multi-thread corruption fix (a Sun bug)
  26.     - List fix to allow removing item 0
  27.     - getlocalhost fix
  28.     - workaround for a Motif bug that causes seg-faults
  29.     - fix to accept() Kernel Bug (impacts Java Web Server)
  30.          - turn-off by: export JDK_NO_KERNEL_FIX=true
  31.     - fix for non-blocking io on stdin, stderr, stdout (a Sun bug)
  32.     - fix for Finalizer thread caused deadlocks (a Sun bug)
  33.     - fix for JNI problems with egcs -O2 on ppc 
  34.     - fix for frame borders / sizing (a Sun bug)
  35.     - fix for offset menus when using Swing 
  36.     - fix for non-resizable frames (a Sun bug)
  37.     - fix for signal names in java stack/thread dump
  38.     - fix for poor GUI performance with open sockets
  39.     - fix for choice list removes
  40.     - fix for button 1 modifier value
  41.     - improved font.properties.ru
  42.     - fix for set frames non-resizable
  43.     - fix for mwm window manager positioning
  44.     - fix for disappearing frames
  45.  
  46. * This port was developed under Sun's non-commercial license agreement.
  47.  
  48. I (sbb) would like to say a special THANK YOU to all of the people who took the
  49. time to respond to my survey about library versions.  Thanks to your support,
  50. we now have a mechanism that automatically can deal with all kinds of different
  51. versions of libraries on all kinds of different Linux systems.  
  52.  
  53. We hope you enjoy the numerous improvements available in JDK 116.
  54. We will continue to work to both improve the port and fix bugs.
  55.  
  56. Thanks,
  57.  
  58. Your Blackdown Java-Linux Porting Team
  59. (Steve Byrne, Karl Asha, Johan Vos, Chris Seawood, Stephen Wynne, Juergen
  60. Kreileder, Scott Hutinger, Michael Sinz, Stephen Zander, Kevin Hendricks, Brad
  61. Crochet, and all the other people who have contributed bug reports, tested
  62. builds, and helped the port...)
  63.  
  64.  
  65. Reporting bugs
  66. --------------
  67. Please, *Please*, report all bugs to the Java-Linux jitterbug 
  68. bug database at http://www.blackdown.org/java-linux.html.
  69.  
  70. If you do report a bug, it helps to have the following
  71. information:
  72.  
  73. * What Linux distribution (with version) you have (RedHat 5.0, Debian 1.3.1,
  74.   etc.) 
  75. * Which version of the JDK you downloaded (including the "v" number,
  76.   i.e. 1.1.5v7 or whatever)
  77. * Which architecture you downloaded (libc, glibc, powerpc, sparc, etc.)
  78.  
  79. NOTE: This cannot be said enough:
  80.  
  81.    Sending (or making available via web or ftp) a small program that
  82.    demonstrates the bug increases its chance of being diagnosed and fixed
  83.    by two orders of magnitude.  I (and others) can zoom right in on what the
  84.    problem is right away, and that's often more than 1/2 the battle to getting
  85.    things fixed.
  86.    
  87. If the JDK crashes on startup, it's quite helpful to send the output of 
  88.  
  89.    ldconfig -D
  90.  
  91. as this tells us a lot about what libraries you have on your system, and
  92. variations in library versions are often the cause of crashes on startup.
  93.  
  94. NOTE: *IF* you're getting crashes on startup (typically SEGVs), you should try
  95. removing or renaming the libc.so.* and libdl.so.* from the
  96. <java>/lib/i386/green_threads/linuxlibs directory.  If that fixes your problem,
  97. please report it using http://www.blackdown.org/java-linux.html, as this
  98. indicates a failure in the checkVersion script.
  99.  
  100. If you have weird AWT behavior, it helps to know what window manager you are
  101. using, and what version of X.  Typically it doesn't help to know what 
  102. display adapter you have.
  103.  
  104. Sanity testing of your code on Solaris (to see if it breaks there) is always
  105. encouraged, as this often rules out generic JDK bugs (and, heaven forbid, bugs
  106. in your code that you didn't realize you had :-).  Win32 sanity checking is
  107. also good, but since the Linux JDK is derived by modifying the Solaris version,
  108. Win32 is not nearly as representative in most cases.
  109.  
  110. If you can't come up with a small program that reproduces the bug, but it
  111. occurs in some standard application that's downloadable off the web, please
  112. include the URL to get to the application -- this saves us the effort (and
  113. possibly differing results) of finding the program ourselves.  Having exact
  114. instructions about how to reproduce the problem ("Start ICQ via 'java icq'.
  115. Select the destroy->empire menu.  Click the ok button and then click on the
  116. Bill Gates icon. ..." helps a lot).
  117.  
  118. If you get out of memory errors, having information about how much RAM and swap
  119. space you have is quite useful.  It is essential that you verify that you have
  120. as much swap as you think by using the top program.  I've had cases where I was
  121. sure that I had enough swap and was getting out of memory errors, only to find
  122. that I'd forgotten to turn a particular swap file back on.  Also, if you're
  123. invoking the java interpreter with any parameters which affect memory size
  124. (like mx), we need to know that too.
  125.  
  126.  
  127. Missing libXp
  128. --------------
  129.  
  130. The JDK now depends on having the X printing library, libXp installed with the
  131. rest of your X files.  This is part of the most recent X11 distributions, so
  132. you'll need to upgrade (or, if you are daring, you can just extract the
  133. libXp.so* file from the upgrade package for your Linux distribution and 
  134. install it by hand w/o upgrading everything else, although this is unlikely to
  135. work if your X libraries are substantially out oof date)
  136.  
  137.  
  138. Installation
  139. ------------
  140.  
  141. Installation of the Linux JDK is trivial, but you have to get the version of
  142. the JDK that matches your environment.  (If you are not on an x86 based Linux
  143. system, skip to the bottom of this section).  For the x86 processor
  144. family, there are two flavors; the version you get depends on your environment.
  145. The versions are known as "glibc" and "libc5", and reflect the type of C
  146. runtime library that's installed on your machine.  Generally, you should get
  147. the glibc version if your machine is running glibc, but libc5 should work
  148. acceptably as well, if you have a recent (say, past April 1, 1998) version of
  149. the glibc library installed on your machine (RedHat 5.0 by default comes with
  150. an older version of glibc, you need to get the 2.0.7-7 version from RedHat to
  151. win).
  152.  
  153. To discover which kind of system you have, (remember, these instructions 
  154. are for x86 based Linux only):
  155.  
  156.    ls -l /lib/libc.so.*
  157.  
  158. What you are looking for is lines of the form 
  159.  
  160.    /lib/libc.so.<num>
  161.  
  162. If all you see are lines where <num> is 5, then you have libc5.  If you
  163. have a line where <num> is 6, then you have glibc, and you should get the
  164. glibc version.  An addtional check is to look in /lib for libdl.so.<num>: 
  165. if at least one <num> here is 2, then you definitely have a glibc system and
  166. you should get the glibc JDK (although I believe the libc version will also
  167. work for you).
  168.  
  169. Now that that's out of the way, you're asking "Yes, Steve, that's all fine
  170. and dandy, but how do I INSTALL the darn thing???".  It's *real* easy:
  171.  
  172. 1) decide where you want the directory to live.  It can be anywhere in your
  173.    filesystem that supports symbolic links (i.e. not on certain mounted
  174.    Windows filesystems).
  175. 2) unzip and untar into your chosen directory (the system untars itself
  176.    into a subdirectory called "jdk1.1.6"; you can call it whatever you like
  177.    after you untar it -- I call mine "fred").  Want to know a secret?  GNU
  178.    tar, like all winning GNU software, has a cool feature (ok, ok, it has
  179.    more than just one) that few folks seem to know about: you can unzip
  180.    and untar with one tar command!  Just do
  181.  
  182.        tar xvzf jdk1.1.6.tar.gz   # whatever the file is called
  183.  
  184.    the "z" flag says "gunzip before untarring".  The same flag works in
  185.    reverse when tarring.  It's handy, and I think more people ought to
  186.    know about it.
  187. 3) [optional] Put the bin directory of the JDK into your PATH environment
  188.    variable so you can just say "java" instead of "/foo/bar/jdk1.1.6/bin/java"
  189.    when you want to run the interpreter.  For my setup, I'd do (bash shell,
  190.    I'm sure you are bright enough to figure out the csh equivalent):
  191.  
  192.       export PATH=/fred/bin:$PATH # remember, I changed my jdk1.1.6 directory
  193.                   # to be "fred"
  194.  
  195. That's it!  No CLASSPATH, no JAVA_HOME, or other environment variables to set
  196. to get the basic system running.  It can be installed anywhere on your
  197. machine, and it figures out whatever information it needs about where it was
  198. installed automatically when it runs.
  199.    
  200.  
  201.  
  202. Java Virtual Machine variations
  203. -------------------------------
  204.  
  205. There are three versions of the Java interpreter that are shipped with this
  206. release.  The default one depends on having X libraries present on your system,
  207. and has Motif statically linked in (so it does not require Motif to be
  208. installed on your machine).  One other version has no dependency on X, and
  209. starts up much faster, but it cannot be used with X, because there's no way to
  210. have a shared library have a weak reference to another shared library with the
  211. current ld.  The other other version dynamically references Motif, but will use
  212. your version of Motif at runtime instead of the statically bound version.
  213.  
  214. The environment variables NS_JAVA and DYN_JAVA control the behavior.  If it's
  215. NS_JAVA unset, or if it's set to a zero length value, you get the default,
  216. statically linked Java interpreter.  If, however, you have NS_JAVA set to
  217. "true" (or something non-zero length), you'll get the much smaller
  218. nonstatically linked Java interpreter.  You will not be able to run any
  219. AWT based applications with the nonstatically linked java interpreter, so only
  220. set NS_JAVA for non-GUI based applications.  [For the curious: in the
  221. bin/i586/green_threads/ directory, the executables (java for the static
  222. version, and java_ns for the non-static version) are kept.  I make no promises
  223. about keeping the name "java_ns" stable across releases; you should use the
  224. "java" shell script in the jdk1.1.5/bin directory and not invoke the "java"
  225. binary executable directly.]
  226.  
  227. Similarly, if the DYN_JAVA environment variable is set to a non-empty value,
  228. the version of the Java interpreter that uses the Motif shared library on your
  229. machine is selected.  This allows you to use your own local Motif shared
  230. library instead of the statically bound one, so you can experiment with
  231. LessTif, and can take advantages of more recent versions of Motif.
  232.  
  233. The environment variables described above also control the operation of the
  234. "jre" program in the same manner.
  235.  
  236.  
  237. Other issues
  238. ------------
  239.  
  240. Due to basic problems with the JDK 1.1.6 source base from Sun, interactions
  241. with various window managers may be "interesting".  For fvwm, and for CDE
  242. things work fine; for others, odd window placement or problems with sizing
  243. occur.  We believe that we've fixed most of these as of the v5 release.  We
  244. would welcome help in diagnosing and and fixing the problems on the various
  245. window managers.
  246.  
  247. Resizing AWT components has been linked with memory corruption.  As of the
  248. time of this writing, it appears that the corruption (double freeing) is
  249. happening within Motif or Xt.  By default, this release does some 
  250. extra checking for this case and ignores duplicated free operations.  
  251. This has a very small overhead associated with it.  If you're not 
  252. doing AWT related Java programming, and you want to live dangerously, 
  253. set the DO_NOT_CHECK_MEM environment variable to some non-zero-length 
  254. value, and don't complain if the system gets less robust.
  255.  
  256. If you want to turn off memory freeing completely (like it was in Linux JDK
  257. 1.1.3), you can set the DO_NOT_FREE environment variable to some
  258. non-zero-length value.  This most likely won't help the robustness of the JVM,
  259. but if you are having random crashes, it's worth turning this on and seeing
  260. if conditions improve.
  261.  
  262. Enjoy!
  263.  
  264.  
  265.  
  266.