Re: IDE for Java
I think that Paul Kinnucan Emacs java IDE http://sunsite.auc.dk/jde/ is very cool. It come with a speedbar for class browsing Maksim Lin wrote: > Robb Shecter wrote: > > > > So far the only Java Linux IDE that truly does this is the BISS IDE, but that > > project appears to be dead. (Too bad - it's the only Java IDE on Linux I > > liked.) > > I like the BISS IDE (JDE) way of doing things as well. I think IDE's > for java (including the prominent windows based ones) are a bit of a > joke, since they are just "prettier" versions of things like the turbo > pascal/C IDE back in the days of DOS (thought these days they seem to > require 64M of RAM to do the samething !). With a nice OO langauge like > java I think something like BISS JDE - a sortof editable classbrowser is > a much nicer way of doing things. > > I'm currently working on my editor which is based on the BISS idea (with > some of my own ideas thrown in) but it is quite a bit of work and only > half-finished at this stage. > > Maksim. > > -- > Remember Darwin; building a better mousetrap merely results in smarter > mice. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problems
hello, this is a problem that i have when i try to run java: ./../bin/i586/green_threads/java: error in loading shared libraries: ./../lib/i586/green_threads/libjava.so: undefined symbol: _dl_symbol_value can't figure out why? any help would be greatly appreciated. joseph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hang in GC with invocation (1.2)
Ok, I guess the subject is enough :-) I am using the invocation API to start JDK1.2, and everything works fine until System.gc() is called ( or I create few large arrays and I suppose gc() is trigered). The same code works without problems with JDK117. The program is using it's own threads, I just attach to the virtual machine when I need to do Java processing ( and when gc() hung, all other threads are also hunged) Please help - I have no ideea where to start with this. Regards, Costin ( the program is apache-apr, the multithreading version of Apache - but I don't think it's a problem with their code, since 1.1.7 works too well, I had it running all night with 20 clients calling servlets ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JDK 1.2 pre-v1 problem
Hi I have Slackware Linux 3.5 and tries to install jdk1.2 pre-v1. First of all (when i've just unzip it) it says that it could not find some file. I investigate that it wants some libs such as linc.so.6 and ld-linux.so.2 which there is not on my system. I've found them in glibc-2.0.6. When i've install them i got "Segmentation fault" error. In README.linux you says that 2.0 is not very good and 2.1 is much better but 2.1 is deleted from gnu.org. So I've set LD_BIND_NOW environment variable (as README.linux says) but no changes. I've tried both green and native threads. Can you help with it? SY, Alexei -- St. Petersburg Java WorkShop team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multi JVM's mem usage in linux?
On Tue, 23 Mar 1999 13:42:46 +1100, Maksim Lin wrote: >Thanks for the info, but I'm still confused - even if top is lying to me >about individual jvm mem usage, I think it's telling the truth about >totol mem usage (at least thats my rough assessment by comparing it's >numbers to hearing the hard disk churn swapping mem in/out). >So why do I get these results ?: Did you read what a posted? ] Linux automatically will share "code" memory. That is, the same physical ] memory space will be used for all of the same physical code. ] Java has another thing that is not as easy to share: The classes.zip ] class files. These are loaded by the JVM into each JVM. This is not ] shared automatically. However, there is hack to the VM system called ] MergeMem that addresses this type of shared data too. I, personally, ] do not use it but I have seen it work. The web site is: ] http://das.ist.org/mergemem/ Again, check out the MergeMem page. It explains how Linux shares code and in my message I explained how the JVM needs to load classes.zip and that is data and not code and thus is not automatically shared without something like MergeMem. (Look at the size of classes.zip and its unzipped size since the classes need to be unzipped to be used) Also, note that you may wish to run your Java with the non-AWT version which is a bit smaller - but that is mainly in the code size but it also means a bit less data space. Another MergeMem site has some examples as to JDK memory usage: http://www.complang.tuwien.ac.at/ulrich/mergemem/ Michael Sinz -- Director of Research & Development, NextBus Inc. mailto:[EMAIL PROTECTED] - http://www.nextbus.com My place on the web ---> http://www.users.fast.net/~michael_sinz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multi JVM's mem usage in linux?
The problem is that most of the stuff that is loaded by the java interpreter isn't shared (.class .jar files). Unless the application is mission critical and / or shares a lot of static classes, it would be better to run them in seperate threads like the others have said. It's not so bad in java, because if one fails, it usually throws an exception (which you can catch), and does not halt the process. Only in rare instances have I ever seen the JVM seg fault and shut down the entire process. I'm not sure but I think another case where the process gets shut down is when a monitor dump gets shown. Maksim Lin wrote: > > Thanks for the info, but I'm still confused - even if top is lying to me > about individual jvm mem usage, I think it's telling the truth about > totol mem usage (at least thats my rough assessment by comparing it's > numbers to hearing the hard disk churn swapping mem in/out). > So why do I get these results ?: > > 1 jvm: > Mem: 47248K av, 44580K used, 2668K free, 21440K shrd,160K buff > Swap: 72572K av, 7116K used, 65456K free 14456K > cached > > 2 jvm: > Mem: 47248K av, 46280K used,968K free, 21868K shrd,100K buff > Swap: 72572K av, 11584K used, 60988K free 12648K > cached > > 3 jvm: > Mem: 47248K av, 46288K used,960K free, 19568K shrd, 92K buff > Swap: 72572K av, 17828K used, 54744K free 11224K > cached > > Now back to 2 jvm: > Mem: 47248K av, 38992K used, 8256K free, 18116K shrd, 92K buff > Swap: 72572K av, 17824K used, 54748K free 11472K > cached > > Now 1 jvm: > Mem: 47248K av, 32088K used, 15160K free, 16756K shrd, 92K buff > Swap: 72572K av, 17160K used, 55412K free 11472K > cached > > Now no jvm: > Mem: 47248K av, 26052K used, 21196K free, 15496K shrd, 92K buff > Swap: 72572K av, 14908K used, 57664K free 11472K > cached > > According to this I am better off just running 1 vm and all apps as lots > of threads. > > Thanks, > Maksim > > > Linux automatically will share "code" memory. That is, the same physical > > memory space will be used for all of the same physical code. > > > > Now, PS and TOP show you what each process would take but not how much > > is actually shared in the code sections. > > > > Java has another thing that is not as easy to share: The classes.zip > > class files. These are loaded by the JVM into each JVM. This is not > > shared automatically. However, there is hack to the VM system called > > MergeMem that addresses this type of shared data too. I, personally, > > do not use it but I have seen it work. The web site is: > > http://das.ist.org/mergemem/ > > > > Michael Sinz -- Director of Research & Development, NextBus Inc. > > mailto:[EMAIL PROTECTED] - http://www.nextbus.com > > My place on the web ---> http://www.users.fast.net/~michael_sinz > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- > Remember Darwin; building a better mousetrap merely results in smarter > mice. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Visual Java development using visual Tcl !
Hello all, I was looking one month ago for a good, free visual Java development tool. Didn't find anything that suit me so I decided to patch vTcl (visual Tcl) in order to generate also Java GUI code. I succeeded, it works fine for me so if anyone is interested in such a thing please take a look at : http://www.flex.ro/vtclava/index.html Nice screenshots, demos, howto, downloads available. If you are interested and you liked it you can add it to the "Free java development tools for Linux". Best regards, -- Constantin Teodorescu FLEX Consulting Braila, ROMANIA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Native Threads in Linux Port for 1.2
Pardon me if this has been asked and I either didn't understand the response, or I missed it, but... I recall a while back that the porting team had some difficultly getting native threads to pass the JCK in JDK 1.2. I was wondering if those issues were ever resolved, and if the current pre-release includes native thread support. Thanks. -Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multi JVM's mem usage in linux?
Why not convert your app to an applet? Applets are designed to have multiple applets run in a single VM. Lotus' InfoBus takes advantage of this, in fact, to allow for data sharing between separate "programs" (actually, applets). This also encourages a more modular design--when a given applet (say, the spell checker) is finished with the data, the applet can exit & free up memory required by the applet. You'd also have the implicit advantage that your code would also run inside a browser, if you choose. -dan Maksim Lin wrote: > To get away from the torrent of 1.2 questions, here is one about > jdk1.1.7: > > I have a quick question about the jvm's memory usage in linux. For > instance if I have 3 jvm's running (all same version) will there be any > sharing of memory resources between the jvms? As I understand it, the > jdk is built using shared libs so should all of the running jvms be > sharing only 1 copy of these libs in memory ? > > Why I ask is that I have tried the above scenario and have found that > having 3 jvm's running uses up almost 3x the memory of having 1 runnning > - leading me to think there is no sharing and wondering how much memory > I'm going to need if I want to have a large number of small > (co-operating) java apps running similtaneously (I know an alternative > would be to use something like echidna which will let multiple apps run > inside 1 vm, but will this is a nice solution it still has a problem > since apps in the same vm are vulnerable to each other, ie. if one of > the apps dies it can take the whole vm and all the other apps in it with > it). > > TIA, > Maksim. > -- > Remember Darwin; building a better mousetrap merely results in smarter > mice. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multi JVM's mem usage in linux?
Have a look at the JShell Project on http://www.ANTLR.org/showcase.html. It may or may not help you. Absolutely no warranty :). Peter Maksim Lin wrote: > I have a quick question about the jvm's memory usage in linux. For > instance if I have 3 jvm's running (all same version) will there be any > sharing of memory resources between the jvms? As I understand it, the > jdk is built using shared libs so should all of the running jvms be > sharing only 1 copy of these libs in memory ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Native Threads in Linux Port for 1.2
Yes, native threads are working in the 1.2 prerelease. Green threads, this time, is a problem when used with the JIT, but you can disable it, of course. Russ [EMAIL PROTECTED] on 03/23/99 11:25:09 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Russell Pridemore/Lex/Lexmark) Subject: Native Threads in Linux Port for 1.2 Pardon me if this has been asked and I either didn't understand the response, or I missed it, but... I recall a while back that the porting team had some difficultly getting native threads to pass the JCK in JDK 1.2. I was wondering if those issues were ever resolved, and if the current pre-release includes native thread support. Thanks. -Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multi JVM's mem usage in linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > while because I had actual work to do. You can create your own custom > security manager that disallows System.exit() calls. Yes, but how do one actually *stop* the application manually, after having denied the System.exit() call? I was playing with the idea to write an echidna type app (as a learning experience), but never got started because I couldn't solve that simple problem :) / Peter Schuller - --- PGP userID: 0x5584BD98 or 'Peter Schuller <[EMAIL PROTECTED]>' E-Mail: [EMAIL PROTECTED] Web: http://hem.passagen.se/petersch Help create a free Java based operating system - www.jos.org. -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBNvfTZcBfJ1FVhL2YEQLfbwCg88Dw3edPzSOlP5qs4lEVo+Tphm0AoNGX gte6iT4sppbqa8YV7T33UVoc =zlwa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK 1.2 for i386 and kernel 2.2.X
Steve, I have gotten 1.2 to run with the 2.2 kernel installed on RedHat 5.2. I believe that Steve Byrne mentioned on this list that the multicasting bug was fixed in the 2.2 kernel. Unfortunately, I have not been able to do much testing with 1.2 because it does not like my video card. I am using the new FrameBuffer support in conjunction with an S3Trio3D card running at 1024X768 and 32 bp It is the 32 bp that seems to kill 1.2 Cynthia Jeness Steve King wrote: > Well done for porting 1.2! I am looking forward to using > Linux as my main development environment for swing > applications. > > In the status page, you say that there are some issues with > linux 2.0.36, that are fixed in 2.0.37. However, you don't > mention 2.2.x > > Have you been able to do any testing with 2.2.x? Do you know > if the bug afflicting 2.0.36 is present in 2.2.x? > > Living on the end of a V90 modem, I would really like to > download the pre-release 1, but 25Mb is a lot of phone time. > > Cheers > -- > Steve King > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Initial test of jdk1.2 pre-release
RedHat 5.2 on Intel Pentium 100 mHz cpu Installation went as described Ran demos. Demos in jdk1.2/demo/applets all seem to work in Netscape Navigator 4.0 jfc demos all fail. Message is Exception in thread "main" java.lang.UnsatifiedLinkError: /jdk1.2/jre/lib/i386/libfontmanager.so: libstdc++-libc6.0-1.so.2: cannot open shared object file: No such file or directory etc. etc. Following is the output of /sbin/ldconfig -D /sbin/ldconfig: version 970402 /usr/lib: libsnmp.so.0 => libsnmp.so.0.3.5.3 libtk8.0.so => libtk8.0.so libtixsam4.1.8.0.so => libtixsam4.1.8.0.so libtix4.1.8.0.so => libtix4.1.8.0.so libtkx8.0.3.so => libtkx8.0.3.so libtclx8.0.3.so => libtclx8.0.3.so libtcl8.0.so => libtcl8.0.so libvgagl.so.1 => libvgagl.so.1.3.0 libvga.so.1 => libvga.so.1.3.0 libslang.so.0 => libslang.so.0.99.38 libreadline.so.3 => libreadline.so.3.0 libhistory.so.3 => libhistory.so.3.0 libpq.so.1 => libpq.so.1.1 libpq++.so.1 => libpq++.so.1 libpgtcl.so.1 => libpgtcl.so.1 libecpg.so.1 => libecpg.so.1.1 libnewt.so.0.30 => libnewt.so.0.30 libncp.so.1 => libncp.so.1.0 libungif.so.3 => libungif.so.3.0.0 libtiff.so.3 => libtiff.so.3.4 libstdc++.so.2.8 => libstdc++.so.2.8.0 libpng.so.2 => libpng.so.2.1.0 libjpeg.so.62 => libjpeg.so.62.0.0 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 libgdk_imlib.so.1 => libgdk_imlib.so.1.8.0 libImlib.so.1 => libImlib.so.1.8.0 libgtk.so.1 => libgtk.so.1.0.6 libgdk.so.1 => libgdk.so.1.0.6 libgpm.so.1 => libgpm.so.1.13 libglib.so.1 => libglib.so.1.0.6 libgimpui.so.1 => libgimpui.so.1.0.1 libgimp.so.1 => libgimp.so.1.0.1 libgck.so.1 => libgck.so.1.0.0 libgdbm.so.2 => libgdbm.so.2.0.0 libgd.so.1 => libgd.so.1.2 libexpect5.26.so => libexpect5.26.so libcrack.so.2 => libcrack.so.2.7 libopcodes-2.9.1.0.15.so.0 => libopcodes-2.9.1.0.15.so.0.0.0 libbfd-2.9.1.0.15.so.0 => libbfd-2.9.1.0.15.so.0.0.0 libz.so.1 => libz.so.1.1.3 libpanel.so.4 => libpanel.so.4.2 libncurses.so.4 => libncurses.so.4.2 libmenu.so.4 => libmenu.so.4.2 libform.so.4 => libform.so.4.2 /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.4 => libMagick.so.4.0.10 /usr/lib: libsnmp.so.0 => libsnmp.so.0.3.5.3 libtk8.0.so => libtk8.0.so libtixsam4.1.8.0.so => libtixsam4.1.8.0.so libtix4.1.8.0.so => libtix4.1.8.0.so libtkx8.0.3.so => libtkx8.0.3.so libtclx8.0.3.so => libtclx8.0.3.so libtcl8.0.so => libtcl8.0.so libvgagl.so.1 => libvgagl.so.1.3.0 libvga.so.1 => libvga.so.1.3.0 libslang.so.0 => libslang.so.0.99.38 libreadline.so.3 => libreadline.so.3.0 libhistory.so.3 => libhistory.so.3.0 libpq.so.1 => libpq.so.1.1 libpq++.so.1 => libpq++.so.1 libpgtcl.so.1 => libpgtcl.so.1 libecpg.so.1 => libecpg.so.1.1 libnewt.so.0.30 => libnewt.so.0.30 libncp.so.1 => libncp.so.1.0 libungif.so.3 => libungif.so.3.0.0 libtiff.so.3 => libtiff.so.3.4 libstdc++.so.2.8 => libstdc++.so.2.8.0 libpng.so.2 => libpng.so.2.1.0 libjpeg.so.62 => libjpeg.so.62.0.0 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 libgdk_imlib.so.1 => libgdk_imlib.so.1.8.0 libImlib.so.1 => libImlib.so.1.8.0 libgtk.so.1 => libgtk.so.1.0.6 libgdk.so.1 => libgdk.so.1.0.6 libgpm.so.1 => libgpm.so.1.13 libglib.so.1 => libglib.so.1.0.6 libgimpui.so.1 => libgimpui.so.1.0.1 libgimp.so.1 => libgimp.so.1.0.1 libgck.so.1 => libgck.so.1.0.0 libgdbm.so.2 => libgdbm.so.2.0.0 libgd.so
Re: multi JVM's mem usage in linux?
Hi,
> Yes, but how do one actually *stop* the application manually, after having
> denied the System.exit() call? I was playing with the idea to write an echidna
> type app (as a learning experience), but never got started because I couldn't
> solve that simple problem :)
Only allow a given thread to stop the application. A hackish example
would be this:
System.setSecurityManager(new SecurityManager(){
public void checkExit(int status) {
if (!Thread.currentThread().getName().equals("kill
thread")) throw new SecurityException("naughty naughty.");
}
}
You could also use a special magic status number, such as 0xCAFEBABE :)
dstn.
---
-- Dustin Lang, [EMAIL PROTECTED] --
(java developer, linux guy, green-haired freak)
Why Linux is so cool: /usr/include/string.h:190:
/* Sautee STRING briskly. */
extern char *strfry __P ((char *__string));
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
jre/glibc2.0/glibc2.1
I am a java developer trying to get a java app running under jre 1.1.7 (i386) running on the next release of Redhat Linux (now in beta). The app runs fine udner the current Redhat Linux with the jre 1.1.7 but fails on the new system. Through my limited understanding and through conact with Redhat, I believe that I need jre for glibc 2.1 not jre for glibc 2.0 (which I assume is the curremt release). Is this available and from where? The message from Redhat is given below. I only have a few days to get his working due to deadline imposed by Redhat so a timely response would be greatly appreciated. Thank you, Robert F. Hodson [EMAIL PROTECTED] 757-873-4747 JDH Technologies - Message from redhat... Unfortunately, the things that they are doing with threads mean that the jre for glibc 2.0 absolutely can't be made to work with glibc 2.1 because they make assumptions about posix thread internals that are simply not true under glibc 2.1. However, blackdown do, as I understand, include a copy of the jre recompiled to work with glibc 2.1, so you'll need to get that new version, at which point it should work fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JDK1.2 and CORBA
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]
Re: Initial test of jdk1.2 pre-release
I had the same problem. Managed to fix it though. I simply created a link to libstdc++.so.2.8.0 in /usr/lib from the file it required. Sorta worked, although I do get lots of font warnings - but java runs OK. Not sure whether it is really a fix or what. James --- George Lawton <[EMAIL PROTECTED]> wrote: > RedHat 5.2 on Intel Pentium 100 mHz cpu > > Installation went as described > Ran demos. Demos in jdk1.2/demo/applets all seem to > work in Netscape > Navigator 4.0 > > jfc demos all fail. Message is > > Exception in thread "main" > java.lang.UnsatifiedLinkError: > /jdk1.2/jre/lib/i386/libfontmanager.so: > libstdc++-libc6.0-1.so.2: cannot > open shared object file: No such file or directory > > etc. etc. > > Following is the output of /sbin/ldconfig -D > > /sbin/ldconfig: version 970402 > /usr/lib: > libsnmp.so.0 => libsnmp.so.0.3.5.3 > libtk8.0.so => libtk8.0.so > libtixsam4.1.8.0.so => libtixsam4.1.8.0.so > libtix4.1.8.0.so => libtix4.1.8.0.so > libtkx8.0.3.so => libtkx8.0.3.so > libtclx8.0.3.so => libtclx8.0.3.so > libtcl8.0.so => libtcl8.0.so > libvgagl.so.1 => libvgagl.so.1.3.0 > libvga.so.1 => libvga.so.1.3.0 > libslang.so.0 => libslang.so.0.99.38 > libreadline.so.3 => libreadline.so.3.0 > libhistory.so.3 => libhistory.so.3.0 > libpq.so.1 => libpq.so.1.1 > libpq++.so.1 => libpq++.so.1 > libpgtcl.so.1 => libpgtcl.so.1 > libecpg.so.1 => libecpg.so.1.1 > libnewt.so.0.30 => libnewt.so.0.30 > libncp.so.1 => libncp.so.1.0 > libungif.so.3 => libungif.so.3.0.0 > libtiff.so.3 => libtiff.so.3.4 > libstdc++.so.2.8 => libstdc++.so.2.8.0 > libpng.so.2 => libpng.so.2.1.0 > libjpeg.so.62 => libjpeg.so.62.0.0 > 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 > libgdk_imlib.so.1 => libgdk_imlib.so.1.8.0 > libImlib.so.1 => libImlib.so.1.8.0 > libgtk.so.1 => libgtk.so.1.0.6 > libgdk.so.1 => libgdk.so.1.0.6 > libgpm.so.1 => libgpm.so.1.13 > libglib.so.1 => libglib.so.1.0.6 > libgimpui.so.1 => libgimpui.so.1.0.1 > libgimp.so.1 => libgimp.so.1.0.1 > libgck.so.1 => libgck.so.1.0.0 > libgdbm.so.2 => libgdbm.so.2.0.0 > libgd.so.1 => libgd.so.1.2 > libexpect5.26.so => libexpect5.26.so > libcrack.so.2 => libcrack.so.2.7 > libopcodes-2.9.1.0.15.so.0 => > libopcodes-2.9.1.0.15.so.0.0.0 > libbfd-2.9.1.0.15.so.0 => libbfd-2.9.1.0.15.so.0.0.0 > libz.so.1 => libz.so.1.1.3 > libpanel.so.4 => libpanel.so.4.2 > libncurses.so.4 => libncurses.so.4.2 > libmenu.so.4 => libmenu.so.4.2 > libform.so.4 => libform.so.4.2 > /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.4 => libMagick.so.4.0.10 > /usr/lib: > libsnmp.so.0 => libsnmp.so.0.3.5.3 > libtk8.0.so => libtk8.0.so > libtixsam4.1.8.0.so => libtixsam4.1.8.0.so > libtix4.1.8.0.so => libtix4.1.8.0.so > libtkx8.0.3.so => libtkx8.0.3.so > libtclx8.0.3.so => libtclx8.0.3.so > libtcl8.0.so => libtcl8.0.so > libvgagl.so.1 => libvgagl.so.1.3.0 > libvga.so.1 => libvga.so.1.3.0 > libslang.so.0 => libslang.so.0.99.38 > libreadline.so.3 => libreadline.so.3.0 > libhistory.so.3 => libhistory.so.3.0 > libpq.so.1 => libpq.so.1.1 > libpq++.so.1 => libpq++.so.1 > libpgtcl.so.1 => libpgtcl.so.1 > libecpg.so.1 => libecpg.so.1.1 > libnewt.so.0.30 => libnewt.so.0.30 > libncp.so.1 => libncp.so.1.0 > libungif.so.3 => libungif.so.3.0.0 > libtiff.so.3 => libtiff.so.3.4 > libstdc++.so.2.8 => libstdc++.so.2.8.0 > libpng.so.2 => libpng.so.2.1.0 > libjpeg.so.62 => libjpeg.so.62.0.0 > librle.so.1 => librle.so.1.0.0 > libppm
Re: multi JVM's mem usage in linux?
Thanks Michael, I think I finally understand (finally). What got me going in the wrong direction was assumming that it was the jvm hogging memory, when in fact it's the classes. The reason I initially didn't think about classes was the "dynamic loading" buzzword in java, but now that I think about it, of course I was being stupid, since even with dynamic loading of classes, the classes used are still going to take up a fair bit of space (jdk1.1.7 classes.zip = ~8.8M!) and of course I was running a swing app (swingall.jar ~2.2M). I'll check out the mergemem sites you mentioned, since the all-in-1-jvm approach is good but not perfect, so it always pays to know about alternatives. Thanks again (for having the patience to explain twice), Maksim Lin. Michael Sinz wrote: > > On Tue, 23 Mar 1999 13:42:46 +1100, Maksim Lin wrote: > > >Thanks for the info, but I'm still confused - even if top is lying to me > >about individual jvm mem usage, I think it's telling the truth about > >totol mem usage (at least thats my rough assessment by comparing it's > >numbers to hearing the hard disk churn swapping mem in/out). > >So why do I get these results ?: > > Did you read what a posted? > > ] Linux automatically will share "code" memory. That is, the same physical > ] memory space will be used for all of the same physical code. > > ] Java has another thing that is not as easy to share: The classes.zip > ] class files. These are loaded by the JVM into each JVM. This is not > ] shared automatically. However, there is hack to the VM system called > ] MergeMem that addresses this type of shared data too. I, personally, > ] do not use it but I have seen it work. The web site is: > ] http://das.ist.org/mergemem/ > > Again, check out the MergeMem page. It explains how Linux shares code > and in my message I explained how the JVM needs to load classes.zip > and that is data and not code and thus is not automatically shared without > something like MergeMem. (Look at the size of classes.zip and its unzipped > size since the classes need to be unzipped to be used) > > Also, note that you may wish to run your Java with the non-AWT version > which is a bit smaller - but that is mainly in the code size but it also > means a bit less data space. > > Another MergeMem site has some examples as to JDK memory usage: > http://www.complang.tuwien.ac.at/ulrich/mergemem/ > > Michael Sinz -- Director of Research & Development, NextBus Inc. > mailto:[EMAIL PROTECTED] - http://www.nextbus.com > My place on the web ---> http://www.users.fast.net/~michael_sinz > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Remember Darwin; building a better mousetrap merely results in smarter mice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Corba
sun's idltojava converter takes in idl code and spew out "processed" 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. So cheer up, you can still do corba in linux. _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -- 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]
free type 3 jdbc driver
Does anybody know where can I find a FREE type 3 jdbc driver for access ODBC data sourcee Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 -- 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: multi JVM's mem usage in linux?
Dustin Lang wrote:
> Hi,
>
> > Yes, but how do one actually *stop* the application manually, after having
> > denied the System.exit() call? I was playing with the idea to write an echidna
> > type app (as a learning experience), but never got started because I couldn't
> > solve that simple problem :)
>
> Only allow a given thread to stop the application. A hackish example
> would be this:
>
> System.setSecurityManager(new SecurityManager(){
> public void checkExit(int status) {
> if (!Thread.currentThread().getName().equals("kill
> thread")) throw new SecurityException("naughty naughty.");
> }
> }
>
> You could also use a special magic status number, such as 0xCAFEBABE :)
It might be worthwhile to register a specific object in the constructor for your
security manager, and save that for later comparison:
class MySecurityManager extends SecurityManager {
private Thread privileged;
public MySecurityManager() { privileged = Thread.currentThread(); }
public void checkExit(int status) {
if (!Thread.currentThread() == privileged) throw new SecurityException("...");
}
}
In that example only the thread which created the security manager could shut down
the VM.
Wes
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK1.2 and CORBA
I downloaded the Solaris version from Sun and installed the .class file (InstallShield) from Linux Java 2, it failed at the end while trying to install some java extension libraries. Another nameserv I already had working wouldn't work anymore after that. I had to reinstall Java 2. If you do get it in ok, it provides a set of classes (zip not jar for some reason, from IBM, ibm???.zip) which is a pure Java idltojava compiler which worked fine. However, the nameserv shipped with the Solaris version was a native binary (come on Sun, what's up?) so I ended up using ORBacus: http://www.ooc.com/ I tried JacORB too, but the ftp site was still disallowing downloads after their reorg last week. http://www.inf.fu-berlin.de/~brose/jacorb/ Both are pure Java; ORBacus worked fine for me. Regards Jon Priddey Elixir Technology Pte Ltd. > 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]
FYI: JavaSpaces work in JDK1.2pre1
Hello, I had previously posted questions about getting JavaSpaces to work under Linux. For all those that were interested, I've got it working. It was my fault, I mis-spelled outrigger-dl.jar in my script file that started the space. JavaSpaces works fine under Linux with JDK1.2pre1. WooHoo! -- --- If DOS means "Denial Of Service" what's MS-DOS? And why should I tell it to "win"? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
