[246] in java-interest
Re: unsubscribe.
daemon@ATHENA.MIT.EDU (Luis Quispe)
Thu Jun 8 23:38:06 1995
From: Luis Quispe <lquispe@nyxfer.blythe.org>
To: java-interest@java.sun.com
Date: Thu, 8 Jun 1995 23:12:31 -0500 (EST)
In-Reply-To: <9506080630.AA25829@java.sun.com> from "owner-java-interest-digest@java.sun.com" at Jun 7, 95 11:30:11 pm
>
> java-interest-digest Thursday, 8 June 1995 Volume 01 : Number 050
>
> In this issue:
>
> Re: Re: Native Methods Question
> Re: How much did C+@ influence Java
> Re: goto and switch
> can anyone help me
> Re: Re: Re: Native Methods Question
> Threads vs New White Paper
> Re: Threads vs New White Paper
> Re: goto and switch
> Re: Threads vs New White Paper
> Re: Threads vs New White Paper
> Re: Threads vs New White Paper
> Re: Threads vs New White Paper
> Do threads share data? (eg. NetworkServer)
> WServer
> Re: Threads vs New White Paper
>
> ----------------------------------------------------------------------
>
> From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
> Date: Wed, 7 Jun 1995 11:28:51 -0700
> Subject: Re: Re: Native Methods Question
>
> Kevin Collins wrote:
> I was trying to figure out how this "miracle happens here" was
> occurring. Let me ask a few more questions along this line :
>
> 1) "NEVER ..."
> How is native code called? Continuing with the File example, is
> the native method executed back on the server via some type of
> invocation from the client? I wish there was a picture of this
> in the documentation :)
>
> I'll consider that an RFE :-)
>
> If it is not invoked on the server, is the implication that the
> code, and therefore the Java class, are only useful to browsers
> running on the same platform as the native code was compiled?
>
> Yes.
>
> If native code is not somehow portable, then why/when/where
> would I want to use native code?
>
> Because you couldn't do something any other way.
>
> The easiest way to think of native code is as a non-portable implementation
> of a class method. Before you can use native code, that code has to be
> on the client somewhere, on Solaris this means that the shared library that
> contains the code is in your LD_LIBRARY_PATH, on Windows NT I think it means
> there is a DLL somewhere (I'm not at all familiar with the internals of the
> Windows NT version.)
>
> If I had separate libraries for all platforms available it would
> select the library based upon the platform of the browser?
>
> Classes that use native code libraries are currently distributed through
> an alternate channel (e.g. FTP). In a class distribution with native code
> there would be some .class files and one or more .so (or DLL) files. The
> user of this class would copy the classes into their class hierarchy or
> add the directory where the classes were located to their CLASSPATH. (how
> they do this is platform dependent, on Solaris you would just set the
> environment variable CLASSPATH to include the new directory.) Presumably
> if I downloaded the Solaris version of your classes you would not include
> Windows NT libraries as well. You would have 'n' files (where n was the
> number of platforms supported) Selection of the proper library is done
> by the user who knows what platform they are running on presumably.
>
> If I wanted to encapsulate an existing C library what would you
> think about just creating a message-based interface to it and
> communicating with it via Java networking calls only? Is this
> a reasonable approach? Could it be supported by the Java
> networking classes? Is there an obviously easier way?
>
> I think you would pay a high price for sending network messages to your
> library for very little benefit. Having recently ported yet another library
> (some PD DES code) I simply did this:
>
> class WrapperClass {
> int x; // global "state" for the library
> int y;
> int z;
> native void func1();
> native int func2(int x, int y);
> }
>
> In the wrapper I did this :
>
> void
> helper_setstate(struct HWrapperClass *x) {
> WrapperClass *foo = unhand(x);
> globalX = foo->x;
> globalY = foo->y;
> globalZ = foo->z;
> }
>
> void
> helper_getstate(struct HWrapperClass *x) {
> WrapperClass *foo = unhand(x);
> foo->x = globalX;
> foo->y = globalY;
> foo->z = globalZ;
> }
>
> void
> WrapperClass_func1(
> struct HWrapperClass *this)
> {
> helper_setstate(this);
> func1();
> helper_getstate(this);
> }
> ...
>
> The wrappers were easy to write once and the wrapper class was the new
> Java interface.
>
> Eventually there will be three levels of "code" :
> J-code - standard Java bytecodes that run on any Java runtime.
> M-code - J-code that has been further compiled into machine code.
> This code is now bound to the platform where it was further
> compiled however the original J-code is still portable.
> N-code - Native code, this code was written for a specific platform
> and for a specific purpose.
>
> The goal is to let you distribute everything as J-code since that is one of
> the main features of Java. We'd like to produce M-code on platforms that
> have a second stage compiler on those classes that can greatly benefit from
> it (String comes to mind). Its still unclear to me (which is not to say its
> unclear to other folks more closely tied to the second stage compiler) whether
> second stage compilation will occur automatically or on a case by case basis.
> And N-code when you either have to support legacy code or you have something
> that lends itself to the extra work (a 3D library that knows about hardware
> accellerators comes to mind.)
>
> - --Chuck
>
> ------------------------------
>
> From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
> Date: Wed, 7 Jun 1995 11:51:01 -0700
> Subject: Re: How much did C+@ influence Java
>
> Hi Peter,
>
> > I think I have a pretty good idea what the answer is but here goes anyway:
> >
> > For those of you that don't read comp.lang.c++ a poster is alluding to the
> > fact that a copy of the C+@ language was seen by Java designers and helped
> > to influence the design of Java.
> >
> > Would anyone want to comment on the veracity of such remarks.
>
> I've heard about it but I've never seen it. I don't think it influenced
> the design of Java at all. Any similarties are purely coincidental B^)
> Actually, we've heard from other projects that were developing
> languages very similar to Java. Some of them are now using Java
> instead.
>
> Have fun,
>
> Arthur van Hoff (avh@eng.sun.com)
> http://java.sun.com/people/avh/
> Sun Microsystems Inc, M/S UPAL02-301,
> 100 Hamilton Avenue, Palo Alto CA 94301, USA
> Tel: +1 415 473 7242, Fax: +1 415 473 7104
>
> ------------------------------
>
> From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
> Date: Wed, 7 Jun 1995 12:00:28 -0700
> Subject: Re: goto and switch
>
> Hi Jeremy,
>
> > > > My concern is that inlining the constants from
> > > > another class is effectively inlining part of the implementation which
> > > > could change between compile time and link time, and therefore
> > > > change the semantics without any obvious errors.
> > >
> > > Your concern is a valid concern. The avoid this somewhat the compiler
> > > automatically does dependency checks (it has a build in make). But you
> > > are right that the problems not go away completely.
> >
> > Yes. The compiler has no control over what version of a class the
> > code it's currently compiling will eventually bind against, and
> > you might be compiling against a class which you have no source
> > for.
>
> Actually, the value of final variables is stored in the class file
> so that it can be inlined even when the source if not available.
>
> > > The bottom line is that, if you are really concerned about changing
> > > an interface in incompatible ways, then you should not use constants,
> > > use variables instead. We chose to inline constants for efficiency,
> > > this has the unfortunate side effect of making interfaces a little
> > > more brittle. However, it is not obvious whether the alternative would
> > > result in acceptable performance.
> >
> > Because all the switches would become if-else trees? Or just
> > because there'd be lots of lookups instead of inline constants?
> > Surely if the compiler didn't inline another class's constants,
> > the runtime could when it saw a class access another class's member
> > which is final? Of course, to get the full effect the runtime
> > would have to do some local rewrites of the bytecode, but that
> > isn't very expensive.
>
> How would you deal with the case where two case labels turn out
> to have the same value at runtime? It is not clear if you can
> write all switch statements as if-then-else trees.
>
> By the way, I've thought about this a lot. I really wanted a
> way to use Strings as case labels. It turned out to be too hard
> given the semantics of the switch statement.
>
> Have fun,
>
> Arthur van Hoff,
> x47242, UPAL02-301
> http://tachyon.eng/~avh/
>
>
> ------------------------------
>
> From: rdp@npr.legent.com (Robert D. Palm)
> Date: Wed, 7 Jun 1995 13:59:08 -0500 (CDT)
> Subject: can anyone help me
>
> I'm trying to track down Henry McGilton. He's an old friend that I've lost
> touch with and I know he's involved with Java. Can anyone send me his e-mail
> address?
>
> Thanks!
> --Bob Palm
>
> ------------------------------
>
> From: Kevin Collins <kevinc@hppcih58.fc.hp.com>
> Date: Wed, 7 Jun 1995 13:17:54 -0600
> Subject: Re: Re: Re: Native Methods Question
>
> Thanks again, one more small follow-up, for now ...
>
> > Classes that use native code libraries are currently distributed through
> > an alternate channel (e.g. FTP). In a class distribution with native code
> > there would be some .class files and one or more .so (or DLL) files. The
> > user of this class would copy the classes into their class hierarchy or
> > add the directory where the classes were located to their CLASSPATH. (how
> > they do this is platform dependent, on Solaris you would just set the
> > environment variable CLASSPATH to include the new directory.) Presumably
> > if I downloaded the Solaris version of your classes you would not include
> > Windows NT libraries as well. You would have 'n' files (where n was the
> > number of platforms supported) Selection of the proper library is done
> > by the user who knows what platform they are running on presumably.
>
> So are you saying there would need to be a different URL for each platform
> that was supported? I was asking if I could somehow set up my classes and
> related native libraries in a single location and magically have a Solaris
> browser pick up the .so lib, NT the dll etc. Possibly a tall order I
> admit ...
>
>
> ------------------------------
>
> From: johnm@medicus.com (John Mitchell)
> Date: Wed, 7 Jun 95 13:47:28 PDT
> Subject: Threads vs New White Paper
>
> I have a printed copy of "The Java Language Environment" that was
> distributed at SunWorld '95.
>
> In Chapter 4 "Interpreted, Dynamic, Secure, and Threaded", on page 45
> in the section "Java Supports Threads at the Language Level" the
> last paragraph states:
> Java's threads are pre-emptive. If your applications are
> likely to be compute intensive, you might consider how to
> give up control periodically to give other threads a
> chance to run. This will insure better interactive
> response for graphical applications.
>
> So what's the deal? Are threads in Java pre-emptive or not? Or
> does it totally rely on the thread package built into Java on the
> runtime system?
>
> Either way the white paper should be fixed and the documentation
> of the Thread class should be amended to make this clear.
>
> Thanks,
> John
>
> ------------------------------
>
> From: jpayne@flim@Sun.COM (Jonathan Payne)
> Date: Wed, 7 Jun 1995 15:02:01 -0700
> Subject: Re: Threads vs New White Paper
>
> Java threads are preemptive in that if a threads a priority 5 is
> currently running and then a thread at priority 6 wants to run, the
> first thread is preempted.
>
> But if you have two threads both at priority 5, then the one which is
> running continues to run until it blocks, and then the other one gets
> a chance.
>
> On the other hand, the exact semantics do depend on the particular
> implementation. For instance, in green threads, which are what's used
> on solaris, I believe the following is true:
>
> Thread A is running at priority 5
> Thread B wants to run at priority 5.
> Thread C wants to run at priority 6.
> Thread C starts running, and then blocks.
> Thread B starts running.
>
> In other words, when a high priority thread preempts a lower one, then
> that lower priority thread is moved to the end of the queue of threads
> at that priority.
>
> God knows what happens on the NT version.
>
> > From: johnm@medicus.com (John Mitchell)
> > Date: Wed, 7 Jun 95 13:47:28 PDT
> > X-Mailer: ELM [version 2.3M PL11]
> > Sender: owner-java-interest@java.sun.com
> > Precedence: bulk
> > X-Info: To unsubscribe, send 'unsubscribe' to java-interest-request@java.sun.com
> > Content-Type: text
> > Content-Length: 919
> >
> > I have a printed copy of "The Java Language Environment" that was
> > distributed at SunWorld '95.
> >
> > In Chapter 4 "Interpreted, Dynamic, Secure, and Threaded", on page 45
> > in the section "Java Supports Threads at the Language Level" the
> > last paragraph states:
> > Java's threads are pre-emptive. If your applications are
> > likely to be compute intensive, you might consider how to
> > give up control periodically to give other threads a
> > chance to run. This will insure better interactive
> > response for graphical applications.
> >
> > So what's the deal? Are threads in Java pre-emptive or not? Or
> > does it totally rely on the thread package built into Java on the
> > runtime system?
> >
> > Either way the white paper should be fixed and the documentation
> > of the Thread class should be amended to make this clear.
> >
> > Thanks,
> > John
> > -
> > Note to Sun employees: this is an EXTERNAL mailing list!
> > Info: send 'help' to java-interest-request@java.sun.com
> >
>
> ------------------------------
>
> From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
> Date: Thu, 8 Jun 1995 00:52:45 +0000 (BST)
> Subject: Re: goto and switch
>
> AVH wrote:
>
> > Hi Jeremy,
> >
> > > > > My concern is that inlining the constants from
> > > > > another class is effectively inlining part of the implementation which
> > > > > could change between compile time and link time, and therefore
> > > > > change the semantics without any obvious errors.
> > > >
> > > > Your concern is a valid concern. The avoid this somewhat the compiler
> > > > automatically does dependency checks (it has a build in make). But you
> > > > are right that the problems not go away completely.
> [snip]
> > > > this has the unfortunate side effect of making interfaces a little
> > > > more brittle. However, it is not obvious whether the alternative would
> > > > result in acceptable performance.
> > >
> > > Because all the switches would become if-else trees? Or just
> > > because there'd be lots of lookups instead of inline constants?
> > > Surely if the compiler didn't inline another class's constants,
> > > the runtime could when it saw a class access another class's member
> > > which is final? Of course, to get the full effect the runtime
> > > would have to do some local rewrites of the bytecode, but that
> > > isn't very expensive.
> >
> > How would you deal with the case where two case labels turn out
> > to have the same value at runtime? It is not clear if you can
> > write all switch statements as if-then-else trees.
> >
> > By the way, I've thought about this a lot. I really wanted a
> > way to use Strings as case labels. It turned out to be too hard
> > given the semantics of the switch statement.
>
> If you have enumerated types, you can use the same trick that is used
> for method selectors: store enumeration constants as globally unique
> strings in class files, and for efficiency map these to locally unique
> numbers within each runtime.
>
> As long as you never reuse the same number for distinct enumeration
> constants of the same type, you are guaranteed to have distinct case
> labels within each switch statement.
>
> David Hopwood
> david.hopwood@lmh.ox.ac.uk
>
> ------------------------------
>
> From: johnm@medicus.com (John Mitchell)
> Date: Wed, 7 Jun 95 16:58:30 PDT
> Subject: Re: Threads vs New White Paper
>
> > Java threads are preemptive in that if a threads a priority 5 is
> > currently running and then a thread at priority 6 wants to run, the
> > first thread is preempted.
>
> Assuming that the underlying thread package supports preemption.
>
>
> > But if you have two threads both at priority 5, then the one which is
> > running continues to run until it blocks, and then the other one gets
> > a chance.
>
> I.e., some sort of round robin within each priority level?
>
>
> > On the other hand, the exact semantics do depend on the particular
> > implementation. For instance, in green threads, which are what's used
> > on solaris, I believe the following is true:
> >
> > Thread A is running at priority 5
> > Thread B wants to run at priority 5.
> > Thread C wants to run at priority 6.
> > Thread C starts running, and then blocks.
> > Thread B starts running.
> >
> > In other words, when a high priority thread preempts a lower one, then
> > that lower priority thread is moved to the end of the queue of threads
> > at that priority.
> >
> > God knows what happens on the NT version.
>
> So, my question becomes: what then is the *real* specification of the
> thread support in Java? I.e., if I as a developer cannot count on
> preemptive threading then I end up having to explicitly do all of that
> yield() calling crap. That's no better than not having thread support
> in the language.
>
> Thanks,
> John
>
> ------------------------------
>
> From: Jim.Graham@Eng.Sun.COM
> Date: Wed, 7 Jun 1995 17:20:33 -0700
> Subject: Re: Threads vs New White Paper
>
> Hi John,
>
> > So, my question becomes: what then is the *real* specification of the
> > thread support in Java? I.e., if I as a developer cannot count on
> > preemptive threading then I end up having to explicitly do all of that
> > yield() calling crap. That's no better than not having thread support
> > in the language.
>
> What Jon was saying is that the specification is:
>
> Higher priority threads are guaranteed to preempt lower
> priority threads when they become eligible to run.
>
> That is all. There is no guarantee that threads within a given
> priority will time slice or preempt each other when one becomes
> eligible to run, but such behaviour is also not prohibited. The
> current thread package on Solaris does not time slice. If we ported to
> native threads on Solaris we would presumably get time slicing for
> free, but neither is guaranteed.
>
> Absence of yield()'s in your code will not interfere with the operation
> of the browser since the UI code runs at a higher priority than the
> typical Applet thread, but other Applets may be starved. If you have
> a long calculation you can either yield, or you can run it at a lower
> priority to prevent starving Applets that are merely performing
> interaction calculations.
>
> ...jim
>
> ------------------------------
>
> From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
> Date: Wed, 7 Jun 1995 17:27:22 -0700
> Subject: Re: Threads vs New White Paper
>
> Hi John,
>
> > So, my question becomes: what then is the *real* specification of the
> > thread support in Java? I.e., if I as a developer cannot count on
> > preemptive threading then I end up having to explicitly do all of that
> > yield() calling crap. That's no better than not having thread support
> > in the language.
>
> The underlying implementation is guaranteed to be preemtive. On platforms
> that do not support thread preemtion (like the Mac), we'll make sure that
> the thread is rescheduled on the next opportunity. In our Mac port we
> check for this on every branch and method call. This "poor-mans" preemtion
> provides you with similar semantics as true preemption.
>
> Note that as Jon pointed out, threads of the same priority currently
> don't preemt each other. This may change in the future. It is likely
> that a native solaris thread implementation of our threads will even
> do time-slicing between various threads.
>
> Have fun,
>
> Arthur van Hoff (avh@eng.sun.com)
> http://java.sun.com/people/avh/
> Sun Microsystems Inc, M/S UPAL02-301,
> 100 Hamilton Avenue, Palo Alto CA 94301, USA
> Tel: +1 415 473 7242, Fax: +1 415 473 7104
>
>
> ------------------------------
>
> From: johnm@medicus.com (John Mitchell)
> Date: Wed, 7 Jun 95 18:53:26 PDT
> Subject: Re: Threads vs New White Paper
>
> [...]
> > The underlying implementation is guaranteed to be preemtive. On platforms
> > that do not support thread preemtion (like the Mac), we'll make sure that
> > the thread is rescheduled on the next opportunity. In our Mac port we
> > check for this on every branch and method call. This "poor-mans" preemtion
> > provides you with similar semantics as true preemption.
>
> This is plenty reasonable. Is this actually documented/specified
> somewhere?
>
>
> > Note that as Jon pointed out, threads of the same priority currently
> > don't preemt each other. This may change in the future.
> [...]
>
> IMHO, this is a Bad Thing(tm) and so I'll throw my $0.03 in to
> encourage y'all to change this. :-)
>
> Thanks,
> John
>
> P.S. A bunch of us stuck here using, gak!, C++, puke! are very
> interested in using Java in a 'standalone' manner. Kudos
> to the whole Java team.
>
> ------------------------------
>
> From: Kevin Campbell <kac@mh1.lbl.gov>
> Date: Wed, 7 Jun 1995 19:17:17 -0700 (PDT)
> Subject: Do threads share data? (eg. NetworkServer)
>
> Hi,
> I'm trying to extend the NetworkServer class to be the server for a
> distributed game (ok, it's tic-tac-toe for now). The problem I am having
> is that each time a client connects to the server a new server thread is
> spawned off, and I don't understand how they are supposed to communicate
> with each other. My understanding of threads is that they share the same
> data space, but the data members of my object don't seem to be shared.
> I have been unable to find any documentation on this, but I haven't
> read everything yet, so I would be happy to hear of somewhere I can read
> about it.
> I have included my very short extension to NetworkServer below. What I
> would like to have happen is that every time a new connection is
> established, the server prints out a message saying how many clients have
> connected so far. For my application I need to have state that is
> accessible from all server threads. I remember reading about conditions
> and locks in the White Paper, so there must be a way to do this.
>
> Thanks in advance,
> Kevin
>
> - ----------
> import net.NetworkServer;
>
> public class TTTServer extends NetworkServer {
> int reqnum = 0;
> public static void main(String argv[]) {
> new TTTServer().startServer(8889);
> }
> public void serviceRequest() {
> System.out.print("Servicing request #" + reqnum++ + "\n");
> }
> }
>
> ------------------------------
>
> From: Paul Beerkens <beerkens@prl.philips.co.uk>
> Date: Wed, 7 Jun 1995 08:59:43 +0100
> Subject: WServer
>
> Can somebody explain to me why this program generates an error message "Warning: Select failed; error code 2"
>
> class Testing {
> public static void main (String argv [])
> {
> awt.WServer MyWServer = new awt.WServer ();
> MyWServer.start ();
> for (int i=0;i++<100000;);
> MyWServer.stop ();
> };
> };
>
> Paul
>
>
> ------------------------------
>
> From: pdoane@pcnet.com (Patrick Doane)
> Date: Wed, 7 Jun 1995 23:42:36 -0400
> Subject: Re: Threads vs New White Paper
>
> >The underlying implementation is guaranteed to be preemtive. On platforms
> >that do not support thread preemtion (like the Mac), we'll make sure that
> >the thread is rescheduled on the next opportunity. In our Mac port we
> >check for this on every branch and method call. This "poor-mans" preemtion
> >provides you with similar semantics as true preemption.
>
> Pre-emptive threads are supported on the Macintosh, but only on 68k based
> machines. I don't know if Sun is only planning on supporting the PowerPC
> architecture, which at this time, currently doesn't support pre-emptive
> threads.
> I'm interested as to why the "poor-mans" approach was taken here to
> provide the pre-emptive model. Why not write a custom thread manager for
> the Macintosh Java implementation. I'm fairly sure that the OS support that
> exists is just using the Time Manager or some variant thereof. It seems to
> me that placing a yield() into every branch or method call would could
> cause the program to slow down considerably.
>
> I have been unable to see or use Java yet since I work almost exclusively
> on a Macintosh but I am extremely interested in it. I'm wondering what the
> compiler environment is like. Is there automatic support for projects or do
> you have to create your own make file? Any information I could get on it
> would be greatly appreciated.
>
> Patrick
>
>
>
> ------------------------------
>
> End of java-interest-digest V1 #50
> **********************************
>
--
The preceding was published by The New Flag (La Nueva Bandera),
a newsletter reporting on the contemporary Peruvian politics,
especially the developments of the People's War. Should you
like to subscribe, please write to:
The New Flag
30-08 Broadway, Suite 159
Queens, NY 11106
e-mail: lquispe@nyxfer.blythe.org
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
