Re: Startup problems
You need to get the newest glibc (2.0.7-x) RPM from RedHat. Also, it's NOT important to compile the kernel for Java binaries; you only need to do this if you don't want to type 'java HelloWorld' and just 'chmod a+x HelloWorld.class ; HelloWorld.class'. Without kernel Java binary support, 'java HelloWorld' works just fine. --troy On Tue, 7 Jul 1998, Michael Ash wrote: > I run RedHat 5.0, and I am using the glibc version of jdk. Also, I assume > it's important to compile the kernel for Java binaries? I did this. > > Per request, here is the output of ldconfig -D > > /sbin/ldconfig: version 970402 > /usr/i486-linuxaout/lib: > libvga.so.1 => libvga.so.1.2.7 > libtk.so.3 => libtk.so.3.1.1 > libtcl.so.3 => libtcl.so.3.1 > libm.so.4 => libm.so.4.6.27 > libdb.so.1 => libdb.so.1.85.1 > libcurses.so.0 => libcurses.so.0.1.2 > libc.so.4 => libc.so.4.7.2 > libXt.so.6 => libXt.so.6.0 > libXt.so.3 => libXt.so.3.1.0 > libXpm.so.4 => libXpm.so.4.2 > libXaw.so.6 => libXaw.so.6.0 > libXaw.so.3 => libXaw.so.3.1.0 > libXIE.so.6 => libXIE.so.6.0 > libX11.so.6 => libX11.so.6.0 > libX11.so.3 => libX11.so.3.1.0 > /usr/i486-linux-libc5/lib: > libvgagl.so.1 => libvgagl.so.1.2.11 > libvga.so.1 => libvga.so.1.2.11 > libtermcap.so.2 => libtermcap.so.2.0.8 > libstdc++.so.27 => libstdc++.so.27.1.4 > libpanel.so.3.0 => libpanel.so.1.9.9e > libncurses.so.3.0 => libncurses.so.1.9.9e > libmenu.so.3.0 => libmenu.so.1.9.9e > libm.so.5 => libm.so.5.0.6 > libg++.so.27 => libg++.so.27.1.4 > libform.so.3.0 => libform.so.1.9.9e > libc.so.5 => libc.so.5.3.12 > libXtst.so.6 => libXtst.so.6.1 > libXt.so.6 => libXt.so.6.0 > libXpm.so.4 => libXpm.so.4.9 > libXmu.so.6 => libXmu.so.6.0 > libXi.so.6 => libXi.so.6.0 > libXext.so.6 => libXext.so.6.3 > libXaw3d.so.6 => libXaw3d.so.6.1 > libXaw.so.6 => libXaw.so.6.1 > libXIE.so.6 => libXIE.so.6.0 > libX11.so.6 => libX11.so.6.1 > libSM.so.6 => libSM.so.6.0 > libPEX5.so.6 => libPEX5.so.6.0 > libICE.so.6 => libICE.so.6.3 > /usr/X11R6/lib: > libXpm.so.4 => libXpm.so.4.10 > libXtst.so.6 => libXtst.so.6.1 > libXt.so.6 => libXt.so.6.0 > libXp.so.6 => libXp.so.6.2 > libXmu.so.6 => libXmu.so.6.0 > libXi.so.6 => libXi.so.6.0 > libXext.so.6 => libXext.so.6.3 > libXaw.so.6 => libXaw.so.6.1 > libXIE.so.6 => libXIE.so.6.0 > libX11.so.6 => libX11.so.6.1 > libSM.so.6 => libSM.so.6.0 > libPEX5.so.6 => libPEX5.so.6.0 > libICE.so.6 => libICE.so.6.3 > libXaw3d.so.6 => libXaw3d.so.6.1 > libMagick.so.3.9 => libMagick.so.3.9.1 > /usr/lib: > libtk8.0.so => libtk8.0.so > libtkx8.0.0.so => libtkx8.0.0.so > libtclx8.0.0.so => libtclx8.0.0.so > libtcl8.0.so => libtcl8.0.so > libvgagl.so.1 => libvgagl.so.1.2.11 > libvga.so.1 => libvga.so.1.2.11 > libreadline.so.3 => libreadline.so.3.0 > libhistory.so.3 => libhistory.so.3.0 > libmh.so.3.2 => libmh.so.3.2 > libtiff.so.3 => libtiff.so.3.4 > libpng.so.0 => libpng.so.0.96 > libjpeg.so.6 => libjpeg.so.6.0.1 > librle.so.1 => librle.so.1.0.0 > libppm.so.1 => libppm.so.1.0.0 > libpnm.so.1 => libpnm.so.1.0.0 > libpgm.so.1 => libpgm.so.1.0.0 > libpbm.so.1 => libpbm.so.1.0.0 > libfbm.so.1 => libfbm.so.1.0.0 > libstdc++.so.2.7.2 => libstdc++.so.2.7.2.8 > libg++.so.2.7.2 => libg++.so.2.7.2.8 > libgtk.so.1 => libgtk.so.1.0.0 > libglib.so.1 => libglib.so.1.0.0 > libgdk.so.1 => libgdk.so.1.0.0 > libgpm.so.1 => libgpm.so.1.11 > libgdbm.so.2 => libgdbm.so.2.0.0 > libexpect5.24.so => libexpect5.24.so > libopcodes.so.2.8.1.0.1 => libopcodes.so.2.8.1.0.1 > libbfd.so.2.8.1.0.1 => libbfd.so.2.8.1.0.1 > libpanel.so.3.0 => libpanel.so.1.9.9e > libncurses.so.3.0 => libncurses.so.1.9.9e > libmenu.so.3.0 => libmenu.so.1.9.9e > libform.so.3.0 => libform.so.1.9.9e > libz.so.1 => libz.so.1.0.4 > libnewt.so.0.20 => libnewt.so.0.21 > libslang.so.0 => libslang.so.0.99.38 > /lib: > libpwdb.so.0 => libpwdb.so.0.54 > libproc.so.1.2 => libproc.so.1.2 > libpam_misc.so.0 => libpam_misc.so.0.59 > libpam.so.0 => libpam.so.0.59 > libncp.so.1 => libncp.so.1.0 > libdl.so.1 => libdl.so.1.9.5 > ld-linux.so.1 => ld-linux.so.1.9.5 > libuuid.so.1 => libuuid.so.1.1 > libss.so.2 => libss.so.2.0 > libext2fs.so.2 => libext2fs.so.2.3 > libe2p.so.2 => libe2p.so.2.3 > libcom_err.so.2 => libcom_err.so.2.0 > libutil.so.1 => libutil-2.0.5.so > libresolv.so.2 => libresolv-2.0.5.so > libpthread.so.0 => libpthread-0.6.so > libnss_nis.so.1 => libnss_nis-2.0.5.so > libnss_files.so.1 => libnss_files-2.0.5.so >
Re: Cannot run java
That file is a shell-script; you could be getting the 'No such file or directory' error if an executable in the shell-script is missing (the first '#!/bin/*sh' command is a notorious offender). --troy On Fri, 24 Jul 1998, Clarence Johnson wrote: > When trying to run java, we receive the following message: > /usr/jdk1.1.6/bin/../bin/i586/green_threads/java: No such file or > directory
Re: Swing 1.0.3
On Mon, 19 Oct 1998, Miguel Mateos Lopez wrote: I have some problems with the file swing.jar. When I compile an example, the compiler returns errors. It doesn't find out included packages in swing.jar. CLASSPATH is OK. Are you putting the full classpath; i.e.: CLASSPATH=$CLASSPATH:/where/you/have/installed/swing/swing.jar and _NOT_ just CLASSPATH=$CLASSPATH:/where/you/have/installed/swing ?
RE: Open Java
On Thu, 5 Nov 1998 [EMAIL PROTECTED] wrote: | > Java Linux porting team politics. The folks who have donated their | > effort to bringing Java to Linux - all of them - have done a wonderful | > job. Thanks to you all! Agreed. | > >The big problem I have is the current closed porting method is only | > >related to Java today. This completely ignores all possibility of | > >advancing java when backward compatibility is not and issue. I think what I tend to (and other have shown to) think is that Sun is doing a great job of being the pointman for the Java specification. A simple reminder of the power of the "commodity specification" can be found in the now-ubiquitous "HALLOWEEN" email. What someone else has also pointed out is that Sun has not prevented anyone from implementing their own JDK. What Sun does not do is provide the source for their implementation. I think Sun _DOES_ want people to provide their own tools, albeit at their own cost. I think that Sun protecting it's source is legit, though it may be be "OSS"-minded. | > I'm not exactly sure what the poster has in mind, but it reminds me of | > one of my major problems with Java. Sun has a tight lock on what | > "Java" is, what the definition of it is. They don't seem very | > interested in having people hack up the VM or the language, or in | > general pushing Java in any future research directions they do not | > directly control. I think this is horribly short-sighted of Sun, and | > very frustrating, but that's their position (at least, as I see it.) | > | > Unfortunately, the JDK licensing terms reflect Sun's attempts to keep | > Java locked up. Without the Sun source, I believe the porting effort would be increased tremendously. I have no problem with a small group of developers having the only legal copies of the source; if you want to work on the project, aren't there ways of joining the devel group @ blackdown? | Let's be VERY clear on this point: they're keeping their IMPLEMENTATION locked | up. Not the specs for the language. You don't need a license to implement a | Java virtual machine and/or the class libraries. This is pretty rare in the | software world. Would you believe that ParcPlace claims ownership of the CLASS | HIERARCHY of Smalltalk, and actually threatens litigation if you don't pay | their (minimal) licensing fee? | | Sun has been quite reasonable with respect to having review and feedback cycles | for all new APIs -- ever hear of M$ doing that? They're trying to be as open | as they can be, in an ocean where sharks live. I agree with this. Although Sun does want as large a piece of the pie as possible (see MS), I tend to favor their methods more often. Public commercial source code release was unprecedented before the past year, with (I believe) the first significant commercial contribution by Netscape. Sun is right (IMHO) to keep the spec singular. This allows anyone to play with any part it and maintain interoperability (The Right Thing) among all the implementations.
Re: New user
Doesn't exist yet. www.sunsoft.com for details. --troy On Thu, 26 Nov 1998, Tobias ramos wrote: Hi there, people... i have 1 machine redhat 5.1 and need very very to install JDK 1.2.x but i dont found... anibody say to me where i find Thanx. Tobias Ramos Diamantina MG [EMAIL PROTECTED]
Re: JAVA/Linux problem
You need to append the directory containing David.class to your
CLASSPATH environment variable; e.g.,
export CLASSPATH=/some/dir/1:/some/dir/2:/your/class/dir
where /your/class/dir contains David.class.
--troy
On Fri, 27 Nov 1998, David House wrote:
I just installed the JDK on a RedHat 5.1 Linux machine. The javac seems to be
working fine, but when I try to run an application, it gives me the error Can't find
class 'whatever'. For example, here is my code
David.java:
class David
{
public static void main( String[] args )
{
System.out.println( "Hello!" );
}
}
I compiled it like:
javac David.java
running it like
java David
error message:
Can't find class David
If you need more information on the config, please let me know.
Thanks,
David House
Re: jdk1.2
On Mon, 30 Nov 1998, Singleton, Terry wrote: Is there any sense of when the JDK will be ported once 1.2 is released. I am Perhaps the best place to track JDK-1.2 development is at the Sun site since they have offered to port JDK-1.2 to Linux. somewhat new to Linux and Java so I have to ask this question: does the Linux port support the SWING API ? Will swing apps run in the CDE for Linux? Swing is written in java. What is the "CDE for Linux"? I'll assume that you're asking about the window manager for Linux. Swing has no run-time dependencies (though it's appearance and behavior may be slightly different...) on the window manager; however, CDE does not have a Linux port (to my knowledge). You'll want to look into KDE; otherwise, just use the wm shipped with your Linux distribution. --troy Stanford Nanofabrication Facility Senior System Software Developer http://www-snf.stanford.edu/
Re: setting up swing
On older versions, it was necessary to set SWING_HOME to the path to your swing installation (e.g., /usr/local/swing-1.1). --troy On Tue, 12 Jan 1999, Patrick wrote: You just need to set the CLASSPATH and export it in the bashrc and include the files for it. There are docs for it with it.
[email protected]
good, and Linux is a good enterprise platform. I'm also curious to know what sort of enterprise-level apps are exploiting Java on Linux -- is there more to enterprise Java than servlets? Definitely. We use java at the Stanford Nanofab for reservation, equipment, and other process and resource management. We're running CORBA servers on Solaris and Linux (orbacus with a modified IDL compiler). We also run CORBA clients on Linux. Performance is great. The servers stay up for weeks (i.e., they only go down when we shut them down for upgrade, bug fixes). CORBA is a really viable architecture for network-ready OSs. We wouldn't touch NT here --troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multi-Threading: Preemptive?
Moses, If I have two programs crunching FFTs (e.g.), then a preemtively multi-tasking OS can interrupt one process and run the other. Linux is such an OS. I don't think that it's wrong (e.g.) to run two threads concurrently, with at least one being CPU-bound. BTW, does anyone know if the native-threads impl solves this scheduling problem? --troy I do not mean to rip on your code or anything, but if you require a big hack like that then something must be wrong with the design of the program. Please do not take that the wrong way. Why exactly do your threads starve each other? Are they polling or something? Most of the time a polling process can be replaced by a signal based process and you will end up saving a lot of wasted CPU time. Just a thought. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: open, read, ioctl calls in java?
We've recently written a device driver (for Linux), and it uses ioctl(2). We use a separate C program which is also a BSD-socket server to drive the device at the user-level. The socket server is for Java apps which also need to use the device. If you want to use ioctl(2), you probably need JNI; even if the Linux port of the JDK supports raw ioctl (as a "feature"), it won't be standard. --troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK1.2 and CORBA
In case anyone's keeping track, I'm sending my thanks for the Java2 port. =) You guys are way cool We're using CORBA as distributed with Java2, and it's working perfectly. We have a rather large application using Swing (JFC), CORBA, JDBC, and multi-threading, and we're running servers (servant object instances) on Solaris and Linux. However, idltojava for Linux doesn't exist--as you well know--and I would advise others to use the idltojava as distributed for Solaris or WinBlows NT. Class files generated with other IDL compilers aren't going to play well with the JDK; we've tried using the Orbacus CDK, but compiled class files aren't usable with the JDK runtime. Conversely, jidl (Orbacus' IDL compiler for Java) compiled class files won't run with the JDK runtime. --troy On Tue, 23 Mar 1999, Francisco Figueirido wrote: First of all, many thanks for all the efforts! I have one question: I know JDK1.2 adds support for CORBA, and Sun distributes its own Java CORBA implementation. However (as always!), it distributes it for Solaris and Windows (ugh!). The Java classes are no problem, but one important piece is the IDL-to-Java compiler (idltojava). Do you have plans to provide a Linux version too? If not, what would you suggest I do to get one? Thanks in advance for any answer you might give me. Francisco Figueirido, Ph.D. Phone: (212)317-7680 Quantitative AnalystFax: (212)317-7601 Imagine Software, Inc. e-mail: [EMAIL PROTECTED] 400 Madison Avenue, 21st Floor New York, NY 10017 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CC/IT d@ s+:+>+: a-- C+++$ ULUVS$ UA++ UI+ UO P+ L+++$ E+ W+++$ N+(++) o? K? w---(++) O+ M(-) V-- PS+(++) PE Y+ PGP-- t++@ 5- X+ R* tv b++(+++)@ DI+++@ D+ G+ e-* h++*(---) r@ y++**>+$ --END GEEK CODE BLOCK-- [EMAIL PROTECTED] http://labnet.stanford.edu/~troywu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corba
On Tue, 23 Mar 1999, Chee Foong wrote: java code. You can look into the java code and you will realized that they will not be much more work converting idl to java code by hand. Actually, this isn't quite true. The _YourClassOperations.java files are rather simple--they are just interfaces which your implmentation must implement. However, the stubs and skeletons are not so simple, and rely upon the individual CORBA runtime implementation specifics. If you look at the output of the _YourClassStub.java files, you'll see that these files are non-trivial. Implementing your own behind-the-scenes runtime environment is not too bad, but you'll have to implement IIOP/GIOP by hand--and the spec is none too short. We almost went this route, but Blackdown saved me. =) Also, other CDKs don't generate names consistently, even with the OMG-defined Java-IDL mapping. I've had the priveledge of modifying the Orbacus IDL compiler to use the same names as idltojava in an earlier phase of our project, even though both the Orbacus CDK and Java2 claim to be standards compliant. While trivial, it takes a long, long time to build the whole Orbacus source tree. =) The OMG Java mapping has holes in the naming conventions. Futhermore, the JDK's CORBA runtime is not at all standards compliant. Error by omission, I believe, lacking the BOA interface (and quite possibly many other things that I just haven't worked with). This causes considerable headache when working with a compliant system. Just as a disclaimer, we're only working with CORBA 2.x, so the 3.x spec could make me obsolete To clarify, this isn't the fault of the Blackdown crew, but rather JavaSoft who didn't provide a complete CORBA API for the Blackdown guys to implement. --troy -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CC/IT d@ s+:+>+: a-- C+++$ ULUVS$ UA++ UI+ UO P+ L+++$ E+ W+++$ N+(++) o? K? w---(++) O+ M(-) V-- PS+(++) PE Y+ PGP-- t++@ 5- X+ R* tv b++(+++)@ DI+++@ D+ G+ e-* h++*(---) r@ y++**>+$ --END GEEK CODE BLOCK-- [EMAIL PROTECTED] http://labnet.stanford.edu/~troywu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK1.2 and CORBA
I'm not having a problem, really. The situation is that the output of idltojava compiler of CDK-A doesn't compile with CORBA classes of CDK-B (Corba Development Kit, that is =). Only runtime object instances are interoperable; not their source. *.java files generated by IDL compiled with JDK's IDL compiler won't compile with the ORBacus CORBA classes; i.e., with the CLASSPATH set with OB.jar in front of /app/jdk-1.2/lib/tools.jar. The opposite is also true. *.class files _ARE_ sharable, provided that the CDK which was used to compile the respective *.java files is in the CLASSPATH first. It boils down to the fact that JDK-1.1 works perfectly well with ORBacus, but try compiling the same code with the Solaris or WinBlows NT version of the JDK. If you have ORBacus, you don't need the CORBA support in 1.2, since it's a rather different flavor anyway and lacks the idltojava compiler. The CORBA support in Java2 (for Linux) is a blessing in our environment only because we're running the Solaris JDK's idltojava compiler and using the JDK's CORBA classes. Then, we take the IDL output (*.java file), compile it (into *.class files), jarball it, and move it to the linux box, where we develop and compile the rest of the code (with the JDK's CORBA classes for Linux). For a complete, standalone, Linux+CORBA+Java solution, ORBacus (or any other compliant CDK) is the best bet; i.e., a CDK with an IDL compiler. --troy What's the problem exactly? Did you try setting the primary bootclasspath to the ORBacus classes? (Personnaly, I do not have any experience on Linux, but with earlier versions of Visibroker for NT and Solaris it was a viable solution to set the bootclasspath, so it point to Visibroker classes first and then to the JDK 1.2 classes. As to JDK 1.2 for Linux and ORBacus, I have not even installed the JDK 1.2 pre on Linux, just looking at the possibility of using it in combination with ORBacus.) Peter -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CC/IT d@ s+:+>+: a-- C+++$ ULUVS$ UA++ UI+ UO P+ L+++$ E+ W+++$ N+(++) o? K? w---(++) O+ M(-) V-- PS+(++) PE Y+ PGP-- t++@ 5- X+ R* tv b++(+++)@ DI+++@ D+ G+ e-* h++*(---) r@ y++**>+$ --END GEEK CODE BLOCK-- [EMAIL PROTECTED] http://labnet.stanford.edu/~troywu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libstdc++-libc6.0-1.so.2... and the Linux mess (IMHO)
On 24 Mar 1999, Albert Y.C. Lai wrote: stuff. Yet, if I get it right, that the linux port requires such beasts as libstdc++-libc6.0-1.so.2 means it is linked against cutting Well, libstdc++-libc6.0-1.so.2 isn't a "real" library, I don't believe. Simply symlinking libstdc++.so to the "beast" should solve the problem. And, I'm using a "cutting-edge" version of libstdc++ (egcs-1.1.1) anyway, and it seems to be no problem. If your aversion is to C++ (and its shared libs), then I, too, am wordless. My system is fairly vanilla Intel RH-5.2 with egcs-1.1.1 for libstdc++. What seems to be not working for you? --troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: javac can not find com.sun.java.swing.JApplet class
How about checking the JDK-1.2 docs...? The package name is:
javax.swing.*
not
com.sun.java.swing.*
On Wed, 31 Mar 1999, Richard James wrote:
public class RootApplet extends com.sun.java.swing.JApplet {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Line numbers vs Compiled Code in stack traces
The VM Spec says that the LineNumberAttribute can be ignored; any such information that the VM provides is a function (IMHO) of the completeness of the debugging implementation in the VM. Not sure that answers your question --troy On Mon, 19 Apr 1999, Jason Proctor wrote: Hi everyone, I've noticed that exception stack traces sometimes print helpful line numbers and sometimes print "Compiled Code" instead of line numbers. The latter is quite annoying when tracking down bugs and I was wondering what determines whether line numbers are included or not. It seems to be random, even in the code I'm writing myself! Does anyone know what determines this, and whether there's a way of always getting line numbers? Thanks in advance. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
package importing conventions
On Mon, 3 May 1999, Michael Sinz wrote: >class layout of java. So yes, it's fine that you declared a >variable as: > >java.util.List foo; Actually, I feel that the real problem is that import lets you use a wildcard. That is, IMHO, the real design flaw in Java. If import required fully qualified names at all times things would be much better. As it is now, many people import the world which makes the packages basically useless (everything is mushed together into a single name space) The nice thing about packages is that you can have the same class name (due to whatever reasons) in multiple packages and not have to give each one a strange name. (Why have to make Jfoo, Nfoo, etc., when it really is a foo?) That an import uses a wildcard can also be a strength. One of the merits of Java lies in its maintainability. Without the ability to import entire package, packages whose structures are being changed (generated code is notorious for having this problem) would have large maintainance issues when names changed. Also, when you decide to use another class in your application, you'll have to add the corresponding import. Sounds like an unnecessary time-sink. It still doesn't solve the List problem... Importing each class is somewhat unnecessary, since importing both java.awt.List and java.util.List doesn't resolve the dependency. You'd still have to unambiguate between List classes. To extend your own words, why call it a javax.swing.JPanel when you can just call it a JPanel? I agree that one, large namespace is impractical (see C++ =), but there are times when it's simply more convenient. Design flaws which deviate from beautiful (IMHO, though it's a little late)can exist--and should exist, sometimes--for purely pragmatic reasons. --troy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
