Re: Applet reloading problem.
On Thu, 7 Sep 2000, Robert Pottschmidt wrote: > Hi, > > Please forgive me for this post I am a newbie to system adm. Our setup is an >academic server. Running Redhat 6.1 with Apache and Jserv. Our problem deals with a >lab we assigned that all of our users where to do an applet using swing to draw a >moiré pattern. When we view them on the server using Netscape one of the students >applets gets load by all the other students pages. This only happen on the server. >Instead of showing the actual students applet it shows an students applet. All the >class are named the same. I think the JServe process is keeping track of the classes it has loaded by class name, and once it has loaded that name once, it won't reload it. Because all your students are using the same class name, the process is loading the first student's version, and re-using it for all subsequent accesses. I think you need to either have the students use unique class names, or find a way to force JServe to reload classes even if JServe thinks it has seen them before. Bouncing JServe would do it but that probably isn't an option for a lab server. I see this sort of behaviour running unit tests with JUnit. JUnit works around this problem by providing a custom class loader that does not attempt to be so clever. Hopefully someone with specific JServe experience can offer a definitive solution for your problem. -- Joi EllisSoftware Engineer Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] No matter what we think of Linux versus FreeBSD, etc., the one thing I really like about Linux is that it has Microsoft worried. Anything that kicks a monopoly in the pants has got to be good for something. - Chris Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Writing A Java Pop Server for Linux
Hi all, Summary: I have a peculiar situation, briefly, I want to write a Daemon/Server in Java which will listen to the Pop port and service Pop requests from clients. Setup: -- I have a Redhat Linux 6 system, and I have jdk-1.1.8 on it. Details: I want the behaviour of the Pop Server to mimic that of any other daemon on a Unix machine. In other words it should first disassociate itself from the terminal on which it started su down to nobody, close default IO descriptors and then move on to listening for connections. There is an another problem here. I am not so sure about having the Server run uninterrupted. Because of memory leaks I should probably restart the Server after having server n connections. Implementation: --- I thought of using the Java Native Interface, I don't know much in this area but here is the plan ... If possible I will change to a background process and bind to the Pop Socket all as part of a C Program, and then Invoke a Java Implementation for accepting client connections. Alternately, I could just keep the daemon part of the code in C and reserve the networking for Java. This way I need to su down to nobody and then load the appropriate Java Class. The Second scenario looks more feasible, I am able to start the JVM from a C Program using libjava.so. This way it also looks easier to start and restart the JVM as proposed. The Difficulty is in restarting the daemon after n connections without inserting any noticeable delay in servicing client connections. I want the time window for which the service is down to be an acceptable minimum. I need Help: The Picture is very hazy, has anybody done this before ? Can Annybody suggest alternatives ? Can somebody help me with advice/resources on this issue ? Whats more important is what is the most efficient way to carry this out ? Of course things have gotten rather complicated and I don't know the hazards I might face further ahead. Already, JNI_GetDefaultJavaVMInitArgs is returning null in place of the Classpath, although the CLASSPATH variable has been set for the shell. I don't know if they are related. Santosh Dawara
Re: Who is right?
Hello all,
> I say syntactically because this is the strict translation of your code.
> A good compiler could optimize away this difference. The compilers have
> special handling of String object in a few places anyway.
Be careful here - the java language requires two identical string
constants to be equal:
String s1 = "hello";
String s2 = "hello";
System.out.println(s1 == s2); // returns 'true'
The language spec also requires new instances of a String to *not* be
equal to the constant:
String s1 = "hello";
String s2 = new String("hello");
System.out.println(s1 == s2); // returns 'false'
Because of these distinctions, a compiler is not allowed to optimize in
the fashion you suggest.
-Larry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who is right?
> "Jacob" == Jacob Nikom <[EMAIL PROTECTED]> writes:
> Hi,
> This is not really Java-Linux, but more like Java question.
> May be it is different for Java Linux implementation, that is
> why I decided to ask.
Actually, the language specification is pretty specific in this area -
see JLS (2nd Ed) sections 3.10.5 and 15.9...
> My friend and I recently tried to figure out which String
> implementation is more efficient and correct:
> String a = "bb"
> or
> String a = new String("bb");
> He said that the second one is a copy constructor which is less
> efficient. It uses more memory and requires to copy the array
> from one place to another. I said that they are the same and it is
> simply different syntax. Who is right?
Your friend is half right:
The former case assigns a to the (interned) string literal "bb".
The latter case assigns a to a new instance of String with the same
sequence of characters as the (interned) string literal "bb".
Now, the reason that he is only half right is that String instances
may share the internal char arrays - this is why Strings are
immutable, after all. So, in the first case, there is one String
object instance which refers to one char array. In the latter case,
there are two String instances, both referencing the same char
array.
I believe that (current) java sematics would forbid these being
equivalent, as the second case would seem to *require* allocation of
new space (e.g. the new object), whereas the first may not. In
particular, java semantics requires the following behavior:
String a = "bb";
String b = "bb";
String c = new String(a);
String d = new String(b);
String e = d.intern();
(a==b) // required to be true!
(a!=c) // required to be true.
(c!=d) // required to be true.
(a==e) // required to be true.
and, of course, they are all .equals().
See JLS (2nd ed), pp 27.
cheers,
-mik
--
Michael Thome ([EMAIL PROTECTED])
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who is right?
Hi,
I would like to thank all people in discussion, especially Chris.
I had never looked at bytecodes before. As far as I see the
call to the String constructor is in the line 3.
It is interesting to know how different bytecodes could be in
different compilers.
Regards,
Jacob Nikom
Chris Abbey wrote:
> At 01:45 9/8/00 +0200, Uli Luckas wrote:
> >Now the second bad news, if you decompile the code generated with either
> >javac or jikes you can see that the constructor call is really compiled
> >into the code.
>
> umm... no it isn't
>
> test.java:
> public class test {
> public static void main (String[] args) {
> String a = "aaa";
> String b = new String("bbb");
> System.out.println("---");
> System.out.println(a);
> System.out.println(b);
> }
> }
>
> Jikes produced bytecode:
> Method void main(java.lang.String[])
> 0 ldc #9
> 2 astore_1
> 3 new #11
> 6 dup
> 7 ldc #13
> 9 invokespecial #18
>12 astore_2
>13 getstatic #22
>16 ldc #25
>18 invokevirtual #29
>21 getstatic #22
>24 aload_1
>25 invokevirtual #29
>28 getstatic #22
>31 aload_2
>32 invokevirtual #29
>35 return
>
> as you can clearly see there is only one call to the String ctor,
> and that is for b not a. Doing otherwise would be a violation of
> the VM spec. Javac in 118 and 130 emit similar bytecode.
>
> Jacob, another point I forgot to mention in my offlist reply was
> that duplicating a String in java is potentially more than a byte
> array copy... Strings have to be "internalized" which isn't always
> cheap in either time or resources.
>
> --
> 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]
making executable of bytecode ....
Hello , I am searching from last one week over the net for software which converts the given bytecode into the executable format.Does anyone have any idea about this.If so please mail me , I am in desperate need of it. Thank U, Satish -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making executable of bytecode ....
Check out the Java front-end to gcc (GCJ): http://sources.redhat.com/java/ Peace. Tom satish <[EMAIL PROTECTED]> on 09/08/2000 09:18:29 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Tom Williams/HQ/dssi) Subject: making executable of bytecode Hello , I am searching from last one week over the net for software which converts the given bytecode into the executable format.Does anyone have any idea about this.If so please mail me , I am in desperate need of it. Thank U, Satish -- 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]
Sun JDK 1.3.0 RC
Note the Java[TM] 2 Platform, Standard Edition (J2SETM), v 1.3 for Linux, Release Candidate on http://developer.java.sun.com/developer/earlyAccess/j2sdk13/download-linux.html Cafe au Lait says "There aren't any new features here, just bug fixes and performance improvements." Still, some interesting results when compared to IBM's current service refresh of August 18. Fellow Linux aficionados, assuming the final version doesn't take anything away from the release candidate, we are about to have two (or maybe make that three when one considers jitc, HotSpot Client, and HotSpot Server) winners here. Congratulations Sun, and thank you. -- Jonathan Doughty The MITRE Corporation [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making executable of bytecode ....
On Fri, Sep 08, 2000 at 09:48:29PM +0530, satish wrote: > > Hello , > > I am searching from last one week over the net for software which converts > the given bytecode into the executable format.Does anyone have any idea about > this.If so please mail me , I am in desperate need of it. Look at the gcj project - http://sources.redhat.com/java/ - it can compile to native from source or bytecodes. It's not up to full JDK1.2 support, but it's getting better all the time. Nathan > > Thank U, > Satish > > > -- > 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: Sun JDK 1.3.0 RC
Jonathan Doughty wrote: > > Note the Java[TM] 2 Platform, Standard Edition (J2SETM), v 1.3 for > Linux, Release Candidate on > http://developer.java.sun.com/developer/earlyAccess/j2sdk13/download-linux.html > > Cafe au Lait says "There aren't any new features here, just bug fixes > and performance improvements." Still, some interesting results when > compared to IBM's current service refresh of August 18. > > Fellow Linux aficionados, assuming the final version doesn't take anything > away from the release candidate, we are about to have two (or maybe make > that three when one considers jitc, HotSpot Client, and HotSpot Server) > winners here. Congratulations Sun, and thank you. > -- I tried to download the bugger last night, from three different ftp links and the http link, and using both Netscape and Lynx. The slightly-truncated file won't install itself because it fails its checksum test. Every single download hung at the last 64K of the file. I've never had this happen before, and never on both browsers. I was here until almost midnight last night trying to complete a download and finally gave up. Grump. If anyone is actually able to download the thing, could you post something here? I'm not going to spend another hour downloading 28megs of RC until I know I have a chance of succeeding. -- Joi EllisSoftware Engineer Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] No matter what we think of Linux versus FreeBSD, etc., the one thing I really like about Linux is that it has Microsoft worried. Anything that kicks a monopoly in the pants has got to be good for something. - Chris Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun JDK 1.3.0 RC
Jonathan Doughty wrote: > > Note the Java[TM] 2 Platform, Standard Edition (J2SETM), v 1.3 for > Linux, Release Candidate on > http://developer.java.sun.com/developer/earlyAccess/j2sdk13/download-linux.html > > Cafe au Lait says "There aren't any new features here, just bug fixes > and performance improvements." Still, some interesting results when > compared to IBM's current service refresh of August 18. > > Fellow Linux aficionados, assuming the final version doesn't take anything > away from the release candidate, we are about to have two (or maybe make > that three when one considers jitc, HotSpot Client, and HotSpot Server) > winners here. Congratulations Sun, and thank you. No congratulations until Java is Open Source !!! :) -- ** Should SUN Open Source Java? Please Vote: http://relativity.yi.org/java ** Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey: burtonator) http://relativity.yi.org | http://www.openprivacy.org Message to SUN Microsystems: "Please Open Source Java!" To fight and conquer in all your battles is not supreme excellence; supreme excellence consists in breaking the enemy's resistance without fighting. - Sun Tzu, 300 B.C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun JDK 1.3.0 RC
I was able to get the RPM downloaded and it checksummed ok, but the install failed because "glibc >= 2.1.2-11 is needed by jre-1.3-rc1". I have glibc-2.1.3 installed on my RedHat system. Go figure... Peace. Tom Joi Ellis <[EMAIL PROTECTED]> on 09/08/2000 01:05:57 PM Please respond to [EMAIL PROTECTED] To: Jonathan Doughty <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] (bcc: Tom Williams/HQ/dssi) Subject: Re: Sun JDK 1.3.0 RC Jonathan Doughty wrote: > > Note the Java[TM] 2 Platform, Standard Edition (J2SETM), v 1.3 for > Linux, Release Candidate on > http://developer.java.sun.com/developer/earlyAccess/j2sdk13/download-linux. html > > Cafe au Lait says "There aren't any new features here, just bug fixes > and performance improvements." Still, some interesting results when > compared to IBM's current service refresh of August 18. > > Fellow Linux aficionados, assuming the final version doesn't take anything > away from the release candidate, we are about to have two (or maybe make > that three when one considers jitc, HotSpot Client, and HotSpot Server) > winners here. Congratulations Sun, and thank you. > -- I tried to download the bugger last night, from three different ftp links and the http link, and using both Netscape and Lynx. The slightly-truncated file won't install itself because it fails its checksum test. Every single download hung at the last 64K of the file. I've never had this happen before, and never on both browsers. I was here until almost midnight last night trying to complete a download and finally gave up. Grump. If anyone is actually able to download the thing, could you post something here? I'm not going to spend another hour downloading 28megs of RC until I know I have a chance of succeeding. -- Joi EllisSoftware Engineer Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] No matter what we think of Linux versus FreeBSD, etc., the one thing I really like about Linux is that it has Microsoft worried. Anything that kicks a monopoly in the pants has got to be good for something. - Chris Johnson -- 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: Sun JDK 1.3.0 RC
On Fri, 8 Sep 2000, Joi Ellis wrote: [snipped] > I tried to download the bugger last night, from three different > ftp links and the http link, and using both Netscape and Lynx. > The slightly-truncated file won't install itself because it fails > its checksum test. > > Every single download hung at the last 64K of the file. I've never > had this happen before, and never on both browsers. > > I was here until almost midnight last night trying to complete a > download and finally gave up. Grump. > > If anyone is actually able to download the thing, could you post > something here? I'm not going to spend another hour downloading > 28megs of RC until I know I have a chance of succeeding. > I just downloaded it from the main ftp site: ftp.java.sun.com It took about 4 minutes on a fairly good pipe here at work. I ran the script to unpack it, and tested the rpm. I didn't see any errors, but I'm not ready yet to install it until I get home and have a better environment to play around with. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun JDK 1.3.0 RC
Man Chi Ly wrote: > > [snipped] > > I just downloaded it from the main ftp site: ftp.java.sun.com > It took about 4 minutes on a fairly good pipe here at work. I ran the > script to unpack it, and tested the rpm. I didn't see any errors, but I'm > not ready yet to install it until I get home and have a better environment > to play around with. I just tried both the tarball and the rpm and they both hung at the last bit. :( I'm going to try lynx from my isp next. -- Joi EllisSoftware Engineer Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] No matter what we think of Linux versus FreeBSD, etc., the one thing I really like about Linux is that it has Microsoft worried. Anything that kicks a monopoly in the pants has got to be good for something. - Chris Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who is right?
At 09:08 9/8/00 -0400, Jacob Nikom wrote: >I would like to thank all people in discussion, especially Chris. your welcome. :) >I had never looked at bytecodes before. As far as I see the >call to the String constructor is in the line 3. the bytecode at offset 3: 3 new #11 is an instance of the "new" bytecode which creates a new reference on the stack, it is NOT equivalent to the java keyword of the same name. Check out the VM Spec for details. For comparison, the bytecode at offset 9: 9 invokespecial #18 *is* a call to a constructor... specifically the ctor for Sting, that takes a string - which was pushed onto the stack by the byte code at offset 7. >It is interesting to know how different bytecodes could be in >different compilers. even in the "same" compiler there can be WORLDs of difference... compare the output of javac in 1.1.x and 1.2 against that in 1.3; the difference is non-trivial. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
