Re: Problems
As a good person told me recently.. go into your green_thread library directory under java and remove the libc.so and the libdl.so and you will be fine..well it worked for me anyway.. Cheers James. Pooh Bear -- "I am just a bear of little brain" On Tue, 25 Aug 1998, G. Nelson DeSouza wrote: > Hi all, > >It'll probably sound trivial for most of you, but I've just installed > > jdk1.1.6 in my Linux box and I got the following error when running: > > $> cd $JDK_HOME; appletviewer demo/GraphLayout/example1.html > SIGSEGV 11* segmentation violation > stackbase=0xb540, stackpointer=0xb444 > > Full thread dump: > "Finalizer thread" (TID:0x4064b208, sys_thread_t:0x4138ff04, > state:R) prio=1 > "Async Garbage Collector" (TID:0x4064b250, sys_thread_t:0x4136ef04, > state:R) prio=1 > "Idle thread" (TID:0x4064b298, sys_thread_t:0x4134df04, state:R) > prio=0 > "Clock" (TID:0x4064b088, sys_thread_t:0x4132cf04, state:CW) prio=12 > "main" (TID:0x4064b0b0, sys_thread_t:0x81cc6e0, state:R) prio=5 > *current thread* > java.lang.Runtime.loadLibrary(Runtime.java) > java.lang.System.loadLibrary(System.java) > sun.awt.motif.MToolkit.(MToolkit.java:46) > java.awt.Toolkit.getDefaultToolkit(Toolkit.java:402) > sun.applet.AppletCopyright.(AppletCopyright.java:36) > sun.applet.AppletViewer.mainInit(AppletViewer.java:1038) > sun.applet.AppletViewer.main(AppletViewer.java:1047) > Monitor Cache Dump: > java.lang.Runtime@1080365288/1080757432: owner "main" (0x81cc6e0, 1 > entry) > java.lang.Class@1080369848/1080783776: owner "main" (0x81cc6e0, 1 > entry) > Registered Monitor Dump: > Thread queue lock: > Name and type hash table lock: > String intern lock: > JNI pinning lock: > JNI global reference lock: > BinClass lock: > Class loading lock: > Java stack lock: > Code rewrite lock: > Heap lock: > Has finalization queue lock: > Finalize me queue lock: > Monitor IO lock: > Child death monitor: > Event monitor: > I/O monitor: > Alarm monitor: > Waiting to be notified: > "Clock" (0x4132cf04) > Monitor registry: owner "main" (0x81cc6e0, 1 entry) > Thread Alarm Q: > > >The linux is a Slackware 3.5 (kernel 2.0.34), with jdk1.1.6, and > > $> ldconfig -D | grep libc > libc.so.5 => libc.so.5.4.44 > $> ldconfig -D | grep ld > ld-linux.so.1 => ld-linux.so.1.9.9 > $>xdpyinfo |grep 'release number' > vendor release number:3320 > > > Thanks for any help, > > Nelson > > >
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: Problem playing audio file from an application.
> Hello,
>
> I'am trying to play a simple audio(.au) file from an application. When I run my
> application I only hear the beginning of the audio file. Here is the program.
>
> import sun.audio.*;
> import java.io.*;
>
> public class Sound {
>
> public void play(String soundfile){
> File theFile = null;
> AudioData theData = null;
> AudioStream as = null;
> try {
> theFile = new File(soundfile);
> if (theFile != null) {
> InputStream fis = new FileInputStream(theFile);
> as = new AudioStream(fis);
> theData = as.getData();
> }
> }
> catch (IOException e) {
> System.err.println(e);
> }
> AudioDataStream ads = new AudioDataStream(theData);
> AudioPlayer.player.start(ads);
> //try{ Thread.sleep(1500); }
> //catch(Exception e){ System.out.println("sleep failed"); }
> // AudioPlayer.player.stop(as);
> }
>
> public static void main(String[] args) {
> Sound snd=new Sound();
> snd.play("sound.au");
> }
> }
>
> When I unmark the sleep, I hear the whole audio file. But that is offcourse not
> the correct solution.
>
> I tested the application on different platforms and using severel jdk's with
> the same results. Playing the audio file with an audio tool works fine.
>
> Somebody a clue?
Why do call AudioPlayer.stop() ?
AudioPlayer.start() - implicitly spawns a thread to send the audio data to
the audio device via a stream buffer.
Calling AudioPlayer.stop() - terminates the thread, n'est pas ?
Unless your program exits soon after AudioPlayer.start() you
do not need to sleep for X milliseconds.
Cheers
Peter
--
Peter Pilgrim Deutsche Bank (UK) Ltd
"I'd be an eagle because I love its way of flying and if I were an
angel I'd simply be Eric Cantona with big wings. If I were a sport I'd
be football, of course, and if I were a film I'd be Raging Bull. If I
were any child I would be my children but if I were Eric Cantona I'd
be proud."
On himself
Vive Manchester United Football Club
re: packages
> 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
>
>
> 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 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
>
>
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.
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: packages
Hello,
You said you have an editor "that makes life easier". What's that for?
Thanks for your answer.
-jec
> -Original Message-
> From: Michael Sinz [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, August 26, 1998 4:50 PM
> To: Kenny Freeman
> Cc: [EMAIL PROTECTED]
> Subject: 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: 3rd JDK for Linux/Intel available (OpenGroup)
> "Liz" == Linux Weekly News <[EMAIL PROTECTED]> writes: Liz> When you say "heavily based", do you believe they have taken Liz> actual code from the blackdown port? Is the blackdown port Liz> GPL (which would make such borrowing illegal)? No, Sun's licencing prevents code from being GPL'd - all code remains the property of SMI. The licence does allow the distribution of diffs but does not require it. IANAL -- Stephen (who should read this group more often) --- Linux - the Frodo Baggins of Computing.
Re: "can't find class file java/lang/Thread"
uh, I may be way off on this, but try simply: java HelloWorld You do not include the .class ext. Then, you still have to set the classpath as per the last bunch of posts about it __ Kenny Freeman <[EMAIL PROTECTED]> "Time is the fire in which we burn." - ST Generations --- On Wed, 26 Aug 1998, Aaron Brick wrote: > my JDK installation seems to be weird. i saw a previous post relevant to > this problem in the archive but the responses i saw weren't helpful. > > when i do "java HelloWorld.class" it complains about not being able to > find the class file - even if i pass the full path - until i do a > "-classpath `pwd`", or its equivalent. is this normal behavior? > > then - this is the step i have not been able to solve - it complains about > not being able to find a class file called "java/lang/Thread". well, i > have tried a large number of things with the Thread.class file, including > renaming it and putting its path in classpath, putting it in ad-hoc > subdirs in the java/classes dir (where i'm trying all this), etc. i just > can't get it to find the file. > > i mailed one member of this list and he told me to download some different > classes.zip file - however, it didn't appear to be on the russian server > he gave me. why the discrepancy, and what is the deal with this problem, > anyone? > > i have: > > JDK 1.1.6v2, glibc, i386 on Debian 2.0 (2.0.34), libc6. i don't have my > machine handy so i'm sorry i don't have the loader or X versions but i can > certainly supply them later. > > i would say this problem is of fairly high severity because it prevents me > from running any program at all! it may be that it is an isolated incident > but i sure thought the install went fine and my system is not weirdly > hacked or anything. > > thanks for your responses. > > aaron brick. > > >
Re: "can't find class file java/lang/Thread"
My guess is this, you don't have your classpath set. Make sure you have the following in your CLASSPATH environment variable. Path to the JDK classes. Path to any external jar files you might use (ie swing.jar) Path to your development tree (Ie for me it is the root of my jclass hierarchy) Finally a . , to get classes with no package in your current directory. IE, my classpath is usually somthing like CLASSPATH="d:/sdk/jdk1.1.6/lib/classes.zip;d:/special/swing.jar;e:/mydevt;." This will probably solve both of the problems you describe. ../Martin Aaron Brick wrote: > my JDK installation seems to be weird. i saw a previous post relevant to > this problem in the archive but the responses i saw weren't helpful. > > when i do "java HelloWorld.class" it complains about not being able to > find the class file - even if i pass the full path - until i do a > "-classpath `pwd`", or its equivalent. is this normal behavior? > > then - this is the step i have not been able to solve - it complains about > not being able to find a class file called "java/lang/Thread". well, i > have tried a large number of things with the Thread.class file, including > renaming it and putting its path in classpath, putting it in ad-hoc > subdirs in the java/classes dir (where i'm trying all this), etc. i just > can't get it to find the file. > > i mailed one member of this list and he told me to download some different > classes.zip file - however, it didn't appear to be on the russian server > he gave me. why the discrepancy, and what is the deal with this problem, > anyone? > > i have: > > JDK 1.1.6v2, glibc, i386 on Debian 2.0 (2.0.34), libc6. i don't have my > machine handy so i'm sorry i don't have the loader or X versions but i can > certainly supply them later. > > i would say this problem is of fairly high severity because it prevents me > from running any program at all! it may be that it is an isolated incident > but i sure thought the install went fine and my system is not weirdly > hacked or anything. > > thanks for your responses. > > aaron brick. >
Re: JDK1.1.6 for Alpha-Linux?
I do, I do have a 116. But like most things the AWT doesn't work like the awt from 115. I have also tried the egcs ( alternate cc compiler for the alpha ). with this compiler I can use byte/short machine instructions which should speed up things. Interestingly enough though, the egcs compiled java116 doesn't build ( at least ) one class. I dont get any errors, just dont get the class. This also means that for folks with with 21064 processors would use one binary, the folks with the 21164 processors can use the other. In either case, i havent really looked at it too much more when SuperMojo ( which worked reasonably well under 115 ) doesn't work too well yet under 116. ALSO I still get requests to fix 115 ( i suppose they could just have been requests to fix 116 :() Is there something more specifically u would to hear me talk about ? gat Rich Edwards wrote: > Does anyone know of any efforts to port the JDK1.1.6 to Alpha-Linux? > > Thanks, > > Rich Edwards > Senior Software Engineer > Codonics, Inc. > e-mail: [EMAIL PROTECTED]
Out of memory - Garbage collector
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
I have included the source to the program etc.
Daivid
Libraries
ldconfig: version 1.8.2
/usr/local/lib:
/usr/X11R6/lib:
libXtst.so.6 => libXtst.so.6.1
libXt.so.6 => libXt.so.6.0
libXmu.so.6 => libXmu.so.6.0
libXi.so.6 => libXi.so.6.0
libXext.so.6 => libXext.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.0
libXpm.so.4 => libXpm.so.4.3
/usr/i486-linuxaout/lib:
libPEX5.so.6 => libPEX5.so.6.0
libXpm.so.4 => libXpm.so.4.3
libXt.so.6 => libXt.so.6.0
libXaw.so.6 => libXaw.so.6.0
libXIE.so.6 => libXIE.so.6.0
libX11.so.6 => libX11.so.6.0
libXt.so.3 => libXt.so.3.1.0
libXaw.so.3 => libXaw.so.3.1.0
libX11.so.3 => libX11.so.3.1.0
libdb.so.1 => libdb.so.1.85.1
libvga.so.1 => libvga.so.1.2.9
/usr/openwin/lib:
libxview.so.3 => libxview.so.3.2.2
libolgx.so.3 => libolgx.so.3.2.2
/usr/local/pgsql/lib:
libpq.so => libpq.so
libpq.so.1 => libpq.so.1
/usr/lib:
libtiff.so.1 => libtiff.so.1.3
librle.so.1 => librle.so.1.3
libppm.so.1 => libppm.so.1.3
libpnm.so.1 => libpnm.so.1.3
libpgm.so.1 => libpgm.so.1.3
libpbm.so.1 => libpbm.so.1.3
libjpeg.so.1 => libjpeg.so.1.3
libfbm.so.1 => libfbm.so.1.3
libform.so.3.0 => libform.so.3.0
libpanel.so.3.0 => libpanel.so.3.0
libmenu.so.3.0 => libmenu.so.3.0
libbfd.so.2.6.0.14 => libbfd.so.2.6.0.14
libopcodes.so.2.6.0.14 => libopcodes.so.2.6.0.14
libgpm.so.1 => libgpm.so.1.09
libdb.so.1 => libdb.so.1.85.4
libgdbm.so.2 => libgdbm.so.2.0.0
libdb.so.2 => libdb.so.2.0.0
libg++.so.27 => libg++.so.27.1.4
libstdc++.so.27 => libstdc++.so.27.1.4
libvgagl.so.1 => libvgagl.so.1.2.10
libvga.so.1 => libvga.so.1.2.10
/lib:
libdl.so.1 => libdl.so.1.8.2
libncurses.so.3.0 => libncurses.so.3.0
libtermcap.so.2 => libtermcap.so.2.0.8
libm.so.5 => libm.so.5.0.6
libgdbm.so.1 => libgdbm.so.1.7.3
libcurses.so.1 => libcurses.so.1.0.0
libc.so.5 => libc.so.5.3.12
libe2p.so.2 => libe2p.so.2.1
libss.so.2 => libss.so.2.0
libext2fs.so.2 => libext2fs.so.2.0
libcom_err.so.2 => libcom_err.so.2.0
libc.so.4 => libc.so.4.7.6
libm.so.4 => libm.so.4.6.27
libcurses.so.0 => libcurses.so.0.1.2
Program ZipCompress
// Uses Java 1.1 Zip compression to compress
// any number of files whose names are passed
// on the command line.
import java.io.*;
import java.util.*;
import java.util.zip.*;
public class ZipCompress {
public static void main(String[] args) {
try {
System.out.println("Checksum: " +
csum.getChecksum().getValue());
// Now extract the files:
System.out.println("Reading file");
FileInputStream fi =
new FileInputStream("test.zip");
CheckedInputStream csumi =
new CheckedInputStream(
fi, new Adler32());
ZipInputStream in2 =
new ZipInputStream(
new BufferedInputStream(csumi));
ZipEntry ze;
System.out.println("Checksum: " +
csumi.getChecksum().getValue());
while((ze = in2.getNextEntry()) != null) {
System.out.println("Reading file getNext Entry " + ze);
}
in2.close
Russian input problems again
Hi, folks! After some testing jdk1.1.5v3a on RH5.1/glibc2.0.6-19 I found HOW one can input Russian ( see my prev. posting) but Russian input does not wokr correctly anyway. Problem is internal char representation - Russian koi8 input shold be converted in Unicode but jdk does no conversion. So, problem with Russian koi8 chars still persists and jdk/Linux still unusable for former SU part of world. FYI, koi8 is standard network encoding for former SU (RFC 1489) , see http://www.nagual.pp.ru/~ache/koi8.html Bye, SY, Look_in
Packages
Howdie, Anyone know how these darned packages work? Or where a good guide is available concerning packages? I can't seem to find anything about it in the nice Sun Java Tutorial. -- Maarten van Leunen Student - Fontys Institute of Technology Eindhoven e-mail: [EMAIL PROTECTED] http://www.il.fontys.nl/~maartenl http://lok.il.fontys.nl/
Re: Packages
On Wed, 26 Aug 1998 15:54:36 +0200, Maarten van Leunen wrote: >Howdie, > >Anyone know how these darned packages work? Or where a good guide is >available concerning packages? > >I can't seem to find anything about it in the nice Sun Java Tutorial. Well, it is covered in "The Java Programming Language" by Arnold & Gosling. It is also in the Java Language Specification (which you can download) The quick-n-dirty: A package can be seen as a "family" of classes that are more related than classes outside the package but not as releated as subclasses. This means that methods that are private or protected can not be seen by "family" members but they can see the "non-public" and public methods and members. (The non-public ones are the ones that do not have private, protected, or public) A class is defined as part of a package with the package statement. Such as: package ORG.blackdown.util; This package would then be in a directory called: ORG/blackdown/util/ Note that the class would then be part of that package. Normally you would have the source (.java) files in that directory (or equal directory in a different tree) so that it matches it package location. (Otherwise javac will not know how to automatically find it) Packages members can the be accessed either directly via: ORG.blackdown.util.MyClass or ORG.blackdown.util.MyClass.staticMember or, you can import the class and then act on it as if local (but not gain package access. Import is just a form of #define to get the names to be shorter) For example: import ORG.blackdown.util.MyClass; MyClass.staticMember ... Warning - personal opinion/flame about the import feature of Java - 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. 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
"can't find class file java/lang/Thread"
my JDK installation seems to be weird. i saw a previous post relevant to this problem in the archive but the responses i saw weren't helpful. when i do "java HelloWorld.class" it complains about not being able to find the class file - even if i pass the full path - until i do a "-classpath `pwd`", or its equivalent. is this normal behavior? then - this is the step i have not been able to solve - it complains about not being able to find a class file called "java/lang/Thread". well, i have tried a large number of things with the Thread.class file, including renaming it and putting its path in classpath, putting it in ad-hoc subdirs in the java/classes dir (where i'm trying all this), etc. i just can't get it to find the file. i mailed one member of this list and he told me to download some different classes.zip file - however, it didn't appear to be on the russian server he gave me. why the discrepancy, and what is the deal with this problem, anyone? i have: JDK 1.1.6v2, glibc, i386 on Debian 2.0 (2.0.34), libc6. i don't have my machine handy so i'm sorry i don't have the loader or X versions but i can certainly supply them later. i would say this problem is of fairly high severity because it prevents me from running any program at all! it may be that it is an isolated incident but i sure thought the install went fine and my system is not weirdly hacked or anything. thanks for your responses. aaron brick.
Re: "can't find class file java/lang/Thread"
On Wed, 26 Aug 1998 14:05:21 -0400 (CST), Aaron Brick wrote: >my JDK installation seems to be weird. i saw a previous post relevant to >this problem in the archive but the responses i saw weren't helpful. > >when i do "java HelloWorld.class" it complains about not being able to >find the class file - even if i pass the full path - until i do a >"-classpath `pwd`", or its equivalent. is this normal behavior? > >then - this is the step i have not been able to solve - it complains about >not being able to find a class file called "java/lang/Thread". well, i >have tried a large number of things with the Thread.class file, including >renaming it and putting its path in classpath, putting it in ad-hoc >subdirs in the java/classes dir (where i'm trying all this), etc. i just >can't get it to find the file. > >i mailed one member of this list and he told me to download some different >classes.zip file - however, it didn't appear to be on the russian server >he gave me. why the discrepancy, and what is the deal with this problem, >anyone? > >i have: > >JDK 1.1.6v2, glibc, i386 on Debian 2.0 (2.0.34), libc6. i don't have my >machine handy so i'm sorry i don't have the loader or X versions but i can >certainly supply them later. > >i would say this problem is of fairly high severity because it prevents me >from running any program at all! it may be that it is an isolated incident >but i sure thought the install went fine and my system is not weirdly >hacked or anything. What is your CLASSPATH environment variable set to? Best to first try *not* having it set to *anything* (CSH - unsetenv CLASSPATH) In most cases, CLASSPATH should not be needed. (It sounds like CLASSPATH points at the classes.zip file but not the current directory - aka ".") 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
Distribution of runtime portions
Hi, The SUN documentation says that while JRE can be distributed freely with the Java Applications/Applets, the JDK cannot be distributed. I wanted to distribute the runtime features of the JDK ported to linux with my Java application, can I do so freely ?? thanx, --rohit.
Re: "can't find class file java/lang/Thread"
Yes, the poster, Kenny Freeman, is correct. To run a class HelloWorld, which
contains a static method 'main()', you need to type:
java HelloWorld
As long as the directory '.' is in your classpath, and the file
HelloWorld.class is in this directory, and HelloWorld is not a part of a
package, this will work. If HelloWorld is in a package (say, package
'com.fubar'), then you need to type:
java com.fubar.HelloWorld
Think of your classpath as a sort of LD_LIBRARY_PATH, with packages being
contained in subdirectories under directories contained within your CLASSPATH
(replacing the '.' with a '/', of course).
BTW, if you ever decide to package your '.class' files into a jar file, the
jar file needs to be explicitly included in your class path. Let's assume you
package the HelloWorld.class into a jar file called 'fubar.jar', by using the
command:
jar cvf fubar.jar HelloWorld.class
Then, to run HelloWorld, you need to have fubar.jar in your classpath:
export CLASSPATH=${CLASSPATH}:./fubar.jar
Finally, you can now run the program (again, assuming that HelloWorld is not
part of a package) using:
java HelloWorld
I hope this helps!
-dan
[EMAIL PROTECTED]
Aaron Brick wrote:
> my JDK installation seems to be weird. i saw a previous post relevant to
> this problem in the archive but the responses i saw weren't helpful.
>
> when i do "java HelloWorld.class" it complains about not being able to
> find the class file - even if i pass the full path - until i do a
> "-classpath `pwd`", or its equivalent. is this normal behavior?
>
> then - this is the step i have not been able to solve - it complains about
> not being able to find a class file called "java/lang/Thread". well, i
> have tried a large number of things with the Thread.class file, including
> renaming it and putting its path in classpath, putting it in ad-hoc
> subdirs in the java/classes dir (where i'm trying all this), etc. i just
> can't get it to find the file.
>
> i mailed one member of this list and he told me to download some different
> classes.zip file - however, it didn't appear to be on the russian server
> he gave me. why the discrepancy, and what is the deal with this problem,
> anyone?
>
> i have:
>
> JDK 1.1.6v2, glibc, i386 on Debian 2.0 (2.0.34), libc6. i don't have my
> machine handy so i'm sorry i don't have the loader or X versions but i can
> certainly supply them later.
>
> i would say this problem is of fairly high severity because it prevents me
> from running any program at all! it may be that it is an isolated incident
> but i sure thought the install went fine and my system is not weirdly
> hacked or anything.
>
> thanks for your responses.
>
> aaron brick.
>
Java linux mailing list?
I tried to subscribe at [EMAIL PROTECTED] as per the instructions in the README.linux file included in jdk1.1.6 v2 for glibc, but my mail bounced. Same with [EMAIL PROTECTED] Are those addresses no longer correct? If so I'd like to find out what the new ones are, since I want to subscribe and have a bug to report, too. :) (Not that I know if someone else did it already, of course - is there some archive with known and fixed bugs in the linux port somewhere on the web, or is the mailing list the only way to find out?) /Jonas
