Date: Tue, 30 Oct 2001 09:36:58 -0700 From: Nate Williams <nate@yogotech.com> To: tlambert2@mindspring.com Cc: 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: <15326.55082.743110.502241@caddis.yogotech.com> In-Reply-To: <3BDED2DC.A04B6822@mindspring.com> References: <XFMail.011029134349.jhb@FreeBSD.org> <3BDE6ED3.64DC027E@mindspring.com> <15326.50508.909158.688936@caddis.yogotech.com> <3BDED2DC.A04B6822@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Java has several problems: > > > > > > 1) It can't do multiple inheritance > > > > This is certainly not a problem. This is a good thing, and one of the > > strengths of Java. It doesn't bring in all of the *crap* that C++ does. > > In any case, you can perform almost all of the same functionality using > > interfaces, in a much cleaner fashion. I've yet to find a good example > > of multiple inheritance that couldn't also be done in a simpler fashion > > using Java + inheritance. > > I've run into several instances where I needed to marshall > objects from a local node to a remote node, and then reinstance > them, without explicitly knowing anything other than that they > inherit from a particular class, and then later marshall them > again (either back or elsewhere). Using interfaces + Serialization, this is trivial, as well as much cleaner than in C++, IMO. I did this all the time in my last Java application. > I've also seen a number of design patterns that could not > be used without a bridge pattern because of the lack of > multiple inheritance (i.e. instead of doing an overlay of > the common parts of two or more patterns, you had to use > reflection to make the common parts act common, even though > they weren't actually common). Again, my experience is quite the opposite. We implemented so many design patterns from the book directly in Java in a *much* easier to understand way than the C++ implementations that I was forever convinced that C++ should be killed dead. (Unfortunately, my new job has me doing C++ development, which I absolutely hate.) > Java is really "dumbed down" in order to make it safe for people who > aren't very meticulous about their coding. Yeah right. I've been doing C/C++ coding for 16 years, and *EVERY* single person I've spoken with that has done significant coding in both C++ and Java would choose the latter in a heartbeat, since it allows them to focus on the problem at hand, rather than the language. Again, you're being elitist, especially considering you've never coded up anything significant in Java. > > > 2) You can instance classes without constructing them (the > > > JavaMail API has a number of examples of this) > > > > And your point is? > > Instance but unconstructed objects are inherently bad. Because? Static classes are a necessary evil (IMO), and is what makes the Java language useful, vs. a nice CS solution. (In theory, one never needs unconstructed objects, but in practice things are very different.) The use of static classes are what makes the language able to handle most of design patterns in a simple manner. > > > 3) Strong typing is for weak minds > > > > That's an elitist attitude from someone who hasn't tried using it. > > I've implemented the majority of the Java 1.2 and JavaX 1.2 > classes, as well as the JavaMail API in C++. I actually re-implemented parts of the JavaMail API in Perl once, and it was pretty trivial. I wouldn't call it a 'significant' programming challenge to re-implement the classes. What I find interesting is that you didn't choose a C++ class as the basic for implementing the API. Also, what JavaX extensions did you implement? There are about a zillion of them. > I've also done not an inconsiderable amount of work in Rational Rose > with "plain old Java". RR is not a Java product, IMO. Claiming to be a Java programmer because you used RR is like saying you're a Basic programmer because you made a nice QUI in V-Basic. > I think that historically, we will find that Java will end up > being a compiled language, and will serve predominantly as a > cross platform API. That's your call to make. I don't see it happening, as there still isn't a single usable compiler for Java. (The closest one to being usable is TowerJ, but it leaves out all of the AWT/Swing/GUI classes, making it less than useful.) > This is, I think, the reason that Microsoft targeted it for > the "embrace and extend" treatment. Java on M$ is a dead product. > The inability to apply a decent optimizer to JIT'ed code is > just the icing on the cake. Actually, you haven't done much lately, since the new JIT's are quite usable. (However, I've found that I can get close to native speed by optimizing my Java code, which is *infinitely* easier to do in Java than in any other language since the tools have access to a much larger > FWIW: dynamic scoping is cool; but garbage collection is not > something one can afford, when designing an embedded system. Blanket statements like that prove that you are being elitist. You really should get out more often Terry. > The InterJet, going forward, was intended to have much code > in Java (in fact, it had some interesting Java code from the > IBM Almaden research center in it); IBM has done some very interesting work with Java. We're using some of the stuff as well. (In particular, their Java compiler, JIKES rocks!) > Archie Cobbs is also a > major contributor to Kaffe, and was one of the primary > developers on the InterJet. I'm aware of Archie's work. He's continued to keep up the FreeBSD port of Jikes, which I continue to use for my Java non-paywork. We attempted to use Kaffe for our Java product, and kept giving up in disgust. The final straw was when M$ bought the primary Kaffe developers off which effectively killed the product. The basic Sun JVM w/out a JIT out-performed Kaffe with a JIT, because of bugs and non-support for many of the Java 1.1 features, and some bugs in the Java 1.0 support. Don't compare Java using Kaffe with Java performance. (And, I understand that cost was the primary reason that Whistle chose Kaffe vs. Sun's JVM, but it's still unfair to imply that using Kaffe for your JVM is a fair comparison to how Java performs.) > That said, the overhead of using Java was _significant_, and > one of the things we had to do (add a more powerful CPU and > more RAM) pushed in a number of undesirable attributes, as > wll, including, but not limited to, the addition of moving > parts to the product (fans) to dissipate the increased heat > from the increased hardware bulk required. *laugh* You are entertaining, if nothing else Terry. I can give you counter-proposals about how a Java implemented solution used *LESS* CPU and RAM than a functionally equal C++ application. 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?15326.55082.743110.502241>