Date: Wed, 31 Oct 2001 09:56:44 -0700 From: Nate Williams <nate@yogotech.com> To: tlambert2@mindspring.com Cc: Chad David <davidc@acns.ab.ca>, Nate Williams <nate@yogotech.com>, John Baldwin <jhb@FreeBSD.ORG>, chat@FreeBSD.ORG Subject: Re: time_t not to change size on x86 Message-ID: <15328.11596.96289.16985@caddis.yogotech.com> In-Reply-To: <3BDFBBB8.EE7E9482@mindspring.com> References: <XFMail.011029134349.jhb@FreeBSD.org> <3BDE6ED3.64DC027E@mindspring.com> <15326.50508.909158.688936@caddis.yogotech.com> <3BDED2DC.A04B6822@mindspring.com> <20011030110629.A3499@colnta.acns.ab.ca> <3BDFBBB8.EE7E9482@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Instance but unconstructed objects are inherently bad. > > > > Again could you give an example. I don't really understand > > what you mean. I am unaware of any way of creating an object > > without invoking one of a classes constructors. The Serialization > > classes do it via a native method (since a class may not have > > a predictable constructor signature). > > You need to read the JavaMail API. The problem is that you > can construct unitialized objects, which are then indistinguishable > from initialized objects (except that they don't work, if you > forget that they're not initialized, so you can't treat them as > opaque members without dealing with the "if not initialized" in a > lot more places than you really want to). In Java, you can not construct uninitialized objects. You can do call methods on objects, but these methods are 'static' methods, whose only purpose is to allow you call methods that don't require an object to work. A good example of this in Math.sin(), which doesn't require any object instantiated in order to perform the operation. If you have classes that are not fully initialized, then it's an implementation issue, which can be done just as easily (or badly) in C++ as it can be done in Java. > > > FWIW: dynamic scoping is cool; but garbage collection is not > > > something one can afford, when designing an embedded system. > > > > Have you ever worked with the Real-Time Specification? > > I do not know anybody who has... > > I've seen it (there are some nice things about being inside > IBM's firewall that I dearly miss); it didn't really impress > me very much, but that was just an appraisal without having > to code in the environment, so I can't tell you if it would > magically make things better. 8-). The non-SUN Real-Time spec. had some good things. This was the specification done by HP and M$, which I think was being driven by HP. It's been awhile since I looked at it, though they dealt with things such as memory footprint, response times, etc.. > > I agree entirely that the size and speed of java is its > > weakest point. The memory footprint of two or three > > jvm's on a server is just stupid, and GUI's are way > > to slow... makes me want to go back to win32. > > I actually _like_ the GUI code; takes all kinds, I guess. 8-). Our latest foray into Win32 + MFC has shown that Java is actually *significantly* faster. (We have two applications, the Java one, and the win32/MFC application. The Java app runs circles around the win32 app that implements the same functionality. We dropped the Java development because it didn't have a 'Windows Look and Feel'.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15328.11596.96289.16985>