Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Oct 2001 00:52:08 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Chad David <davidc@acns.ab.ca>
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:  <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>

next in thread | previous in thread | raw e-mail | index | archive | help
Chad David wrote:
> 
> On Tue, Oct 30, 2001 at 08:18:36AM -0800, Terry Lambert wrote:
> > Nate Williams wrote:
> > > > 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).
> 
>         What does this have to do with multiple inheritance?  Every
>         major java server I've every written did exactly this, and
>         a base class being a constant is a must.  I don't see how
>         multiple inheritance would change this.

Nate suggested using interfaces in place of multiple inheritance.

If I do that, then the backing object is opaque, which it can't
be, if I need to marshall it.


> > 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).
> 
>         Could you give a more concrete example of what you are
>         talking about.  If you are arguing that using reflection
>         is not pure then I might agree (if you have a better way).

Yes; specifically, in the case where both ends of the relationship
have a cardinality > 1.  8-p.


>         Also, I've observed the exact opposite, you need reflection
>         to stop the common parts from acting common, ie. in order to
>         cast the base class to its real type.

My problem is when the real type is unknown to an intermediary.
For the Java Mail API, think "MIME Type".


>         Have you ever taken a look at SableCC?  They make very
>         effective use of interfaces without every using reflection
>         or multiple inheritance.

I've played with this, and with the stuff that Warner Losh
used to work on way back when, when Motif was theoretically
not dictating API, but only "look and feel".

I'd argue that it's a bit contrived.


> > Java is really "dumbed down" in order to make it safe for
> > people who aren't very meticulous about their coding.
> 
>         I think this is a very easy statement to make without
>         actually giving the language any of its due credit.  I
>         spent four indepth years with java, and while I do not
>         miss it, I do have a respect for it in its place.
> 
>         Come to think of it, C is really "dumbed down" in order
>         to make it safe for people who aren't very meticulous
>         about their [assembly] coding. :).

Sure.  That's a true statement as well.  I'm willing to have
my personal favorite language tarred with the same brush, if
it's rightous.  8-).

The thing that annoys me with Java is that I either have to
work around the limitation with a lot of code, or I have to
drop down to a JNI to another language.  Most of my examples
of this are code I don't have access to any more, but they
are all almost invariably tied to the language needing to be
able to be run as interpreted byte code (and everyone has
seen my diatrives on interpreted languages like Perl, so I
don't need to repeat them).


> > 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).

> > 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.
> 
>         I would like to see an Objective C like implementation
>         for java, but I fear some of the language and class
>         interation design decisions may make that very difficult
>         to actually acheive.

Actually, I like Java far more than I like Objective C, and I
saw Objective C back when the first NeXT cubes were coming out,
and liked it somewhat then.


> > 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-).


>         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-).

The footprint problem is annoying; you really need the concept
of a single JVM with multiple processes in seperate protection
domains.  I haven't seen anything, other than the hadware Java
machines (non-virtual) that could approach this.

I'd also feel real silly, carrying around my Java machine
hardware on a ring, like some nerd version of The Green Lantern.

8-) 8-).

-- Terry

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?3BDFBBB8.EE7E9482>