Re: Expanding arrays
On Tue, 08 Sep 1998 17:59:26 +0200, Maarten van Leunen wrote:
>Howdie,
>
>Is there a way to expand arrays. Like, I want to put a unknown number of
>strings in an array.
>
>And then "return" the array of Strings in the Method.
>
>I read one string, and wish to add it to the array without having to
>define the amount of Strings in the array previously.
Generally I tend to use the java.util.Vector class if I really can not
know the size of the array before hand. Then, if I need to make an
array from it, I just use the copyInto() method after building the
array of the right type and size. For example:
java.util.Vector v=new java.util.Vector();
/// add all sorts of String object to the vector
String[] result=new String[v.size()];
v.copyInto(result);
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
Re: ddd, gdb, jdb and java: debuging on linux
On Wed, 9 Sep 1998 12:10:23 -0700 (PDT), Luiz Otavio L. Zorzella wrote: >Hi, > >I've been missing a good debuger for java on linux for quite some >time. It was then that I found this on the ddd >(http://www.cs.tu-bs.de/softech/ddd/) manual, under "News": I don't know if it is "good" but the IBM Alphaworks debugger known as JIKES DEBUGGER works rather well (IMHO) for most JAVA programs. It is written in 100% "pure" Java so it runs if you Java can do AWT correctly. The nice thing is that it comes with source code too. Check out the Alphaworks web site at http://www.alphaworks.ibm.com/formula (I have modified the source to have line numbers in the listing window. Check out the diffs I posted to the JIKES DEBUGGER discussion list) And, yes, it shows variables and objects and threads and... 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
Re: Java on Linux... bug in InetAddress ??? please help!
On Thu, 10 Sep 1998 13:34:08 -0700, Masuda, Bond wrote: >Hello, > >I am having trouble getting reverse DNS lookups to work on Linux. >Following is a snip of the code... this works on Windows 95, Windows NT, >but not on Linux. The problem is that the getHostName method returns the >ipString instead of the hostname... i.e., it returns something like >10.2.6.15 instead of whatever.home.edu. The JDK version seems to not >matter in this particular case... so I don't believe that is an issue. I >am wondering if this might be a bug in the port of Java to linux. First - have you tried that address in nslookup? Just type: nslookup 10.2.6.15 If this does not return the name of the host then the problem is that you either do not have the DNS setup or it is set up wrong or the host really does not have a name. [...] >I would appreciate any help on this issue. Thanks in advance. I wish I could help you more but on my machine your address does not work but address on the net, such as 204.146.18.33 do work. (That should return something like www.ibm.com if I remember correctly...) 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
RE: Java on Linux... bug in InetAddress ??? please help!
On Thu, 10 Sep 1998 14:44:50 -0700, Masuda, Bond wrote:
>Hello Michael,
>
>Thank you for replying so quickly..
>
>The particular address in my message was a bogus address.. I was
>assuming that would be clear when I mentioned the whatever.home.edu. In
>anycase, yes, my DNS is setup properly, as 'nslookup' and 'host' both
>return a hostname and address... in particular,
>
>for IP = 206.19.60.13 I get
>hostname = chinook.tenthmtn.com
>
>but the Java program in my previous message does not work. I believe it
>is capable of doing the reverse lookup... as is my understanding...
>instantiation of the InetAddress object fails if reverse lookup is to
>fail. However, my program continues to execute to the point where it
>calls the getHostName() method. So, to me that means that the object was
>successfully instantiated... which leads me to conclude that reverse
>lookup was successful. However, the getHostName method returns the ip
>address in string representation instead of the hostname. It seems to me
>that the InetAddress object is instantiated, the ipString accepted, the
>reverse lookup successful, but the hostname is not stored in
>InetAddress.
Here is what I ran on my machine: (Linux 2.0.35 with JDK 1.1.6)
class test
{
public static void main(String[] args) throws Throwable
{
System.out.println(java.net.InetAddress.getByName(args[0]));
}
}
Running it with:
java test 204.146.18.33
produces:
www.ibm.com/204.146.18.33
>In case this matters, I am on Redhat 5.1 Linux kernel 2.0.35. I've used
>both JDK 1.0.2 and JDK 1.1.5.
>
>You mention that you are able to do reverse lookup on your machine. What
>platform are you on? And did you use the code in my previous message or
>some other Java program? My java program DOES work on windows 95 and
>Windows NT platforms... it DOESN'T WORK ONLY ON Linux.
I have also run your program (with the addition of an import statement
that was not in your original posting) and it produced the correct answer:
java revDNS 204.146.18.33
Hostname is :www.ibm.com
Again, this is on Linux 2.0.35 kernel (x86 CPU) on my small network here.
I have also run both your program and my little test program and they
both produce the same results under Windows using the Sun 1.1.6 JDK.
(And I assume it is the same JDK you are using)
The same result also happens on my Linux 2.0.35 (Alpha 21164) system, but
that was running a JDK 1.1.5 variant.
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
Re: Well done
On Sat, 12 Sep 1998 16:00:34 -0700, James Howe wrote: >P.S. Thanks alot guys !! I am sure the whole team would like to say "You are welcome." 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
Re: To read from a port
On Sun, 13 Sep 1998 20:56:35 +0200, Carlos Garcia wrote: >Hi. There is somebody who can tell me how to get information from a >Ethernet card on my PC system? Of course, I know the protocol of the outward >system. >From the ethernet card? Or do you want to read from a TCP/IP (TCP or UDP) data stream? Directly from the card is non-trivial in Java (as in you will need to do native methods and maybe even more complex code to deal with the green threads) However, do networked (Sockets and UDP datagrams) that is all supported in Java at the pure-Java level. Check on the java.net package, and specifically the java.net.Socket and java.net.DatagramSocket 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
Re: Reading /dev/cua? or /dev/ttyS?
On Sun, 13 Sep 1998 17:46:39 -0300, Fernando Soares Barrocal wrote: > >Brazilian Hello ! > >I have a CodeBar Reader attached at /dev/cua1 and I can read from it from >some applications, opening the "/dev/cua1" file and reading from it ! > >There is any way to do this with java ? Well, if you do not need to do anything other than opening and read/write operations, just open that as a file in Java. Then do the byte I/O or stream I/O to/from it. However, controlling the data rate and other serial port parameters will need to be done with either an external program/native methods or the new Java Serial (RXTX) extensions. (I have not played with those as they came out well after I had needed to do serial port stuff...) What I did was to use stty and then to run the Java code with the /dev/cua1 name for the file. (This is not very cross platform other than within Unix worlds and even then stty has some strange behaviors) 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
Re: java-linux, reliabilety
On Wed, 16 Sep 1998 13:57:27 -0700, Lukas Hazlehurst wrote: > >>> Is java on linux reliable enough to run on a box by itself for a >>> considerable period of time, or would C be more appropriate ? >> >>I have had NO PROBLEMS with Linux Java for server software. I've had >>some problems with AWT-related stuff, but that's... well, the Java >>burden at this point in time. > >That was my suspicion, avoiding a pretty UI would make for a more reliable >service. The UI would be provided via the network from another machine so >it wouldn't matter if that fell over. Actually, I would think that the UI would be generated at the client machine anyway. >>Also, for non-AWT apps, you can compile with TowerJ to full-blown native >>code. > > >This would be a definite plus. Could i assume that as the compiled code is >not running under a jvm etc it would be more reliable ? I would not say that. I can not talk about TowerJ but there are some benefits to running within the JVM. Now, you are limited to the quality of the JVM but it has been run by and used by many people on many platforms and so much of the core is very well tested. The code generator for any compiler can easily have bugs in it just like the JVM can. However, the number of cases the code generator may have to deal with could be far greater (especially if it does complex optimizations). So, while the JVM could be the weekest link in a server-side Java program, compiling to native code does not mean that it will be more reliable, just that the types of problems and the way they manifest themselves may change (and the ease and manner in which they are tracked down.) 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
Re: Problem with getting JDK's to work
On Wed, 16 Sep 1998 09:50:49 -0400, Molenda, Mark P wrote: >I have followed the checks listed on the web page for loading the jdk and >everything looks great. >The gzip tar file unloads and I add /usr1/jdk1.1.6/lib/classes.zip to my >CLASSPATH and /usr1/jdk1.1.6/bin >to my PATH. When I try to compile a hello world program with javac it blows >up with a core dump. > >I have RedHat 5.0 and glibc ( at least I think I do from the checks I >performed in the README's). If you have RedHat 5.0 installed, make sure that you do not have the kaffe JVM installed. (Or have moved/renamed/etc the files and settings it had set up) >Anyone having a similar problem? I tried this again with jdk1.1.5 v7 same >problem, I need to get this up and running ASAP. -Mark I have seen this problem on other systems and it was always that the javac was from the Kaffe install. (So I guess and hope that is what your problem is.) BTW - Maybe we should add to the FAQ a stronger statement about the Kaffe RPMs from RedHat? 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
Re: Out of memory - Garbage collector
On Wed, 26 Aug 1998 09:59:37 +0100, [EMAIL PROTECTED] wrote: >Help > >I believe there may be a problem with the garbage collector as it >doesn't seem to release all the memory when it is not reference > >(But I could be wrong) > >I have list my version, m/c spec and a simple program > >Many thanks for any help in advance > >Daividm > > >JDK_Version: jdk 1.1.6v2 > JDK_Arch: i386 (x86) > Linux_Dist: Slackware > Linux_Dist_Ver: 2.0.0 > Libc_Ver: 1.8.2 > Ld_Ver: 0.1.2 > Dyn_Java: no > > > I have a very small program that reads the entries in a zip file. The >file is4.9MB > in size and contains 5302 entries. The program uses both methods for >reading a zip file > nextentry and enumeration. Under the enumeration method it runs out >of memory. > I have tried the program under Borland JBuilder (1 & 2) and (canyou >believe it) > > microsoft J++ and they work fine. > > I have 128MB of real memory and 128MB of swap, and the program still >runs out ofmemory.I have even force 'gc' but the program still >fails. Something must be wrong with the manangement of the memory. > > That means each entry uses more than 48K. That can't be right. >Considering I ran the JBuilder on 32MB memory Most likely you need to change the default maximum heap size. It is set to a relatively small number. This same behavior happens under the JDK from Sun on Windows too. Try, for example, to use the -mx32m which states that the JVM can use up to 32 meg of memory. Also, the Sun implementation of the GC does not currently compact memory (even though it has indirect pointers) This is not a big issue, but in tight spaces it can make a difference. Anyway, try running your code with -mx32m and see what happens. 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
re: packages
On Wed, 26 Aug 1998 11:33:42 -0300 (ADT), Kenny Freeman wrote:
>
>> I personally am rather against most import statements as they can
>> only help to confuse the issue of what you are looking at. Even worse
>> is import of a whole package - since then you do not even see in the
>> code all of the possible class names that just got defined... However,
>> if used very rarely and only when really justified, they can help
>> reduce the typing needed and not reduce the maintainability of the code.
>>
>> Sorry about that, but I have had to fix code where the top of the
>> file had import .*; import .*; etc. Basically importing every
>> package in the whole product - almost 30 lines of these - and then
>> trying to figure out what the DataTrack class is and which one it used -
>> since there was a different one in three different packages...
>>
>> BTW - This was only one person who did this in his souce - and his
>> code was usually the code we had to fix. But he was a contractor and
>> did not follow our coding standards.
>
>Well, that is still no real argument against packages. However the
>.whatever packages were generated, there should have been a way to
>make things a bit less cryptic. I couldn't imagine not being able to use
>the import statement. Things like:
> tmp = new ken.encryption.RSA.RSAMessageDigest()
> tmp2 = new ken.util.file.FileReader("blah.txt")
>get on my nerves pretty quick. People who make bad names for packages like
> should keep there code to themselves. Well, thats my $ 0.02
No, it names were not x. I just am not in a position to explain the
names. The names were nice, but the imports where all of the type:
import ORG.junk.foo.bar.*;
import ORG.junk.blah.foo.*;
import ORG.junk.blah.bar.*;
etc. for about 30 lines...
So, the code was importing classes that it never needed or used,
it was importing conflicting classes, and it was very hard to maintain.
(All of his source files started with the same set of lines but none
of them used all of the classes...)
I would have liked it if the import statement could *not* have "*"
and thus you would have to:
import ORG.junk.foo.bar.TimeTrack;
etc.
This way you would always have a true listing of what you have imported
and from where. (The "*" just is a problem.)
Personally, I never use that. I have an editor that makes life easier
and I can type rather quickly, so I have fully qualified names on all
classes that are outside of the package that the source is in. It also
means that when I read the code I can see instantly what package the class
came from.)
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
re: packages
On Wed, 26 Aug 1998 12:02:55 -0300 (ADT), Kenny Freeman wrote: >I see your point now. I agree with you when you say doing this is a bad >thing: > import foo.bar.*; > import foo2.bar2.*; >This does cause problems and is not nec. a good thing to do - but I was >generally thinking allong the lines of importing one or two utility >classes to save me the trouble of typing out the really long names. >Importing * is a bit lazy, and in larger classes really does make it >difficult to keep things organized. Like you said, if you don't import *, >but list every class like: >import ken.encryption.RSA.RSAMessageDigest; >import ken.util.FileReader; >it makes it more obvious what classes are used compared to the *, where >you really have to go through the code and find out. Not only that, but when you go through the code and see a class name, how can you know where it came from: SomeClass item=new SomeClass(a,x,t); With import statements that have "*", where in the world did this come from? And don't ask me to name my class "UtilTextFoobar" when it is already in the "ORG.sinz.util.text" package... 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
Re: OS/2 JVM three times faster than others!?
On Thu, 17 Sep 1998 05:29:19 +, Dan Kegel wrote: >Dan Kegel wrote: >> >> Check out >> http://www.infoworld.com/cgi-bin/displayTC.pl?/980914analysis.htm >> >> It shows OS/2's latest JVM to be *three times* faster than >> any other. (They haven't tried Blackdown's v4a yet; they only >> used v2.) > >I should mention - the test was run on dual-processor machines >(except for Linux, which they couldn't get running in SMP mode). >So perhaps OS/2's JVM is only 1.5x times faster on a single >processor, and has much better native threading than the others. Well, the Windows NT test is also done on the same dual-processor system and it too shows to be 1/3 as fast as the OS/2 version. The thing is the OS/2 has a *very good* threading model. It works very well. And OS/2 applications and tools generally make use of this and depend on this since it is almost impossible to write a reasonable GUI application without at least 2 threads due to the way the input queue works. Having over 100 active threads in the system is not uncommon. (The good threading model is also why OS/2 tends to be a very good file server in larger networks - it handles user connections rather well...) I hope they get a chance to run the V4 port of the JDK since the socket fix has a *major* impact on any programs that tend to wait on a socket. (Which generally is done a lot in client/server code) 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
Re: Problem spawning process with "several words"
On Wed, 16 Sep 1998 22:41:34 +0800, Jon Priddey wrote:
>Any help much appreciated:
>
>I've got some code which integrates with RCS.
>It creates a Process with:
>Runtime.getRuntime().exec("ci -m\"blah blah blah\" filename",env);
>
>where "blah blah blah" is the description of the check-in.
>Enclosed in double quotes (") to group the words as a single parameter.
>
>My 116v2 seems to have problems with this, though it works fine on a Sun
>JDK.
>
>ci gets the args as:
>1/ -m"blah
>2/ blah
>3/ blah"
>4/ filename.
I think you have the quotes in the wrong spot. On the command line
you need to type:
ci "-mblah blah blah" foo.c
Doing
ci -m"blah blah blah" foo.c
does not work since the " is in the middle of an argument word. (Standard
shell parsing, which is what happens when you use the exec() method.
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
Re: Help of Setting up java for Linux
On Thu, 17 Sep 1998 14:03:25 +0800, Ong Choon Seng wrote: >Hi, > >I have install the rpm package (jdk-sbb-1.1.6-4a.glibc.i386.rpm) from redhat's ftp on >my rh5.1 system but have problem running classes. > >I am very now to this environment so any help would be greatly appreciated. > >I know that you have to setup the classpath option but how do I do that? > >I was trying to run the HelloWorld class with :- >java -classpath \home\java HelloWorld Well, unless the JAVA classes are in \home\java this will most likely fail as you have listed: >but encounter the following error :- >Unable to initialize threads : cannot find class java/lang/Thread Most likely you should not need to set up CLASSPATH using the -classpath option. The problem with that option (or feature) is that it *replaces* the classpath environment variable. Not only that, the JAVA Wrapper does not automatically add the Java system classes to the classpath in that case. (It does add them to the classpath environment variable) BTW - I think that Sun has caused the largest harm to Java due to the complexities and irregularities of the setting of CLASSPATH. Yes, there is lots of power there, but there is no excuse for the Java startup to not always add on the location of the system classes. If someone is replacing them, not search would get that far but most users do need them so having to put them into the classpath has become a major pain and hassle for the users of Java. 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
Re: OS/2 JVM three times faster than others!?
On Thu, 17 Sep 1998 02:08:00 +, Dan Kegel wrote: >Check out >http://www.infoworld.com/cgi-bin/displayTC.pl?/980914analysis.htm > >It shows OS/2's latest JVM to be *three times* faster than >any other. (They haven't tried Blackdown's v4a yet; they only >used v2.) > >Perhaps the Blackdown team will be interested in getting >a copy of the benchmark code they used; it looked easier >to run than the Volanomark. We will see. I have EMailed the author and asked if we could get a copy of the test programs. BTW - OS/2 has a very nice threading system and a rather solid network stack and these are the real reasons the stuff ran so much faster. Why do I know this? Well, friends at IBM tell me that the JVM they made for OS/2 and NT are almost the exact same code (plus/minus the technical differences between platforms) That includes the JIT and the core JVM, both of which are very much the same since x86 code generation is the same on either platform. 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
Re: javac problem
On Thu, 17 Sep 1998 09:45:55 +0100, Matt Zagni wrote: >Mats, > >I have the same problem when I try to install netbeans. >you mentioned that to over come this problem I should > >> This is an old one delete (or rename) the libc.so* and /or libdl.so* > >Are these major lib's and what other applications will the above >impact ? Make sure you delete them from inside the JDK directory tree and not the public versions! See the Blackdown FAQ for details. 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
Re: RXTX, SerialImp.c
On Mon, 21 Sep 1998 08:12:26 -0700, Dan Kegel wrote: >[EMAIL PROTECTED] wrote: >> The major thing I have done with ioctls() is to do a nonblocking read >> FIONREAD which also returns the number of bytes available for reading. I >> could not find a similar function using termios. I can't think of a way >> to avoid this. (I would actually like to go even lower and use >> interrupts for notification as the polling is wasteful of resources.) > >Would select() be applicable? Depends on the filehandle. Serial file handles on some UNIX systems sometimes block even in non-blocking mode. >(This is the greatest functions for doing I/O >efficiently; you can sleep the current thread >until any of a number of file descriptors has >i/o ready for you. Java suffers greatly from >its absence. It's the key to implementing >truly monsterously high performance web >servers and the like, where the number of >clients far exceeds the number of available >threads.) Actually, I feel that select(), while powerfull, is a great way to work around the fact that there are thread limits or that, for a long time, UNIX systems did not have threads. The Java model is to have threads be very easy and accessable and, if used in that form, can simplify the cases of many clients. Operating systems with no real thread limit have shown how this can be a major benefit in simplifying and optimizing such code. 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
Re: CLASSPATH problem
On Mon, 21 Sep 1998 15:48:51 -0500, Larry Bottorff wrote: >I just downloaded jdk1_1_6-v2-glibc_tar.gz and set it up in >/usr/lib/jdk1.1.6. I'm using Red Hat 5.1 on Intel and I had previously >updated glibc with glibc-2_0_7-19. I also set up my path to >/usr/lib/jdk1.1.6/bin. When I try to compile: javac hello.java, I get >the error message CLASSPATH is not set! All right, but the README.linux >says I shouldn't have to set a CLASSPATH. However, the README seems to >apply to Version 4a, and I downloaded from /v2 (see file name >above). I then tried to add a CLASSPATH variable to my bash shell with >export CLASSPATH=.:/usr/lib/jdk1.1.6/lib/classes.zip, and I get "No >library path set", even when echo $CLASSPATH gives me back a good >string. What am I missing? . . . Darn this is getting "old" (not your fault Larry) Check "which javac" and you may find that it is in /usr/bin and if you look at the file it will be trying to run kaffe. The JDK (both from Sun and our port of it) does not need the CLASSPATH set to find its own classes (only for external packages that you may had added, such as swing or 3rd party things) Anyway, remove javac and a whole bunch of other java* files in /usr/bin since they are not the ones you want to use. It may be best to just remove kaffe from the installed packages and this should remove the javac/javadoc/javah/etc files that have been placed there by kaffe's RPM. We really should put up a major line/paragraph in the install document about the problems with RedHat and the kaffe RPM. 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
Re: Swing: Can't find class ClassName
On Tue, 22 Sep 1998 14:16:39 -0700, William Tchen wrote:
>Thanks for your suggestion, but I think the CLASSPATH variable on my system
>is properly set (which includes
>swingall.jar), otherwise I can't compile a file that refer to Swing classes.
>My CLASSPATH is:
>
>CLASSPATH=.:/JAVA/jdk1.1.6/lib/classes.zip:/JAVA/swing-1.0.3/swingall.jar
I figured the classpath was correct given that it compiles...
> I include the example file that I want to compile here:
>
> package JFCBook.Chapter2;
>
>import com.sun.java.swing.*;
>
>public class BasicFrame {
>public static void main(String[] args) {
>JFrame f = new JFrame("Simple Frame");
>f.setSize(250, 200);
>f.setVisible(true);
>}
>}
>
>When I compile this file, there is no error message. But when I run it using
>'java BasicFrame'
>it says 'Can't find class BasicFrame'. Have you ever experience this before?
>Thanks for time.
Well, the problem is that the class is not "BasicFrame"
but "JFCBook.Chapter2.BasicFrame"
If you remove the package statement or if you use the full class name
when trying to run the class you will be fine.
The java command needs the full class name since ther is no "import"
for the class name used to run from the command line - import is only
a compile-time typing shortcut and not a run-time item. Classes that
are not in a specific package are in the "outer" package - as in nothing
to prefix the name.
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
Re: JDK & native threads
non-blocking file descriptors. This was done due to a problem outside the control of the Java group (the shell would get confused) but this has been addressed in Solaris (and is not an issue in Linux) Plus, with native threads this is (or should not be) an issue. Also native threads still have issues with blocking calls and monitor locks. 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
Re: JDK & native threads
On Wed, 23 Sep 1998 09:29:19 -0400 (EDT), [EMAIL PROTECTED] wrote: > >On Tue, 22 Sep 1998, Gerald Gutierrez wrote: > >> I'm starting to pull out my hair from the fact that the current JDK is >> based on user threads. I can't call anything that can potentially block, >> because everything will block. >> > >Are you saying that if my application has 5 threads running, and >one of them blocks on a blocking method (i.e., BufferedReader.readLine() >on a client socket) then the 4 other threads are blocking (not running) >also during this time?? No... The JVM and the green threads wrappers make all of this work with the magic of select() and poll() and other such "wonderful" things. The problem comes when you use native methods and the native code blocks on something (either because it is not using green threads wrappers or because the blocking call is not part of the green threads wrapper) Then you will block. (Ok, so on older versions, reads from STDIN/STDOUT/STDERR were a problem but this has been addressed) 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
Re: JDK & native threads
On Wed, 23 Sep 1998 09:42:48 -0700, Gerald Gutierrez wrote: >> (Ok, so on older versions, reads from STDIN/STDOUT/STDERR were a problem >> but this has been addressed) >> > > >Are you sure ? The following seems to indicate that at least >STDIN will block everything. Yes, I am sure - you need to use the Linux port V4a to solve this. STDIN/STDOUT/STDERR were blocking file descriptors in previous ports. On Solaris they still are (until JDK 1.2 unless they do a JDK 1.1.7 maybe?) If you check the Java-Linux bug database (jitterbug) you will see that I was the one to report this and that Kevin was the one who did most of the work to address this. 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
Re: Need help with initial Java setup
On Sun, 27 Sep 1998 16:24:46 +0200, Stefan Huebner wrote: >Hello ! > >I was just trying to install Java for the first time on my Linux Box, >but I m not able to use appletviewer, or to view my class-files from >the command-prompt: > >Linux 2.0.35 with Java-binaries support >glibc 2.0.7-19 > >I installed jdk 1.1.6 to /usr/local/java and created the symlinks >/usr/bin/java -> /usr/local/java/bin/java and >/usr/bin/appletviewer -> /usr/local/java/bin/appletviewer You may find that using SymLinks will cause some problems - depending on many other things. It is much better to put /usr/local/java/bin into your path an make sure that the java/etc are *not* in /usr/bin >My $CLASSPATH is set to >".:/usr/local/java/lib:/usr/local/netscape/java/classes/java40.jar" This can also be a problem. The Netscape class files are for when running the Netscape JVM. Netscape should never need you to define a classpath at all (do not set CLASSPATH when running netscape and it will work correctly) I generally try not to set CLASSPATH or to set it to something as simple as ".:./obj" (since I tend to compile my class files into a different directory tree) Silly details: The Java wrapper script will automatically try to find the classes.zip file (or directory or jar or a whole list of possible places) before it starts the JVM. However, it does this by using the $0 (command name) to find it. With symlinks the $0 name points to /usr/bin/java (for example) and this is not where the rest of the Java files are. You can still use the symlinks if you also set up a JAVA_HOME to point to where the Java files are installed. This normally should not be needed if you simply put the java/bin directory into your path. Netscape does equally complex stuff. It tries to find itself (and there is a setting but I forgot what it was) and once it does, it does even more by automatically adding *all* jar files in the directory where it stores its jar files. This is so that plug-in and add-on java things can be done without the CLASSPATH setting. Note that there actually is a problem with some versions of Netscape where if you have CLASSPATH defined at all when Netscape runs it does not try to find its own Java directories and thus will fail to run Java. The best thing to do is not to have CLASSPATH defined when starting Netscape. All of this is, of course, for the "normal" usage. Advanced users are welcome to "shoot them selves in the foot" ;^) Seriously, this is one of the worst parts about Java. But it also sometimes is "needed" in order to try something or do something tricky. I just wish it was not abused so many times for things that really did not need to have special settings. 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
Re: fast multiple object creation ... can it be done!
On Mon, 28 Sep 1998 21:34:24 +0200 (CEST), B. Craig Taverner wrote: >I'm dealing with a performance issue in java where it appears that >performance is noticably affected by the fact that many (thousands) of >relatively small objects need to be created very quickly (multiple small >memory allocations). From my C/C++ background I would have considered >solving this problem by allocating the objects in reasonable sized blocks >of objects (single alloc for many objects to minimize system calls). >Individual objects could still be accessed (perhaps >calloc/sizeof/typecast) and could then continue to be referenced in the >normal way (hashtables, vectors, trees, etc). This is really part of what a "better" JVM would do for you. In most cases, it really should be the domain of the JVM to solve some of these optimization issues. >However, I do not see any obvious way to achieve this in java. You cannot >simply allocate a chunk of memory (you also cannot know the object size, >or typecaste the memory to the object type). If I allocate an array of >objects, I'm simply allocating an array object that contains references to >the correct object type, but does not actually contain those objects, and >they still need to be created. Well, there is no direct way to do this. However, some things that can be done is to have static methods be used to get instances of objects and keep the constructor private. Then the objects can make their own tracking of usage and reuse themselves rather than always recreating themselves. (These are generally known as object pools) Sun even talked about how these can help with objects that are expensive to create, such as threads. >Does anyone know of a good way to solve this problem? Any suggestions >around the issue of object creation performance are welcome. Well, other than doing work on a JVM to make better allocation systems and stuff like that, the only choice is doing the pooling of objects within your own Java code but this can complicate things and make the code that much harder to understand and maintain. A JVM could, for example, notice that you are reusing certain objects and implement the pools "automatically" for you and thus provide the benefit for all java code without adding complexity to the Java code. (Just to the JVM, but that is ok since it is somewhat reused :-) 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
Re: JDK 1.2
On Thu, 01 Oct 1998 00:57:23 +0200, Flag wrote: >Maybe a stupid question, > >Is there the jdk 1.2 for Linux?!?!?!? Not a stupid question - but one that we can only say that the source code licenses are not available from Sun until the product ships. We have, thus, not even seen the JDK 1.2 source and have no idea as to how much work it would be to do the port. We hope to get the code as soon as possible but from what Sun has said about the 1.2 changes, it could be a lot of work (and thus time) to do the Linux port. (We hope it will not be too much, but...) 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
Re: java.lang.reflect.Method invoke bug?
On Thu, 01 Oct 1998 19:58:11 -0400, Andrew V. Shuvalov wrote:
>Hi!
>
> I have continous problems trying to call "invoke" in
>java.lang.reflect.Method class. I spend several hours and have the
>impression that it is not implemented. I use
>redhat-5.1 and
>jdk-1.1.6sn-1.1glibc package
>
>1) Did somebody ever happens to run "invoke"?
>2) What is the most stable and/or complete Java for Linux distribution?
>( I see many choices on ftp.redhat.com )
I use Invoke in my server support classes all the time.
This has worked in the Linux JDK since 1.1.5 at least (I think
that was when this code went into service on a Linux box)
This code is currently running in all JDK 1.1.6 versions on Linux.
(Including the current test of the v5 changes)
Here is an example of the code:
/**
* This method is called to process the command that this
* entry is for. It uses reflection to find the command
* and process it in the handler object.
*
* @param context The command context that the command handler will need.
*/
public void HandleCommand(CommandContext context)
{
if (Method == null)
{
// We assume that this is to be handled by the
// context itself...
context.nullMethod();
}
else
{
CommandProcessor handler=context.getProcessor();
// First, get the class of the handler object...
java.lang.Class handlerClass=handler.getClass();
// Just in case the method is not there...
try
{
// Now, get the method for this command...
java.lang.reflect.Method handlerMethod;
handlerMethod=handlerClass.getMethod(Method,HandlerArgTypes);
// Put together the argument array...
Object[] args=new Object[1];
args[0]=context;
// Just in case there is a access/invoke violation...
try
{
// Finally, we need to invoke the method...
handlerMethod.invoke(handler,args);
}
catch (java.lang.IllegalAccessException e)
{
// Let the user know (and thus let the system
know)
// This should really never happen.
context.Error(e.toString());
}
catch (java.lang.reflect.InvocationTargetException e)
{
// Let the user know (and thus let the system
know)
// This should really never happen.
context.Error(e.toString());
}
}
catch (java.lang.NoSuchMethodException e)
{
// Let the user know (and thus let the system know)
// This should really never happen.
context.Error(e.toString());
}
}
}
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
Re: Trouble JDK 1.1.6 + HOTJAVA
On Fri, 02 Oct 1998 18:16:59 +0400, Alexander Davydenko wrote: >> > > * You DO NOT need to set JAVA_HOME. Doing so can be bad for your health >> >> What makes you think HotJava needs JAVA_HOME? Look at the launching script. I >> think you need to set JDK_HOME (or JRE_HOME) but not JAVA_HOME, but the script >> is the final arbiter. > >I can't catch a thought... What wrong is to set JAVA_HOME ? > >The starter script is doing the same thing. > >I just make it work simpler, by setting up that. :) If that is the only Java VM on your system, then it should not cause a problem. However, setting this can lead to problems if you install a new JDK to try it and forget to unset it. Or if you have another JVM installed that may happen to use JAVA_HOME Since it gets set in the script, setting it externally can cause problems/confusion. It is not that it, in and of itself, is bad. With so many different people doing so many different linux systems and so many different ways they install things, it is easier to just make a blanket statement that *generally* is true and assume that those who are more advanced users can work though the stuff. 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
Re: slightly off-topic
On Sat, 3 Oct 1998 02:15:03 -0500 (EST), Fred McDavid wrote:
>Hi,
>
>I keep hitting an obstacle while coding and I was hoping someone here
>could help enlighten me:
>
>A bunch of the java-standard methods return "Object" and when I try to
>use them, I get the following error:
>
> >> Incompatible type for declaration. Explicit cast needed to convert
> java.lang.Object to (whatever)
>
>In this particular instance, I've created a class which is a descendant
>of java.awt.Checkbox. I add an ItemListener and the listener, therefore,
>receives an ItemEvent. I call ItemEvent::getItem() and try to call a
>method that I've created for the descendant class...hence the error which
>would seem to imply that if I'm going to use the ItemEvent (or the java
>hashtable or a bunch of other stuff that I've just worked around), I
>can only call Object::(whatever Object methods there are) after my
>objects go thru the mill.
>
>I'm pretty sure whatever I'm missing is pretty basic...could anyone
>shed some light on this for me?
Well, are you asking why or how?
The "why" a generic "Object" type is returned from a number of methods
is because these methods are usually dealing in the abstract with any
type of object - such as the java.util.Vector class is able to store any
object type. Since all objects are subclasses of Object, the methods
are defined to take (and return) an Object so that you are now able to
use an object of any class, including those of your making.
The "how" to get arround this is much like C/C++ type casting. If,
for example, you have stored objects of class java.lang.String in a
vector, you would get them back out as follows:
java.util.Vector myVector=new java.util.Vector();
myVector.addElement("A string as an element");
String data;
data=(String) myVector.elementAt(0);
Now, note that even though a bit of code like this in C could be
dangerous since you could be taking some other object and saying
it was a String, in Java, at run time (since the compiler can not
know what type of object is in the vector) the JVM will make sure
that the object returned is a String object otherwise an exception
will be raised.
If you have an object you can also find out what its type is or
you can ask if it is an instance of a specific class without the
overhead of a try/catch of an exception while trying to typecast
the object. In most cases one actually knows that all the elements
in a vector are strings/etc so normally the cast is all that is
needed or wanted.
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
Re: Java-Linux networking problem < Connection refused >
On Mon, 05 Oct 1998 06:21:19 +, Glenn Valenta wrote:
>I'm new to Java and also not too experienced in Linux so forgive me
>if this is a simple question, but I couldn't find it in the FAQs.
>
>When I try to open a network socket, I get...
>
> java.net.ConnectException: Connection refused
>
>at this line...
>
> socket = new Socket("localhost", 8205);
>
>I think I may have a permission problem somewhere but I can't even
>open the socket as root. Any Ideas?
>
>Does this sound like a host.allow or host.deny problem?
>
>At the moment, I have written a simple client / server app to simply
>get started in java networking. The problem is with anything that opens
>a port. I have compiled sample code from a few books and get the same
>error each time.
>
>I'm using jdk 1.1.6 on Redhat 5.1 with the updated lib.
>
>I have placed the full source on my Webpage at...
>
>http://ouray.cudenver.edu/~gavalent/java/problem1.html
Well, the problem is nothing to do with security given that you are
running as a full application and are connected via localhost.
The first thing I noticed was that you are not connecting to the same
port that the server is "servicing". You created the server socket on
port 4747. You need to connect to that port. I do not know what 8205 is
since you do not service that port in any of the code you have posted.
Also, just in case of a strange setup - check that you can "ping localhost"
meaning that your system knows that as a name. (Normally one should
have that setup but I have run into people who either deleted that definiton
from their hosts file or never put it in...)
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
Re: Does Java apps has to have .class extension?
On Mon, 5 Oct 1998 19:16:27 -0400 (EDT), Danny Lu wrote: >Hi, > Can anyone tell me does Java applications has to have .class >in order for it be to executed in Linux? ??? Java does not directly need .class to run. In fact, to use the java binary support in the Linux kernal, you may want to not have .class as the name of the main() class. However, standard Java will load classes from .class files. (Or the equiv in jar/zip files) This means that when you do: java Foo You are telling Java to load Foo.class. Same for if a class called Bar is used, the JVM will look for it as Bar.class. (Well, the default class loader will do that and if it is already loaded, it will not need to look again) 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
Re: DatagramSocket option in jdk1.1.6v4
On Wed, 7 Oct 1998 02:26:37 -0400 (EDT), Gwobaw A. Wu wrote: >Hi, >I thought this problem is fixed in jdk1.1.6v4, but I still have it: >java.net.SocketException: invalid DatagramSocket option >at >java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:155) >at java.net.MulticastSocket.create(MulticastSocket.java:111) >at java.net.DatagramSocket.(DatagramSocket.java:114) >at java.net.DatagramSocket.(DatagramSocket.java:100) >at java.net.MulticastSocket.(MulticastSocket.java:92) > >jdk1.1.6v1 did not have this problem though. Watch for jdk1.1.6v5 - it should be up on the web sites very soon. This is a known problem that was introduced in v4a (sorry) 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
Re: Java app without X installed
On Wed, 7 Oct 1998 21:05:39 +0800 (WST), John Summerfield wrote: >On Tue, 6 Oct 1998, Steve Byrne wrote: > >> >> Aw, come on, man! RTFM! I covered this in great detail; you should take the > >Well I for one don't know which frigging document you're talking about. >I've just installed the jre on a system without X. To make the jre even run >I found it necessary to install a part of XFree even though I don't want >the gui. > >I can see no mention of this in any of the documentation included with the >package jre1.1.6-v4a-i386-libc5.tar.gz. > >Exercise patience and courtesy in your replies. You too were a beginner >once. It is a bit hidden - it is in the README.linux file under the NS_JAVA option. :-) If you set that environment variable, the non-statically linked non-AWT JVM will be used. One thing we can look at is to use the non-AWT/X version automatically whenever the DISPLAY variable is not set. You could still set the NS_JAVA to always use that, but at least it would be less confusing/more automatic for the cases where X is not running, let alone installed. 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
Re: javac dies silently
On Sun, 11 Oct 1998 08:59:43 -0400, strider wrote: >Greetings. > >I notice that, after the 1.1.5 distribution of Java on Linux, regardless of >which port or subversion I try, javac no longer works. It seems to be a link to a >file called .java_wrapper, which basically sets a bunch of system vars. What it >doesn't do is compile .java files. There doesn't appear to be anything about this in >the FAQ. The java and javah executables work, so the whole dist. isn't bad. I'm >using 1.1.6-5 glibc on RH 5.0/KDE 1.0. > >What do I need to do/get to make javac work? It should just work. Make sure (since you are RedHat 5.0) not to have Kaffe installed from the default Kaffe archives. I basically run RedHat 5.0 on the system that I built the v5 glibc version of the JDK 1.1.6 Linux port. Note also that if you have JAVA_HOME set or something in CLASSPATH that points to an old JDK install, this can cause things not to run. However, given that you are getting a silent failure it sounds more like a Kaffe install collision. 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
Re: Fw: javac dies silently
On Sun, 11 Oct 1998 13:08:26 -0400, Nathan Buggia wrote: >How do you de-install Kaffe? Where is it located? Remove the RPM - you can use GLINT (the GUI) to remove packages that are installed. 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
Re: RH5.1 configuration problem for running with Java???
On Mon, 12 Oct 1998 09:52:09 -0400, Wendy Richardson wrote: >Hi, > >I am trying to run a Java application on RH5.1 with a glibc version of >jre1.1.6v5. My Java app uses JNI and X/Motif in the native part (legacy >code). >I get the following error: > >jre Jsaf >libc.so.5: cannot open shared object file: No such file or directory >(libfoo.so) >Class not found: Jsaf libc.so.5 ??? Should this not be libc.so.6 for a GLIBC system? Could you be running the libc5 version of the JDK? >Does anyone have any suggestions for what might be wrong with my >configuration on RH5.1? I wasn't able to find a newer version >of ld for RH5.1. > >Is it ok to use a shared object file (*.so) that was built on RH4.2 on a >RH5.1 machine with Java & JNI? Hmmm... I don't know. I have never tried to mix LIBC5 and GLIBC too much. RedHat 5.0 has libc5 libraries so that you can run the libc5 binaries. However, if your JNI code needs to interact with the green threads based function wrappers you may end up having problems. It is something I have yet to ever try. (I tend to try to stay in 100% Java whenever possible) 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
Ooops, we have a small LIBC5 problem...
On 09 Oct 1998 15:22:30 -0400, Kyriakos Georgiou wrote:
>
>You have probably got this correction already, but here it is
>anyways. It caused a "function {isGreaterOrEqua not found" with my bash
>(version 1.14.7(1))
Sorry to all of you who may have run into this problem. This is the correct
fix to the problem in checkVersions and we are building some new archives
that will have this fixed. We also will put up a fixed checkVersions script
so that you do not neet to down load the whole thing again. (I know I
would not want to just for this...)
Again, I am sorry for the error.
BTW - you are welcome to use this patch since it does solve the problem:
-8<8<-8<-
--- bin/checkVersions.orig Fri Oct 9 15:13:34 1998
+++ bin/checkVersions Fri Oct 9 15:13:45 1998
@@ -103,8 +103,8 @@
# 5.4.33 & 1.9.6 seem to do it too
if isGreaterOrEqual "$libdlVers" 1.9.6 ||
- {isGreaterOrEqual "$libcVers" 1.5.44 &&
-isGreaterOrEqual "$libdlVers" 1.9.9}
+ { isGreaterOrEqual "$libcVers" 1.5.44 &&
+ isGreaterOrEqual "$libdlVers" 1.9.9 }
then
# supplied libraries are not needed
return 1
-8<8<-8<-
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
Re: JAVA Error
On Tue, 13 Oct 1998 14:31:36 +0530 (IST), Syed Mubin wrote:
> Hi,
>
> I've installed jdk1.1.6 on RHL5.1 ,Iam able to create and run
> applets but when i try to compile and run a standlalone
> application program i get the following errors
>
> class hello{
>
> public static void main(String args[])
>{
>System.out.println("HELLO");
>}
> }
>
> ERROR SHOWN
> [syed@barfi syed]$ javac hello.java
> [syed@barfi syed]$ java hello
> Can't find class hello
Try doing an ls -l hello.class after the javac. If the file is not
there, do a find . -name hello.class
If it showed up in a sub-directory, you most likely made a package
statement in the source file that placed it inside a package rather
than at the "root"
Oh, and try this without CLASSPATH set. (I noticed that you had
CLASSPATH set. If you really need CLASSPATH set, make sure you have
"." in the CLASSPATH in addition to the other directories - just in
case)
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
Re: small patch
On 09 Oct 1998 15:22:30 -0400, Kyriakos Georgiou wrote:
>
>You have probably got this correction already, but here it is
>anyways. It caused a "function {isGreaterOrEqua not found" with my bash
>(version 1.14.7(1))
>
>later
>Kiriakos
>
>
>
>
>--- bin/checkVersions.orig Fri Oct 9 15:13:34 1998
>+++ bin/checkVersions Fri Oct 9 15:13:45 1998
>@@ -103,8 +103,8 @@
>
> # 5.4.33 & 1.9.6 seem to do it too
> if isGreaterOrEqual "$libdlVers" 1.9.6 ||
>- {isGreaterOrEqual "$libcVers" 1.5.44 &&
>-isGreaterOrEqual "$libdlVers" 1.9.9}
>+ { isGreaterOrEqual "$libcVers" 1.5.44 &&
>+isGreaterOrEqual "$libdlVers" 1.9.9 }
> then
> # supplied libraries are not needed
> return 1
Well, in bash version 2.01.1(1) this change seems to be a problem.
We are going to have to do something different since there seems to
be a conflict of behavior here.
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
Re: Threads / CLASSPATH?
On Wed, 14 Oct 1998 13:29:45 +0100, Danny Ayers wrote: >Hi, >Thanks for all the suggestions relating to CLASSPATH - I though this >would be a fairly quiet list (Java&Linux = FairlyObscure^2, mail->0), >not so! > >I've still got a problem though. When trying to run java mpEDIT (nice >basic java text editor I downloaded) I get 'Can't find class >java.lang.Thread'. Now other stuff runs ok, and the lib is there in the >.zip file. mpEDIT runs ok on a Windows machine. Hmmm... This tends to happen when the Java classes.zip file is not found by the JVM. I have seent this in two cases: 1) When Kaffe is installed since it will answer to "java" and does not automatically find its own classes.zip file (since it used to use Sun's) 2) When a program wrapper script uses the jre and the -cp/-classpath option since this option *replaces* the classpath that the java_wrapper supplies. This is, IMHO, a bug, but it is how it works. In these cases, it is sometimes needed to actually have CLASSPATH set to point at classes.zip. I personally think that no user should every point at classes.zip and that the system should automatically make sure it is at the end of the classpath so that things work. However, there are so many different startup scripts for so many different programs written by so many different people who have had to deal with the many different behaviors of past Sun JDK releases, it is hard to get this all cleaned up. >I've seen mention of the green_threads stuff (but nothing relating >directly to my problem) is this related? No... "green" threads are also known as "user based" threads which means the threading is handled by the JVM on its own vs "native" threads which uses the operating system kernel to manage the threading. Either way works, albeit in different ways. Native threads can be overall better but only if the OS supports a good threading model without too much overhead. OS/2 and Solaris both have very nice threading support. Windows NT has reasonable threading support but not very good performance. The Linux kernel threading support is rather high in overhead and there are complications with respect to the way the GC works. 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
RE: help!!!
On Sat, 10 Oct 1998 23:51:23 -0700 (PDT), Jason Dillon wrote: >Try setting your classpath to contain jdk116/lib/classes.zip: > >sh: > >CLASSPATH=/where/ever/you/put/it/jdk116/lib/classes.zip >export CLASSPATH This should not be needed. The problem below is most likely that he is not running the javac from the jdk116/bin directory. That is a simple script that will set CLASSPATH for you. If you get a CLASSPATH NOT SET error it is either KAFFE that is running and not the jdk116/bin/javac command or it is some other problem like that since the javac script (which is just .java_wrapper) always makes sure CLASSPATH is set. >csh: > >setenv CLASSPATH /where/ever/you/put/it/jdk116/lib/classes.zip > >You should also set JAVA_HOME to /where/ever/you/put/it/jdk116/ in the same >fashion. That should fix it. Let me know if it doesn't. Please do not set JAVA_HOME. It is not needed and generally will help add to confusion rather than reduce it. >On 11-Oct-98 Willy wrote: >> Sir/Madam, >> Good day!!! >> I download the jdk_1.1.6-v5-x86-lib5.tar.gz... then untar it... it >> extracted on jdk116 directory then... and when i run javac it return the >> error message "CLASSPATH NOT SET" please help me how to solve this >> problem... We're students now developing a software using Java in >> Linux... please help us as soon as possible Do you have KAFFE installed. If you do a "which javac" you should see that it is running the jdk116/bin/javac If that is not what it is running your path may be incorrect or you may have some other javac in the path that you will want to remove 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
Re: javac dies silently
On Sun, 11 Oct 1998 17:36:08 -0400, strider wrote: >On Sun, 11 Oct 1998 09:50:15 -0400, "Michael Sinz" <[EMAIL PROTECTED]> wrote: >> >> It should just work. Make sure (since you are RedHat 5.0) not to have >> Kaffe installed from the default Kaffe archives. >>> On Sun, 11 Oct 1998 08:59:43 -0400, strider wrote: >>>I notice that, after the 1.1.5 distribution of Java on Linux, regardless of >>>which port or subversion I try, javac no longer works. > >Thanks for responding. I've removed Kaffe from my system, as well as older versions >of the JDK, and javac still does nothing. Any other ideas? Hmmm... I can not think of a reason off the top of my head. I would look at what the javac is trying to run. For example, check what java -version outputs. (javac is just a java program that happens to be a Java Compiler) 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
Re: mpEDIT+Threads/CLASSPATH?
On Wed, 14 Oct 1998 15:41:02 +0100, Danny Ayers wrote:
>Thanks (Ernst & Michael) for the replies - I should have included the
>following in my query :
>
>mpEDIT is a text editor, very like wordpad, for java, free with source
>from :
>
>http://members.tripod.com/~mpTOOLS/mpEDIT.html
>
>Thanks (Ernst & Michael) for the replies - I should have included the
>following in my query :
>
>the script to run mpEDIT is as follows -
>java -classpath src:$CLASSPATH mpTOOLS.mpEDIT.mpEDIT $1 $2 $3 $4
Unless the src directory is needed in the classpath, try using just
java mpTOOLS.mpEDIT.mpEDIT $*
You could also do:
CLASSPATH="src:${CLASSPATH}"
java mpTOOLS.mpEDIT.mpEDIT $*
if you need the src part. The -classpath option *replaces* the classpath
environment variable and thus prevents the java_wrapper from adding its
classes.zip path. (A bug, IMHO, but it is how it does things)
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
Re: rmid with JDK1.1.6
On Thu, 15 Oct 1998 10:15:03 +0100, Michael Kranz wrote: >Hi, > >believe it or not: I really mean rmid; look at > >http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/rmid.html > >The same is true with Windows. So my question was, is there rmid in >JDK1.1.6, especially under Linux? What I learned from you, folks: Apparently >not. But read ahead... No. Note that elsewhere in the JDK 1.2 documentation (which is not final yet) it shows that rmid is a new feature of JDK 1.2. It was not part of the JDK 1.1 (1.1.x) releases. When the JDK 1.2 is released and we have ported it to Linux, rmid will most likely be part of that release. >Is there any equivalent for rmid? If I interpret Mik and Joe correctly, it >seems so, because they say running RMI-Objects with Linux. But how does an >application-object-server under JDK1.1.6 activate business-objects (which I >compile with rmic and register via rmiregistry) without rmid? (According to >the JDK1.2 documentation above even rmiregistry has to access rmid). Maybe >you are already using some CORBA-stuff underneath instead of "Pure RMI"?? If you are doing things that only work in JDK 1.2, you may need to wait for JDK 1.2. Otherwise, please refer to the JDK 1.1 documentation on how RMI is activated and works. Sorry I can not be of more specific help other than to point you at: http://java.sun.com/products/jdk/1.1/docs/tooldocs/solaris/index.html and http://java.sun.com/docs/books/tutorial/rmi/index.html (The solaris documentation is basically the "unix" documentation) 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
Re: setup question
On Thu, 15 Oct 1998 07:44:31 -0400, Jim Ridenour wrote: > First let me say I'm new to Linux, but I do run other programs on it >successfully. >I have two questions: > >1. On Blackdown's mirror sites for JDK116_v5 they have two files beginning >with jdk... and differing only by the letter "b" toward the end. The one >without the "b" appears to be the one I want and uncompresses to the JDK. >The one with the "b" on the end won't even uncompress. What is it? We have started to release the files in both tar.gz and tar.bz2 format. The bz2 compression format (bzip2) is a new compression system that happens to do a nice job on the JDK (saving a bit over 10% in size and since the archive is over 10megs that means over 1meg smaller archives) Many people do not have bzip2 support on their systems. Plus, tar.gz is a well established format that works on almost all platforms (including Windows/WinZIP) tar.gz also uses much less RAM to decompress a file. (bzip2 can use a lot of memory to do a decompress and the memory it takes depends on the way the file was compressed) The main reason we are trying bzip2 format is to see if people really want it due to the smaller file sizes. (Not all files are smaller) I know it takes me twice as long to upload the two different formats and thus I would like to have only one, but since I do the upload in auto-pilot mode while I am away from my machines usually, it does not bother me too much) >2. Having uncompressed JDK116v5 (the one without the "b" at the end) it >creates all the directories to hold the jdk. If I go into /jdk116v5/bin >and create a test.java file and then invoke "javac test.java", nothing >happens. I just get a command prompt back. No test.class file is created, >no errors, no messages, nothing. Both the test.java and the javac are in >that directory so paths shouldn't be the problem. Any ideas? Hmmm... I don't have an idea right now. I normall add the jdk116v5/bin directory to my path and do my work elsewhere. >PS I should say this is on RedHat 5.0 and I used their package manager to >remove all Kaffe files. Also, I am using the glibc version which by the >tests Blackdown describes for telling which library you have, is the one I >need. Thanks for that PS. I build the glibc libraries on RedHat 5.0 (albeit updated to current releases of the kernel and other security/bug fixes) What happens if you just type "java -version" or "javac" The first should give you the version of the java system you are running and the second should output the compiler options. If this does not happen, try doing "which java" or "which javac" to find out where things may be coming from. 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
Re: rmid with JDK1.1.6
On Thu, 15 Oct 1998 14:51:46 +0200 (MET DST), Kontorotsui wrote: > >On 14-Oct-98 Joe Carter wrote: >>My linux box has the same java facilities as the solaris box. >>I'm fairly certain you can talk either way. >> >>There's no "rmid" in the solaris 1.1.6. >>My solaris stuff only uses rmiregistry... > >I have to use solaris because there is the JDK1.2. I thought that RMI >was available on in 1.2, but I see it also in the 1.1.6, now. > >But does it work? RMI was available in all 1.1 JDK versions. JDK 1.1 does not have rmid but RMI has worked for a long time. >>Can anyone comment on the differences between 1.1 and 1.2 RMI? >>(beyond the running over IIOP...) > >Yes, I'd like to know the differencies too, please. The best places to look are: http://java.sun.com/docs/books/tutorial/rmi/index.html http://java.sun.com/products/jdk/1.1/docs/tooldocs/solaris/index.html 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
Re: Working Button mnemonics under Linux Java?
On Thu, 15 Oct 1998 12:29:30 -0400 (EDT), Jim Burmeister wrote:
>Eu Hin Chua <[EMAIL PROTECTED]> wrote:
>
>> Has anyone ever managed to get keyboard mnemonics working for JButtons
>> using Swing?
>>
>> e.g.
>>
>> OKButton.setMnemonic('o');
>>
>> Under windows 95/8/NT, all of my code (including the SwingSet demo)
>> performs as expected, with the ALT key being used to activate the mnemonic
>> for both buttons and menu items. Under Linux, nothing happens at all.
>
>Swing button mnemonics work just fine for me, both in standalone buttons
>and menus. I've used them in my own code, and I also just checked the
>SwingSet demo and it works OK too. I did nothing special to set them up;
>pressing Alt+key has always just worked.
>
>Here's my setup:
>
> Red Hat Linux 5.0 w/upgraded glibc libraries
> Blackdown JDK 1.1.6v4a
> Swing 1.0.3
> Metro-X 4.3 X server
>
>Chances are, the problem is not with the JDK; it's with the way you have your
>X server configured. Are you able to use the Alt key in other X applications?
>Check your .xinitrc or .xsession script for "xmodmap" commands; if you've used
>xmodmap to reconfigure your keyboard, the Alt keys might be generating keysyms
>other than what the JDK is expecting. You can use the "xev" program to see
>whay keysyms your Alt keys are generating; here's what the output looks like
>on my system, for the left and right Alt keys respectively. The keysym on
>the third line is what's important: it should be "Alt_L" and "Alt_R".
Note also that many users may have the window manager set up to use
the alt key for their own use. Many of the alt key strokes a friends
machine do window operations or scrolling operations or desktop operations.
>-Jim Burmeister, Metro Link Incorporated <[EMAIL PROTECTED]>
Thanks for your answer Jim - There are so many places where the
configuration in unix systems can "confuse" users.
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
Re: RPM JDK installation on RedHat 5.1
On Wed, 14 Oct 1998 17:51:51 +0100, Arif H Saleem wrote: >hi! > >We have used the jdk 1.1.6v5 tar.gz to build an rpm on an i386 RedHat 5.1 >system. We have glibc 2.0.7-19 installed (also glibc-devel) and lesstif 0.86.5. >We had no problem building the rpm but on installation we get a failed >dependency: > >libXm.so.2 required by jdk-1.1.6-5 My guess is that the person who made the package did that. MetroLink provided the JDK group with Motif developer kits so that we can build the JDK with Motif *and* statically link it. The JDK archives we have produced include both the static and dynamic linked versions of the JVM (java, java_dyn, etc) For most users, just installing the JDK and using it will result in the user getting the statically linked JDK. Setting DYN_JAVA to some value will make the wrapper script load the dynamic linked version of the JVM. >We understand that this is provided by Metro Link Motif 2.0 ( we checked their >web page) but it does not seem to be included with LessTif. (It only has >libXm.so.1) >Does this mean that we either have to buy Metro Link Motif or recompile >against LessTif ??? No. Now, if you were to compile the JDK you would need either Motif or LessTif. Currently we have run into a number of strange behaviors in LessTif that prevent the JDK from running 100% correctly with AWT code. The MetroLink Motif does not have these problems. 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
Re: lifeless javac with RedHat 5.0 JDK1.1.6v5
On Thu, 15 Oct 1998 17:15:47 -0400 (EDT), Jim Burmeister wrote: >Jason Chambers wrote (well, quoted): > >> If I create a test.java file and then invoke "javac test.java", nothing >> happens. I just get a command prompt back. No test.class file is >> created, no errors, no messages, nothing. > >A few weeks ago, when I decided to start using Java, I downloaded the JDK >(version 1.1.6v4a) and installed it on my Red Hat 5.0 system. I had this >exact problem. A further problem was that most other Java programs would >cause the java runtime to segfault. > >I fought with it for a while (being the type of person who exhausts all >possibilities before asking for help). Eventually, I ran across this >section in the README.linux file: > >Generally, you should get the glibc version if your machine is running >glibc, but libc5 should work acceptably as well, if you have a recent >(say, past April 1, 1998) version of the glibc library installed on >your machine (RedHat 5.0 by default comes with an older version of glibc, >you need to get the 2.0.7-7 version from RedHat to win). > >Even though this text referred to a different case than my setup (it talks >of running the libc5 version of JDK, not the glibc version), I decided to >try upgrading my C libraries to see if it would help. So I downloaded the >latest glibc update packages from ftp.redhat.com (glibc-2.0.7-19) and >installed them. Once I did that, the JDK worked flawlessly. The wording is not too good in that section. The updating is needed also for older glibc systems if you want to run the JDK. >Can we get an official answer from someone on the porting team to the >following questions: > >1. Should the latest version of the JDK for glibc work on a stock Red Hat > Linux 5.0 machine? It would appear the answer to this is "no", since I > and others have had problems. I would think that it could have problems given the scope of bug fixes that have been done in glibc. If you look at the list, it really sounds like an update to glibc 2.0.7-19 would be a very good idea. It is too bad that some popular older releases may need updating but the fact is that the code continues to evolve and important fixes are being made to the glibc code base. >2. If the answer to #1 is "no", is the recommended solution to update the > glibc package on your system? While this was the solution I found, the > previous poster noted that some people would rather not make such a > drastic change to their system unless absolutely necessary. Given the fixes (both security related and otherwise) this is a very good idea. There are fixes that have to do with time zones, threading, and lots and lots of security and exploit fixes. >3. If the user does not wish to upgrade their C library, is there a workaround > (I've seen talk of doing stuff with the C libraries in the green_threads > directory, but didn't try it since I had already solved the problem). > Or, is the Red Hat 5.0 glibc package sufficiently broken that the only > solution is to upgrade? Well, it may be that if they don't want to upgrade glibc then doing libc5 may work, but even that may be a problem. Even Red Hat claims that you need the May 28th, 1998 release of glibc to be compatible with future security fixes in other modules. This includes the JDK. >4. Once official answers to these questions are determined, I think they > should be explained clearly in README.linux. I looked at the v5 version > of this file, and no new information on this subject was added since v4a, > when I fought with the problem. Since you most resently fought with the problem, what is the best answer here? (Other than to fix the wording to recommend to update to a known working version of glibc. 2.0.7-19 seems to be a good one) 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
Re: glibc question
On Fri, 16 Oct 1998 18:21:02 -0400 (EDT), [EMAIL PROTECTED] wrote: > >An offpoint but related question Does anyone know of an easy >way to get the glibc source files installed? The latest version >from gnu is 2.0.6 (btw, how can redhat have a later version that >gnu itself...) and the latest srpm from redhat is version 2.0.7-13. > >I need the source files for debugging. Anyone know of a convenient >way to get the right source installed without making everything >get messed up? Well, if you are RPM enabled, just install the SRPM. 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
Re: Zero sized display panes from recompiled jdk
On Fri, 16 Oct 1998 17:15:04 -0600, John Campbell wrote: >Im getting very small display panes which cannot be resized >from my recompiled jdk1.1.6v5. The down-loaded jdk works >fine. I suppose i'm not loading lessTif correctly. Any ideas >about where to start? -John Campbell This is one of the LessTif problems that I know of. From the last LessTif build I did it still was a problem. It works correctly in every Motif build (1.2, 2.0, and 2.1) 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
Re: Zero sized display panes from recompiled jdk
On Fri, 16 Oct 1998 17:15:04 -0600, John Campbell wrote: >Im getting very small display panes which cannot be resized >from my recompiled jdk1.1.6v5. The down-loaded jdk works >fine. I suppose i'm not loading lessTif correctly. Any ideas >about where to start? -John Campbell This is one of the LessTif problems that I know of. From the last LessTif build I did it still was a problem. It works correctly in every Motif build (1.2, 2.0, and 2.1) 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
Re: libawt.so purgatory
On Sun, 18 Oct 1998 17:56:17 +1000, jim watson wrote: > > > > >(Jon Peterson) wrote: > >> /usr/local/java/bin/i586/green_threads/java_ns: can't resolve symbol >> 'XFreeColors' > >Jon, > >It appears to be running java_ns...? > >I dont have v2 but the README.linux for v5 states: > >"You will not be able to run any AWT based applications with the nonstatically >linked java interpreter, so only set NS_JAVA for non-GUI based applications. >[For the curious: in the bin/i586/green_threads/ directory, the executables >(java for the static version, and java_ns for the non-static version) are kept. >" > >I got the same error message by setting NS_JAVA=true in a otherwise good >setup... Yup, that is what would happen. If you want to use the dynamically linked Java with AWT you need to set DYN_JAVA=true. This version will need to have Motif shared libraries on your system. Normally you would not set either DYN_JAVA or NS_JAVA if you want to run AWT and do not own a copy of Motif. NS_JAVA is mainly there so that you can run non-GUI Java applications without X-Windows installed. Such as server-side applications/servlets. This reduces the size of the memory used and does not require that X be installed on the system. 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
Re: question about installing
On Sun, 18 Oct 1998 03:17:58 -0600, Sunny Sandhu wrote: > >Hi, > >i'm not sure if this is the right email address to send a question of >this nature to, i apologize if it isn't. > >I just downloaded the file jdk_1.1.6-v5-glibc-x86-tar.bz2 and i am >unsure how to install it. I am new to Linux, and i am aware of the >command 'tar zxvf filename', but i get an error message that it doens't >look like a tar archive. i tried renaming to a .Z and .tar extension >but it didn't work. .tar.bz2 files are much like .tar.gz files only they are compressed using bzip2 rather than gzip. bzip2 is rather new and not "fully established" yet so many systems do not have this installed. Tar also does not directly know about bzip2 (at least the versions I have) So, you need to get BZIP2 to decompress the file and then run that through "tar -xf". Otherwise you could download the .tar.gz version of the file. It is the exact same tar file only with gzip compression. This normally is very easy to extract since tar tends to know how to deal with this if you use "tar -zxf" (the -z tells it to use gzip filter) 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
Re: Sending objects down a stream problem
On Sun, 18 Oct 1998 17:29:52 -0600, Glenn Valenta wrote: >I'm almost sure this is one of those problems cuased by >my misconception of how things work in Java v.s. C++, >but I have run this thing around for days without resolve. > >Maybe someone can see the obvious > >I'm trying to send a serialized class down a network pipe and am >only getting the first one on the other end. The rest seem to vanish. [code deleted...] You are trying to send the same object down the same (already open) object output stream. The serialization stuff keeps track of what was sent already and does not send it again. You can either send new objects or close and open new streams for each one. 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
Re: Zero sized display panes from recompiled jdk
On Mon, 19 Oct 1998 10:37:43 -0600, John Campbell wrote: >>>>> Michael Sinz wrote >>John Campbell wrote: >>>Im getting very small display panes which cannot be resized >>>from my recompiled jdk1.1.6v5. >>This is one of the LessTif problems that I know of. From the last >>LessTif build I did it still was a problem. > >Are you your'e saying is that there is no work-around? Well, I did not find out for LessTif. The problem I saw was that the java.awt.Window objects I created would only render a 10x10 pixel area in the top left even though the whole 120x80 pixel area was there. Other windows moved under it, you would notice that it really was 120x80 in size but all rendering was clipped to the 10x10 size. The exact same Java source code on Windows, Solaris, MacOS, and Linux with Motif works correctly. It also works as an applet in Netscape under Windows, Linux, and MacOS. It may actually work elsewhere but these are the only test platforms I have. (Oh, and it works with FreeBSD with Motif) 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
Re: FW: Slackware and static versus ELF
On Mon, 19 Oct 1998 14:39:40 -0700, Marsh, Douglas wrote: > >Well this is an update, I've collected bits and pieces of later/newer, ELF >compiled, X lib files from two other linux systems where the installed (not >me) custom installed his X Windows (one was Slackware and the other RedHat, >but both have more than new enough ELF X libs). The JRE is happy, and I >believe the JDK should also... > >I'll check out the XFree86 org for the newest ELF precompiled version. I was >just wondering if anybody had a bare minimum X lib tgz or something... I'm >just developing and running "console" applications. Nothing (yet) GUI! Is >there a version of the JRE which is console only (i.e. required no X >libraries)? If you set NS_JAVA to something (like "true" or "yes" or "foo" or "xxx") then the Java wrapper scripts will run a version of the JVM that does not need X and, in fact, can not use X. This is specifically made so that server-side Java applications/servlets can be run without the overhead that the larger JVM-with-X support code has. (Only a memory overhead issue, but memory is overhead :-) This works fine for all console and network based socket code. 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
Re: Java Plugin doesn't work
On Tue, 20 Oct 1998 13:10:43 +0800 (HKT), Robert P. Biuk-Aghai wrote: >On Fri, 16 Oct 1998, Patrick Lamb wrote: > >> I got it to work by setting the NPX_PLUGIN_PATH environment variable. >> (It's in one of the FMs...) IIRC, it isn't supposed to be needed for a >> default installation, but the plugin suddenly started working when I set >> it anyhow. In my case I set >> NPX_PLUGIN_PATH=/home/pdlamb/.netscape/plugins >> export NPX_PLUGIN_PATH >> in my .bashrc. >> >> Pat > >I have in the meantime downloaded the activator.i18n-linux-glibc >plugin (previously I used the activator-linux-glibc plugin), installed >it, and set the NPX_PLUGIN_PATH variable to the ~/.netscape/plugins >directory. Upon starting Netscape 4.06, I get following message: Just a simple question - is there a reason why you are trying the plug-in in 4.06? I have seen things about problems starting in 4.05 with the plug-in due to some changes in the browser. Also, starting in 4.06, Netscape has finally main-lined the JDK 1.1.x Java into their browsers and thus there generally is no need for the plugin. 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
Re: CheckVersions Error...
On Wed, 21 Oct 1998 20:58:22 -0700, Dustin Preisler wrote:
>new to Linux, attempting to
>install and run the Blackdown
>Java..
>get a:
>/usr/lib.java/jdk116_v5/bin/checkVershions:
>{isGreaterOrEqual: command not
>found
>error...
>thats when i try to do a
>javac
>or
>javac -g
>on any .java file...
>can anyone help me out
>thanks..
You can hand-patch that file or you can:
--- bin/checkVersions.orig Fri Oct 9 15:13:34 1998
+++ bin/checkVersions Fri Oct 9 15:13:45 1998
@@ -103,8 +103,8 @@
# 5.4.33 & 1.9.6 seem to do it too
if isGreaterOrEqual "$libdlVers" 1.9.6 ||
- {isGreaterOrEqual "$libcVers" 1.5.44 &&
-isGreaterOrEqual "$libdlVers" 1.9.9}
+ ( isGreaterOrEqual "$libcVers" 1.5.44 &&
+isGreaterOrEqual "$libdlVers" 1.9.9 )
then
# supplied libraries are not needed
return 1
which is the difference in checkVersions that support
both BASH 1.x and BASH 2.x syntax. (Sorry about the problem
but my only LIBC5 system has BASH 2.x...)
This should be in the v5a version of the JDK 1.1.6 JDK.
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
Re: apache, jserv, blackdown's vm, memory leak?
On Thu, 22 Oct 1998 15:29:42 -0500, Keith T. Garner wrote: >I'm out at a clients and we're investigating using Linux, Apache, and >Jserv in Apache for the new services they want to roll out to their >customers. > >Being a Linux user for years, I have no doubt of its ability, but being >a company they want to play it safe. I've been doing an unrelisitic- >for-my-clients-uses tests where a java servlet that speaks over RMI is >being hit anywhere from 3 to 8 times a second. Its working beautifully >except I think I may have discovered a memory leak. > >When I first ran the test servlet, memory would grow quickly and would >eventually fill up the heap and cause the vm to exit. After doing some >quick research I found out that the garbage collection thread was never >running because it was such a low priority thread and the cpu (and the >vm) was pegged with requests, so it never got a chance to collect. >I throw a System.gc() call at the end of the servlet, and the mongo >growth stopped. However, after 7-10 hours of being pounded on, the >memory footprint still grows a little bit. > >After I stopped the bombing I expected the the vm to shrink a bit, but >it never did...Which makes me think is a very time memory leak that is >showing up after constant pounding and a long period of time. And I can't >figure out if its in the vm, or in something that mod_jserv does to the >vm. First, something to do: Have something in the JVM print out the memory status (used and total memory) or log this every few minutes... However, I would guess that this is one of two things: 1) A real memory leak - they do happen sometimes in Java (either the actual VM or the Java code running on it. 2) A fragmentation tractor This is when memory gets used in just the wrong order and released in just the wrong order and thus causes memory to get very fragmented. Normally this requires a memory leak but sometimes, even with no memory leak this can happen, but only to a certain point. Things to do: a) In addition to the call to gc, you can try to force any finalizers to run. Sometimes objects need to run a finalizer and sometimes that needs to run on its own thread and... Anyway, this can help in rare cases. b) Check that the memory use within the VM is really going up (that is what the output of the VM memory status is for) If the amount of memory used does not grow, the problem is not within the Java code itself. If the amount of total memory does not grow then the problem is not in the heap space itself but is in an actual JVM memory leak outside of the Java heap (most likely not) >I can't track the possible bug down much more then this, which is >fustrating because its useless as a bug report. However, I do want to >see if anyone can verify my results. Do you have the servlet handy? Which version of the JVM? (Some earlier versions had problems with threads not freeing all resources) I have some Java server-side stuff running that tends to be up as long as the OS stays up. It is still in testing stage but there is a connection to it at least every 30 seconds with loads as high as one every 2 or 3 seconds during rush hour. (And it has lots of threads but I wrote my own thread pool class since this was started back when there was a bug in the Sun code that leaked a bit of memory for every thread you created.) 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
Re: Interprocess Communication with a Java Application
On Fri, 23 Oct 1998 10:03:56 -0700, Steve Bankes wrote: > >I am seeking advice about interprocess communication between a Java application >and other, not necessarily Java, applications. > >I am developing the Java application under Linux but want to be able to run it >under Windows. So far I have been using Linux FIFO's (named pipes) rather than >sockets. I am using FIFO's because it is easier to write shell scripts that >will create, read from and write to FIFO's than for sockets, and because there >does not seem to be a Java internal socket; i.e there seems to be no Java analog >of AF_UNIX (UNIX internal protocols) sockets. > >So far this approach is working fine under Linux. I know nothing about Widows >or Windows programming. I am concerned how portable this will be to Windows. The only real IPC in Java that is platform independant is via the network I/O classes. This also happens to work rather well between machines, not just between processes. Now, it is not light weight. Windows NT has a think known as a "named pipe" the is much like a fifo. However, it requires special code to create/manage one. Connecting to one (being sender usually) is trivial and even works over the network from Windows 95 and Windows 98. However, the other end requires NT. Again, sockets or UDP are very handy and with 127.0.0.1 it even should work reasonably fast. (Loopback address) And, it is easy (or at least easier) to work over the network to systems of different platforms even. I do this a lot with normal sockets and RMI and serialization. (All three in one program even, but usuaully just sockets since that works almost everywhere) 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
Re: Problem compiling with the JDK
On Thu, 22 Oct 1998 16:41:16 -0500, Andrew P. Karels wrote: >I am having problems useing the javac compiler in the Blackdown JDK. >When I just type "javac" I get the message "No library path set". I >have RedHat linux ver. 5.1 JDK version 1.1.6.v5 glibc. That message tends to mean that you have kaffe installed from the old RedHat RPM. It makes a javac shell script in /usr/bin that tries to use kaffe as the JVM. Try checking that "which javac" points to your /bin/javac and not to /usr/bin/javac 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
Re: StrongARM port
On Wed, 28 Oct 1998 09:14:53 -0700, Warren Little wrote: >Hello, > Was wondering if you folks had any plans to port the JDK to the > StrongARM processor (such as CCC's NetWinder). If someone in the porting group has such a machine, it would most likely happen. However, at the moment, no one has such a machine making it a bit hard to do the port :-) 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
Re: HP wrong, Linux right... right?
On Wed, 28 Oct 1998 20:28:52 +, Charles Forsythe wrote: >Hello, > >Below is a some source code for a simple test. You invoke it with a >hostname that has a telnet port (for historical reasons): > > java STest localhost > >Anyway, it spawns two threads. > >SThread opens a socket, unblocks a lock and then pends on a socket >read(). > >XThread waits on the lock, sleeps for a while and then closes the >socket. > >What I expect to happen (and what happens on Linux JDK), is that when >the socket is closed, the read() will throw an exception. What happens >on HP is that the whole thing hangs. The close() hangs, the read() >stays where it is. > >I think they have a bug involving blocking I/O (which was a problem with >Linux JDK at one point). Is this really a bug, or is this acceptable >behaviour. Someone please tell me it's a bug. They want to charge me >$250/hr if they investigate it and it's not a bug. Hmmm... This is a tough one. You are closing a socket from another thread while the first thread has already started to read from that socket. From an implementation stand point, it could do almost anything. It should throw an exception but that may depend on the soLinger setting. (Linger may prevent it from pulling the socket closed on some IP stacks... I do not know the HP stack and can not comment on it.) The code to me looks rather nasty since it does depend on being able to close a resource from another thread without there being some Monitor (mutex in Java) on that resource to keep only one thread doing things with it at once. I would personally feel that such code, while it may work in some cases/systems, is not code I would assume would work everywhere. 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
Re: newbie question
On Thu, 29 Oct 1998 11:47:12 -0700, a wrote: >Hi all, >I just installed the glibc verison of the blackdown JDK 1.1.6 and I am >getting this error when trying to complile a simple program using javac. > >/usr/local/jdk116_v5/bin/../bin/i586/green_threads/java: error in loading >shared libraries >libXpm.so.4: cannot open shared object file: No such file or directory You need to update your XFree86 version. The Motif libraries we used to build the JDK now require the newer XFree86 releases. 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
Re: problem running java under Linux
On Thu, 29 Oct 1998 17:28:38 -0500, Redeker, Marcus, BMG - NY1540 wrote: >All, > >I am using SuSe-Linux 5.2 and I installed "glibc-2_0_6-1_i386.rpm" >because I have a Sybase Server running >on this machine too. So I presume that I am using glib and I installed >"jdk_1.1.6-v5-glibc-x86.tar.gz" in the >directory "/usr/lib/jdk116_v5/". I created the well known >HelloWorld.java and get the following error: I build the v5 1.1.6 JDK on SuSE for the LIBC5 version. SuSE is basically LIBC5 with support for glibc. You will find that the LIBC5 version works while glibc will not be reliable. 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
Re: StrongARM port
On Fri, 30 Oct 1998 09:14:41 -0500, Christopher Hinds wrote: >What OS are we talking about anyway? Don't we have to port Linux to the >StrongARM platform first? The only OS's I know of to date are the Palm >Pilot and Windows CE. Actually, the Corel NetWinder and there other products are all on Linux. In fact, they announced that it is now RedHat 5.1 (it used to be a cross-compiled version of RedHat 4.2) 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
Re: Which version of linux on which is JDK compiled?
On Sat, 31 Oct 1998 15:45:39 +0900, SHUDOH Kazuyuki wrote: >What platform on which does binary distribution of JDK >for linux compiled? Which version of linux kernel? Well, the 1.1.6 v5 and v5a builds for x86 systems were done on: for glibc - a RedHat 5.0 base system with current updates and the Linux 2.0.35 kernel for libc5 - a SuSE 5.2 system - it is one of my test systems - and it has Linux 2.0.33 kernel as modified by SuSE. >As the linux patch to JDK shows us, linux JDK >distinguishes whether the platform supports signal >handler with three arguments or only one argument, with >the macro SA_SIGINFO. > >The macro SA_SIGINFO is defined by including signal.h on >linux 2.1.X, but isn't defined on 2.0.X. On x86 we use the production kernels since most users will be using such kernels. Other platforms may use other kernels. 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
Re: JDK for 21064?
On Sat, 31 Oct 1998 11:05:03 -0500, Uncle George [fwd by sbb] wrote: >[sbb: Here's what Uncle George wrote:] > >actually a 21164a ( the "a" really counts - who wuddya thunkit ) >i'm gonny try to see if i can build for all processors with 117, and see >if it all will fit under 10 meg. these processors are ( 21064, 21164, >and 21164a ). > >at the moment i am having probs with finding a home. The folks at >blackdown seemed to have reneged on their offer :-( . > >[Is it just me, or does this guy seem to be a real hard case. We've tried and >tried to bring him into the fold, and at this point I'm ready to say "let's not >try anymore. He's likely to do more damage if he joins than where he is now." >I know it's uncharitable of me, but statements like this (at least I don't >THINK we reneged on the offer, I THINK he let it fall on the floor) really piss >me off. Also, his lack of willingness to develop a unified port with us, and >other "loose cannon" behavior make me real hesitant at this point to extend any >more olive branches (and certainly not in the 1.2 space). > >What do others feel about this? -- sbb] I have asked him a number of times to join. I only got once responce back about how he could not join due to some issues with being a closed group. Given that we give out our diffs and let anyone in who has the legal access to the source, I find this difficult to understand. I don't know what to do. I still hope to find some time to finish the Alpha work but CVS is much more important and will make the work that much easier to manage. (Lots of little changes in prototypes and return types) 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
Re: JNI trouble with JNI_CreateJavaVM
On Sun, 1 Nov 1998 11:12:30 -0800, Andrew Burgess wrote: > >Regarding my problem with open(), upon reading further I see in >tutorial/native1.1/implementing/invo.html: > >>The user-level Java programming language thread implementation on Solaris >>requires the Java Virtual Machine to redirect certain Solaris system calls. The >>set of redirected system calls currently includes read, readv, write, writev, >>getmsg, putmsg, poll, open, close, pipe, fcntl, dup, create, accept, recv, >>send, and so on. This may cause undesirable effects on a hosting native >>application that also depends on these system calls. > >I believe this translates to "I'm screwed". Any chance this works in 1.2? Well, the only real answer here is not to use green threads but native threads. Green threads require these tricks so as to be able to do task switching while a call to a blocking I/O function is made. Native threads do not have that problem (but may have others :-() 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
Re: lib&jdk probs
On Wed, 4 Nov 1998 16:05:59 +0100 (CET), Bruno Boettcher wrote:
>hello,
>just tryed to install the jdk116v5 on our server and when compiling i get the
>following error:
>5:44:30 erm1:~/java/jSim$ make
>javac -classpath /usr/local/java/lib/classes.zip:. Capacitor.java
>/usr/local/java/bin/../bin/checkVersions: {isGreaterOrEqual: command not found
>javac -classpath /usr/local/java/lib/classes.zip:. Constant.java
>/usr/local/java/bin/../bin/checkVersions: {isGreaterOrEqual: command not found
>javac -classpath
That was an error in the checkVersions script. It turns out that
in bash 2.x you do not want the space but in bash 1.x you do.
I have fixed that by using a different syntax - rather than {isGre}
it now uses ( isGre... )
(Yes, with spaces this time too...)
This is rather archane and is really a problem that bash is inconsistant
between 1.x (which is on RedHat and most others) and 2.x (which is on
SuSE 5.2 at least) I would think more compatibility problems would
be already showing up with that difference.
We are releasing a v5a version of the 1.1.6 JDK but it turns out that
JDK 1.1.7 is almost ready to be released (actually it is, just the
readme needs to be updated) and the 1.1.7 release adds a major feature
for glibc systems - a native threads package! (not supported in libc5)
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
JDK 1.1.7 for x86 Linux
Your Blackdown Java-Linux porting group would like to announce that the JDK 1.1.7 should now be available. The big surprise is that we now have a native threads add-on package for it too. (Thanks to Phill) Make sure you read the README.native_threads for some details as to what to expect. (It should be in the same directory as the tar.gz files for the JDK, JRE, RT, and i18n...) Note that the native thread support requires GLIBC systems since the threads package is GLIBC based. Check out http://www.blackdown.org/java-linux.html I have noticed that some of the mirrors already have the files. All of them should have them soon. 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
Re: Java SDK
On Fri, 06 Nov 1998 14:53:24 -0500, Poynter wrote: >Hi, you'll havew to excuse me, but I'm rather new to Linux. I followed >the steps given with the JDK, but have still not been able to get it to >work properly. Here is what I did: > >1) Extracted it to /usr/local/jdk116_v5 > >2) Added the line > alias java='/usr/local/jdk116_v5/bin/java' > to my .bashrc > >3) However when I type "java" or go directly to the >/usr/local/jdk116_v5/bin and type "java" I get this: > >ls: not: No such file or directory >/usr/local/jdk116_v5/bin/../bin/i586/green_threads/java: can't resolve >symbol '_Xglobal_lock' >/usr/local/jdk116_v5/bin/../bin/i586/green_threads/java: can't resolve >symbol '_XUnlockMutex_fn' >/usr/local/jdk116_v5/bin/../bin/i586/green_threads/java: can't resolve >symbol '_XLockMutex_fn' This looks like you either do not have X-windows installed or you have an incompatible version of libc/glibc mix. If you do not have X-Windows installed and only want to do STDIO Java work then you can set the NS_JAVA environment variable. This lets Java run without the AWT addons. If you have the wrong mix of libc/glibc (as in libc5 system and a glibc version of the JDK) you need to get the "other" one... 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
Re: Which version of linux on which is JDK compiled?
On Sun, 01 Nov 1998 18:26:43 +0900, SHUDOH Kazuyuki wrote:
>[EMAIL PROTECTED]("Michael Sinz") wrote:
>
>> >What platform on which does binary distribution of JDK
>> >for linux compiled? Which version of linux kernel?
>
>> On x86 we use the production kernels since most users will
>> be using such kernels. Other platforms may use other
>> kernels.
>
>On other processors, e.g. Alpha, PowerPC and SPARC,
>what version of kernel is used generally?
>What platform on which does binary distribution compiled?
The PowerPC group tends to use a relatively new 2.1.x (2.1.100+)
kernel. There are some fixes that are in the kernels and the
glibc that are needed there.
I don't know about Sparc but I would guess that it is RedHat
based given the RedHat support for the Sparc.
The Alpha work I will be doing will be stable kernel based as much
as possible (such as 2.0.35, which is what I am currently running)
The base system started out as a RedHat 5.0 distribution but has
been updated with many things since then.
The JDK 1.1.7 v1a release was compiled for glibc on a 2.0.35 kernel
with RedHat 5.0 (plus lots of updates) The libc5 was build on a
rather generic SuSE 5.2 distribution with only minor upgrades.
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
Re: Low level disk access
On Wed, 11 Nov 1998 10:40:52 +, [EMAIL PROTECTED] wrote: >While this is not directly a Java question does anybody know of any >library functions etc which will provide low level disk access to >harddisks. i.e sector access etc. > >I am looking at writing a Java class for providing direct access to a >dedicated harddisk so that I can avoid some of the overhead of Java and >normal filesystem based disk access. Sorry, but when I read this I laughed a bit... In any reasonable filesystem (ext2 on Linux, HPFS on OS/2, etc) you get very good performance - and if you are controlling this from Java, going directly to the hard drive just seems a bit, well, funny. I do not know of any libraries for Java that provide low-level disk access. Using JNI (Native Methods) you could write those routes in another language (C is the easiest) and then use them from Java. 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
Re: Getting jre to run...
On Wed, 11 Nov 1998 09:57:38 -0500, Jon Allen wrote:
>I have installed the package jre_1_1_7-v1a-glibc-x86-native_tar.gz on my
>RedHat 5.1 system. In keeping with the new UNIX standard, I made a
>/usr/opt directory (with the symbolic link to /opt) and installed the
>package.
>
>I put the jre in my path. When I type 'jre' I get "Could not locate Java
>runtime".
Do you have any environment variables (such as JAVA_HOME) set?
JAVA_HOME is a common problem.
The other problem could be due to having the wrong libc/glibc version
of the JRE. Since you are RedHat, you should make sure you have the
glibc version (glibc also happens to work the best)
>I have tried to copy the rt.jar file from the NT version of the jre because
>it appeared to be missing from the tar file.
Which tar file did you use? I just tried the jre_1.1.7-v1a-glibc-x86.tar.gz
file that we built and "tar -zxf jre..." and then made the jre117_v1a/bin
directory part of the path and typed "jre"
>Although the idea of Kaffe being Java in RedHat 5.1, I prefer Java that is
>closer to the SUN standard. (Besides I could not get Kaffe to work.)
You may wish to check that the jre command is the one you think it is.
which jre
should return the file .../jre117_v1a/bin/jre
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
Re: classes.zip
On Thu, 12 Nov 1998 14:33:50 PST, alex andrejin wrote: >hi! could somebody tell me where i can get the classes.zip for linux? >they are not included in the linux jdk nor jre. > >i realize it is a very basic question but i have found no docs to help >me. & i apologize in advance for cluttering the list w/ goofy questions. Yes it is included in the JDK/etc. If you have tar -zxf the file the current version would be in: .../jdk117_v1a/lib/classes.zip 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
Re: Retrieving a fully qualified hostname under NT
On Fri, 13 Nov 1998 10:01:30 -0800, Christopher Hinds wrote: >Try using a reverse DNS lookup with that host's IP address , you should >get >a fully qualified host name from that. This obviously means you will >have to use the DNS protocol on an open socket. The problem with NT is >it is using >WINS ( NT DNS) to resolve the name and that name returned is a host name >known to the NT Promary Domain controller and the WINS Service. >Mark Hofmann wrote: You should not need to do that much work - the JVM will do it for you when you give InetAddress an IP address and then as it for the host name. However, you are correct, the machine would need to be in DNS to support this. Note that if you are not DNS named, a fully qualified name will have little meaning. 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
Re: Deprecated `Thread.stop()' in forthcoming JDK 1.2. Why?
On Fri, 13 Nov 1998 15:15:29 +, [EMAIL PROTECTED] wrote: > I read somewhere that Thread.stop() is now deprecated. Now how on > earth do we stop a thread ? > I thought the solution would be Thread.interrupt() > but that only works when the thread is sleeping, at least in JDK 1.1 > documentation. > > I do not have the JDK 1.2 to hand, and I have started use multiple > threads in Swing/JFC/. It seems to be idiocy to have a start method > and not have a stop method. The stop() method justs halts the thread > object and the garbage collector collects any rubbish. > > Thoughts? There are reasons for some of the thread changes, mainly that the JVM can not control the threads as well on native threading systems (even more so when the thread is maybe running on another CPU) There would be far too much overhead in normal operation. You can implement your own thread operations but you would then need to have the overhead only in those cases. (It also will have the same problems with multi-processor/native thread operations and the like but if you really want a harsh stop(), it may be the only way) I too like the feature but it is easy enough to have your own notification. A harsh stop may not be able to control what is happening at the moment or it would have to only check at certain points within the operations. 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
Re: Reusable threads?
On Fri, 13 Nov 1998 11:20:36 -0500 (EST), Michael Thome wrote: >Now that we have the option of native threads, I'd like to start using >thread resource pools. But, the Java semantics and/or the >implementation appears to make it problematic with regard to >applications without a known exit condition... here's my problem: > >I want my application to exit when all computation is done - for >purposes of discussion, consider a fractal image generator which uses >threads to farm out work. > >Let's say I create a pool of 10 threads to do the work: > >If they are normal threads, the threads in the pool need to be in a >wait state (e.g. when idle) - but waiting (or interrupted) is still >active, so the vm will not exit even when all the threads are idle. > >If they are daemon threads, the VM will likely exit too early, because >running daemons alone aren't enough to keep the VM alive. > >I want to write my thread pool as a generic class, so I want to avoid >introducing an otherwise external sync point (work all done) to >actually kill the threads in the pool at job completion time. I have a generic thread pool class that works for me. It is not complete for public use (yet) but it does the job. It knows when it has no threads in use. It also dynamically expands as peak loading increases. The trick is that you need a "front-end" class to the thread class and then a class that manages the set of threads. 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
Re: jar
On Tue, 17 Nov 1998 13:07:03 -0500 (EST), [EMAIL PROTECTED] wrote:
>
>Is anyone else experiencing trouble with jar?
>
>When I run jar -t jarfile.jar
>
>it just hangs...
>
>I've tried it on more than one jar file
Well, you need to use
jar -tf jarfile.jar
Doing just "jar -t" will tell jar to read stdin for the
jar file itself - such as:
cat jarfile.jar | jar -t
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
Re: My Audio Problem was a permission issue: can't setuid .java_wrapper
On Wed, 18 Nov 1998 19:44:06 -0700, Chip Grandits wrote: >[EMAIL PROTECTED] wrote >> >[EMAIL PROTECTED] (and others) were very helpful Much Thanks. > >I would like to post this quick summary of what I have learned: [...] >The problem was related to my attempt to setuid to appletviewer >This is really a symbolic link to .java_wrapper >However .java_wrapper is a shell script, and setuid does NOT work on scripts. >(I here there are exceptions for perl?) > >For now I've taken the quick and dirty 'Number of the Beast' solution >chmod 666 /dev/audio If you really are worried about audio device access, you can make a group and make /dev/audio (and what it links to) 660 and part of that group. Then you make all of the user accounts that can play audio part of that group and you have it. >I assume the actual files which should be setuid are tucked away in (for 1.1.6 >at least) >$JAVA-HOME/jdk1.1.6/bin/$ARCH/green_threads >(for me $JAVA-HOME is /usr/local and $ARCH is i586) Ahh, but suid does not magically make the program run as such unless it also makes the calls to do so. Plus, this would be a rather foolish thing to do since it would mean that all Java programs now are running as root just so that they can have access to audio. (Burn down the barn because you don't like the mouse in it...) Using groups is a much better way (and audio really is not that critical of a system resource that one would worry about something getting access to it - having all Java programs running as root would be...) 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
Re: jdk_1.1.7-v1a missing headerfiles
On Thu, 19 Nov 1998 18:16:30 -0600, Robert C. Pettengill wrote: >jdk_1.1.7-v1a-glibc-x86-native.tar.gz >is missing most of the headerfiles in the inlude directory. >We have a jni app that needs them. Are they unchanged from 1.1.6 or >unchanged form the Solaris versions? You need to use jdk_1.1.7-v1a-glibc-x86.tar.gz along with the native threads package. The native threads package is just an "add-on" to the "traditional" JDK. (No need to download the same thing more than once...) 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
Re: Deprecated `Thread.stop()' in forthcoming JDK 1.2. Why?
On Mon, 23 Nov 1998 09:47:39 +0300, Pavel Tolkachev wrote: >> Right. Sleeping and blocking I/O are interrupted by the interrupt >> mechanism; when this happens, the I/O methods and the sleep method >> throw an appropriate exception that tells you it is interrupted. > >I/O methods do not throw, at least not on NT Sun's JDKs and API >documentation does not state they must. Sorry for repeating posting but >this is my test case from message posted earlier to this thread. Please >try it on Linux with native threads if possible: > >- >Well, as my testing has shown even stop() function does not stop thread >waiting IO (I tested on NT Sun's JDK 1.1.7 though). I do not feel it is >thread API design disadvantage; sooner it is drawback of java.io API. My >common sense tells me: there is no way to stop thread "in correct >manner" if it has no provisions for this. InputStream makes you to poll >available() function for non-blocking read. Probably my testing code >will give you some assistance in your problem: It is hard to have stop() work during blocking I/O on native threaded systems since the native threading and I/O blocking may not have a way to cleanly "break" out of the blocked I/O state. The only option may be to kill the process (or thread) at a OS level and thus you would have a problem of not being able to clean up. The whole Thread.stop() thing is very nasty in non-green-thread systems. The core OS may not support the needed mechanisms to cleanly stop a thread at various points (such as during a blocked I/O) 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
Re: Deprecated `Thread.stop()' in forthcoming JDK 1.2. Why?
On Mon, 23 Nov 1998 08:45:29 -0500 (EST), Nelson Minar wrote: >>The whole Thread.stop() thing is very nasty in non-green-thread >>systems. The core OS may not support the needed mechanisms to cleanly >>stop a thread at various points (such as during a blocked I/O) > >URGH! So the entire Java language is weakened to support OSes with >poor threading support. Even *after* we have a library, green threads, >that lets you work around bad threading in the OS? > >Not being able to stop a thread preemptively is a really big problem. >How do you stop an applet in a browser that happens to be buggy or >malicious and has spun off in a tight loop? That is less of a problem - If you are killing a rouge applet/process you just do that. That is, you kill it without reguard. However, it is nearly impossible to make the language cleanly support an arbitrary "stop" of a thread. The code that is being stopped needs to know and, maybe do some cleanup or other very important work. It is much the same reason as you have interrupt disable in the CPU. There are times you really do not want to be interrupted. And it is also why most systems really do not like using the NMI (non-maskable interrupt) since it tends to make it impossible to know for sure that the system will be reliable then. 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
Re: java/Netscape question
On Tue, 24 Nov 1998 13:58:23 + (GMT), Matt Zagni wrote: >Hi, > >Is it possible to remove the Save, Send page, Send and View Page Source >options from a browser when viewing a page so that the page is totaly >secure ? Not really. The page *has* to be visible to the browser so that the browser can render it. As such, if the user can get to the page, it can be viewed freely. If the page is secured on a secure server, it at least can require that the user has access rights to the page and that the user is who he says he is but again, if the user sees the page, the page source is available, by definition of how the browser works. 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
Re: Netscape/CLASSPATH question
On Tue, 24 Nov 1998 13:37:12 +, Mike Song wrote: >It will do if I remove MOZILLA_HOME and CLASSPATH >from the .bashrc file (so they are not defined). It sounds >strange but it works somehow. Actually, it is documented in Netscape's readme that the browser's JVM looks at CLASSPATH if defined and will *only* look there for its own classes. If it is not defined, it will look at the directory where the binary lives to find the jar/zip files. What I did was to make a netscape script file that lives in /usr/local/bin that unsets CLASSPATH, just in case it was set, and then runs the netscape binary (thus the netscape binary is not actually in the path) This makes it work perfectly. Why Netscape does not look for its classes in the binary directory *after* it has looked at classpath is beyond me. It is so silly that the user's added classes and jar files must then also include the application's files. (Just like the silly -classpath option in the JDK) The application's/JVM's required classes should always be added to the end of the classpath the user sets. If the user is replacing some/all of the classes, it will never find the ones later on, and if the user is not replacing them (usual case) the system will then find its required classes. CLASSPATH, as it is currently implemented by various JVMs, JDKs, and browsers is, IMHO, one of the most confusing, broken, and expensive problems in Java (expensive in the cost of support and the like) Just look at how many times people have problems with this in a reasonably technical group like Linux. 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
RE: CLASSPATH confusion
On Wed, 25 Nov 1998 07:38:11 +0200, Jaco Greeff wrote:
>> Having it "fixed" in 1.2 won't help us
>
>Sorry for the total ignorance, but I've been hearing a lot about the
>CLASSPATH that doesn't need to be set in 1.2. Is this true? Where does
>"java" (1.2) look for the jar/zip/class files then? Or will it still need to
>be specified?
>
>Ok, doesn't have anything to doe with our port in general, but could
>somebody please clear this up? (I'm sure I'm not the only confuzzled person
>around here...)
Actually, in JDK 1.1, CLASSPATH does not need to be set to get the core
Java classes.zip file. The Java wrapper does that.
Also, the CLASSPATH env variable can also be set to just your own path
extensions and that will work too since the JDK will find its own classes.zip
Both of these are reasonable but the behavior of the -cp/-classpath option
*replaces* not just the CLASSPATH env variable but also the default that
the wrapper script would define and thus using that option requires that
you add in the classes.zip file, something the user should not need to
deal with.
Jikes has "yet another problem" in that it needs to know where the JDK
classes.zip file is in order to load it.
What I have done for our engineers is to state that "CLASSPATH is only to
contain local added classes" and we normally just have it set to "./obj:."
which lets us store the *.class files outside of the source tree.
All of the tools should then know how to add any tool-specific class paths
to that variable before running. The JDK tools already do this. For the
Jikes compiler I have a front-end script that does:
export CLASSPATH="${CLASSPATH}:/usr/Java/JDK/lib/classes.zip"
For the Jikes debugger, I add in the debugger classes and then call the
normal JDK Java wrapper which adds the classes.zip file.
This way, if classpath is not defined, it works as before. If classpath
is defined, I add to the end what the tool knows it will need and *if*
the user happened to want to replace part of that, the user's settings
come first.
The other thing that would be good is a standard place to put jar/zip files
(or links to them) such that you do not need to keep adding them to the
classpath in *user* space. That is, the user's environment should not
need to define things that are required definitions for the system to
operate. (Such as where classes.zip is for the JVM since it generally
does not make sense to use Java without it)
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
RE: CLASSPATH confusion
On Wed, 25 Nov 1998 14:28:53 +0200, Jaco Greeff wrote: >> Actually, in JDK 1.1, CLASSPATH does not need to be set to >> get the core Java classes.zip file. The Java wrapper does that. > >Ok. That makes sense. I actually found this out without even trying and was >quite surprised! > >> The other thing that would be good is a standard place to put >> jar/zip files (or links to them) such that you do not need to >> keep adding them to the classpath in *user* space. > >That would be great! This is actually what I meant in my original >question... It is starting to get quite a mission adding a jar/zip/path to >your path just to try things out. If the java wrapper could read (with >links) all the jar/zip/class files in "jdk/lib/usr" or some path like that >it would be great and save a lot of trouble. The problem with the approach >obviously is that ALL the classes will get loded into memory... , not >good. (The wrapper obviously knows to read the classes.zip file from >"jdk/lib", so why not the user classes?) It is not that simple - especially if some of the jar/zip files have replacement classes (such as some debuggers have) for the classes.zip file. WHat is the order of the files? Anyway, I think it is easily doable for UNIX systems using symbolic links into a directory and having them encode in the ordering (like the rcX.d directories do) but this is not a solution that can be done for "Java" since not all Java systems run on Unix. (One rather important system, Windows, does not even support softlinks in the OS at all - don't count the GUI "links" - and WindowsNT supports hardlinks but by default the user has no way of making those since you need the NT resource kit to get the "ln" command.) Anyway, Sun has been working on this for JDK 1.2 - I just hope that the solution does not have yet another case of "almost" there. (The 1.1 JDK almost had it except that the -classpath option does not append the required classes.zip file and thus if you use that you need to find classes.zip and put that into the -classpath option and... It is just a mess.) 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
Re: JDK-1.1.7.1a Installation: missing libXm.so.2
On Mon, 21 Dec 1998 15:02:39 +0100, Jean-Michel Paris wrote: >I've downloaded the latest jdk on libc6 linux based system: >jdk-1.1.7.1a-2glibc.i386.rpm. > >But when I tried to install it, I got the message that jdk has need of >libXm.so.2 >Ok, I went to the latest lestiff release, and I was only able to get a >libXm.so.1.2 >(lesstif is Motif-1.2 complient + stuff of 2.0). I don't know who built the JDK RPM, but the JDK does not need libXm.so.2 to run since it is statically linked with the MetroLink Motif 2.1 release. Now, when running the dynamic (DYN_JAVA=true) version, then it will need that library. You should be able to install the JDK just fine and run it in its normal configuration. (Note that if the RPM does not include the statically linked JDK you may wish to grab the tar archive which does include the fully release.) 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
Re: jdk117_v1a glibc x86, where are the classes?
On Tue, 29 Dec 1998 10:06:47 -0700, Dale Carstensen wrote: >Hello folks, > >This is on Red Hat 5.2 plus the December 16, 1998, errata updates. > >I untarred jdk-1.1.7-v1a-glibc-x86-native.tar.gz (from the infomagic mirror.) >Contrary to the README, the guts are not in ./jdk1.1.7, they are in >./jdk117_v1a, and there are intervening sub-directories under bin, include >and lib, too (i686/native_threads for bin and lib, native_threads for include, >but then include only has one file anyway.) The Native Threads archive is just an add-on to the standard archive. This is why there seems to be minimal information in the directory. The directory name has changed each time we do a new version - I guess we missed getting them all updated in the readme files. Sorry about that. Note that the readme should tell you that the native_threads archive is just an "add on" to the standard green_threads archive. There are many things that only exist in the base archive that are needed in addition to the native_threads package. >From the README.linux file: -- Native Threads support -- Starting with the 1.1.7 v1a port of the Java Virtual Machine, we have added native thread support. Traditionally, the JVM used user based threads, also known as "green" threads. Native threads, on the other hand, use the operating system to do the task switching. Native threads are thus a benefit in multi-processor (SMP) systems and they tend to make native method invocation support easier to deal with. Native threads do have some limitations relative to green threads. They require more overhead and are limited to the number of processes your Linux kernel supports. Native thread support is new as of 1.1.7 v1a due to the wonderful effort of Phill Edwards. To install the native threads package, you need to first download the JDK, JRE, or RT and install that. Next, you need to get the matching native threads package and install that into the same location. Finally, to use the native threads version of the JVM, you need to set the THREADS_FLAG environment variable to "native" Note, that while the native threads support works very well and has been tested by the Java-Linux porting team, it should still be viewed as "beta" code as it has not had the extended testing that the green threads code has. Also, at this time there is no native threads support for libc5 systems. Only glibc based Linux systems. -- [...] >So, why does the 1.1.7 README (release notes) not match reality, at least >for the infomagic mirror? Where are the missing Thread and JavaP classes for >1.1.7 and whatever version (how can I tell which version it is) comes with >RH5.2? Do I not have the threads support that native threads requires (how >can I know whether I have it?) Sorry about the naming thing. We had changed things a number of times and with a number of people writing the README file it just did not work out very well. We should try to get all of the wording looked over again. However, the readme does specifically tell you that you need to download either the JDK, JRE, or RT in green thread format and then add on the native threads package for that. >Oh, and what is the purpose of the jre and rt tar files? And does the >common directory, with its diffs.gz file (which isn't compressed, at least >not the infomagic mirror copy), have anything to do with 1.1.7? It appears >to me to be diffs from Sun's source, which I guess isn't publicly available Well, the RT package is just the run-time without the international UNICODE support. The JRE is basically the RT plus the I18N files. The JDK is the JRE plus all of the code needed to develop java programs in addition to running them. For more details as to the differences, see the Sun readme files. 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
Re: ISO libstdc++-2.8 (to make jikes happy)
On Fri, 1 Jan 1999 19:13:12 -0700 (MST), Robert Dodier wrote: >Hello all, > >Happy new year! > >I would like to run jikes on my RH 5.0 linux box, but jikes wants >libstdc++-2.8, while the current rpm contains libstdc++-2.7 and ...-2.9, >but not 2.8. :( You should be able to get the Jikes libc5 version or download the source to Jikes and compile it locally. The glibc version is RedHat 5.2 with egcs compiler and not statically linked with the libstdc++ >On a related note, perhaps jikes should be bundled with the libstdc++ >which it wants; I symlinked 2.8 to 2.9 and jikes dies with a "symbol >not found." Is it usual for apps to be bundled with specific library >versions, or more usual that they aren't? Well, it is usually not nice to bundle an application with all of the libraries it needs since it just takes up disk space. Much of the point of shared libraries is to reduce download time and disk space and in-memory space and ease of fixing problems in the library. However, it also means that you have problems with library versions and incompatibilities. Yuck. 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
Re: subscribe
On Mon, 4 Jan 1999 15:24:26 -0500 (EST), Patrick wrote: >Is there anyway I can force the runtime from the blackdown port to read >the CLASSPATH variable? > >I am having trouble getting the JMF working w/o appending the command >line. I think that is also the reason that Netscape isn't working with it, >based on the JMF diag page from sun. It does read the CLASSPATH variable. But the standard for the JRE is that if you use the command line classpath option it *replaces* anything that is in the CLASSPATH variable. This is "as per Sun" (And again I wish CLASSPATH would not have been so poorly implemented) 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
Re: subscribe
On Mon, 4 Jan 1999 15:48:32 -0500 (EST), Patrick wrote: >Well, running 1.1.6 CLASSPATH doesn't work. At all. Its all set up to >point ot classes.zip and 2 JMF jar files. if I put it in command line >(java -classpath $CLASSPATH CLASS) it works geat. Strange. What "java" are you running? (As in, what is returned from "which java" ?) Given that you can put CLASSPATH right there it looks like it is set up correctly (as far as syntax) but could it be that you did not "export" the CLASSPATH variable? (in bash: "export CLASSPATH") Variables that are not exported are only visible from the current shell, not any other shells, including sub-shells. >But, netscape doesn't want to see any of it. Any hints? Well, for the silly Netscape thing I have a shell script called "netscape" that is what really runs netscape and it cleans out any of the variables that should not be there and then runs the correct version of the netscape binary. 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
Re: What are four different packages for ?
On Tue, 05 Jan 1999 14:18:15 + (GMT), Philip Nelson wrote: >On the Blackdown web / FTP site there are four packages - > >I18N >JDK >JRE >RT > >Which do I need. and what are they all ? > >My guesses are - > >JDK - Developer's Kit (includes JRE) >JRE - runtime environment (for distribution) >I18N - internationalization (do I need to install on top of JDK / JRE ?) >RT - no idea Close - very close: RT == Run Time - this is the basic Java run time. I18N == Internationalization - add this to the RT to get: JRE == Run Time + Internationalization JDK == Developer kit + Run Time + Internationalization. If you ship a Java product you can *not* ship the JDK with it. You *can* ship the JRE or RT (and I18N) with it. 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
Re: Is this a JVM bug? Why is my local variable not initialized?
On Wed, 06 Jan 1999 15:13:51 +, Richard Jones wrote:
>
>Can someone tell me why this program, when run under
>Linux, prints d = 0 (ie. the variable d isn't being
>initialized as expected)? According to Bruce Eckel's
>book, which is the only reference I have available to
>me, d should be initialized to 1, so I suspect this
>may be a JVM bug ...
Actually, this is where the "how do I run first" problems
happen.
The thing is that until super() is called *and* returns,
the object is not complete - as in storage for it has
not even been allocated, etc. So, when you have the
constructor in you "SuperClass" calling the method, the
constructors in the "DerivedClass" have not yet had a
chance to run. They can not run before super() is called
since they need the object to exist before they can store
any data into the object. Thus, they run after super()
returns.
There are limits to what could be done in the object.
And, there is no way to get around this unless you build
a system that lets each class run before and after each
other class in an object.
>-
>/* SuperClass.java */
>
>public abstract class SuperClass
>{
> protected SuperClass ()
> {
>method ();
> }
>
> protected abstract void method ();
>}
>-
>
>-
>/* DerivedClass.java */
>
>public class DerivedClass extends SuperClass
>{
> public int d = 1;
>
> public DerivedClass ()
> {
>super ();
> }
>
> protected void method ()
> {
>System.out.println ("d = " + d);
> }
>
> public static void main (String[] args)
> {
>DerivedClass derivedClass = new DerivedClass ();
> }
>}
>-
>
>$ java -version
>java version "1.1.6"
>$ java DerivedClass
>d = 0
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
Re: [email protected]
On Mon, 18 Jan 1999 11:12:59 -0800 (PST), hackit usolame wrote: >hey >i did all what u told me , but its still not work (i added the path >line to >my profile) , and now i can execute the /jdk1.1.5/bin from every >directory >: but its still giving me error message well , this is the error >SecMgre:/jdk1.1.5/bin#./java (this is the command that i executing > i can >execute it from every directory , because i added /jdk1.1.5 to the >path in the >profile file) >: and this is the error >java: /jdk1.1.5/bin/../bin/Linux/green_threads/java:No such file or >directory/. >java: /jdk1.1.5/bin/../bin/Linux/green_threads/java:No such file or >directory/. Something is strange here. Your system seems to returning "Linux" as its CPU type. If you note in the bin and lib directories, there is a directory for each of the CPU types you have installed. This lets you share more of the JAVA directories with multiple CPU platforms and just have the actual binaries be CPU specific. (Sun does this for the x86 and Sparc builds on Solaris, for example) Anyway, the wrapper script is somehow trying to use a CPU type of Linux rather than, say, i386 (386), i486 (486), i586 (Pentium), or i686 (PII/PPro) 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
Re: Reading from the Keyboard
On Tue, 19 Jan 1999 21:20:07 +0100, Sven Ruppert wrote:
>Hi,
>I have a problem.. (my english is too bad)
>so I try it in german
>Also ich habe folgendes Problem...
>Ich will schlicht und ergreifend die Tastatur
>einlesen. Ein Synonym für ReadLn(); unter Pascal.
>Meine Suche brachten mich zur Methode readUTF.
>Ist die Richtung OK ?
>Es wäre super wenn mir jemand einen
>DemoQuelltext schicken könnte.
Here is a simple loop that will read from STDIN and
then output each line back out to STDOUT.
import java.io.InputStreamReader;
import java.io.BufferedReader;
...
BufferedReader input=new BufferedReader(new InputStreamReader(System.in));
String data;
while ((data=input.readLine()) != null)
{
System.out.println("--> " + data);
}
This will do all of the locale correct work and for each line
of input, will echo back the line with "--> " pre-pended to it.
It exits at EOF or a thrown exception :-)
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
Re: port information
On Wed, 20 Jan 1999 12:53:18 -0500 (EST), Patrick W. O'Neill wrote: >I was wondering if your port was supported by Sun in any way. The reason >I'm asking is because I need to perform some benchmarking, and if I could >do it all on a linux system it would make my life much simpler, however, I >want to make sure the numbers for Java are an accurate representation of >Sun's JVM (mainly in thread performance), so I didn't want to use >something like Kaffe. Thanks for any information. Our port is based on Sun's code (we have a source license from Sun) However, threading is very dependant on a number of things. 1) Native threads are very dependant on the OS and the interface the OS provides for the threads. For example, on OS/2, you will see much higher threading performance than on, say, Windows. Solaris also has much higher threading performance than Linux. 2) Green threads depends on the JVM to switch between threads internally. This depends on the quality of the library code for green threads and the OS support for sync signals and the like. (select() and poll()) Windows would do rather poorly in such an environment. Most good unix implementations should do rather well. Now, the Linux port had to do lots of work to get Native threads to work in the Linux threading model. And the Green threads also took some work due to some library routine issues. (and the lack of poll() in the kernel.) 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
Re: CLASSPATH problems.
On Thu, 21 Jan 1999 14:50:06 +0530 (IST), Karthik Vishwanath wrote: >Hi all, > i use magician with Java as on openGl implementation. I >have the jdk1.1.7 running on Linux RH5.1. Magician requires that i have a >CLASSPATH set. The current value of my CLASSPATH is: >/data/karthik/magician/classes. If I compile a program which uses some >magician classes, the program compiles fine. But, on trying to execute it >with java solarSystem; i get the following error: "Can't find class >solarSystem". The file solarSystem.class *does* exist in my 'pwd'. can >anyone shed some light on what i must do? Since you have CLASSPATH set, you may wish to put "." in you CLASSPATH so that things in the 'pwd' are also loaded. 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
