> > (Geek alert: shared libraries enable executable binaries to use
> > less memory than they would otherwise. .....
> > [ ... ]
>
> Can't answer why you felt compelled to write <g>
are you kidding? geeks live and breathe for the opportunity to drop
a discussion like this into normal conversation. ;-)
> but this raises some
> questions in my (admittedly very non-knowledgeable) pea-brain:
>
> How does this relate to Java? That is, I thought part of the
> attractiveness of Java was the ability to break things up in to
> "clumps" ... I've envisioned it as modular -- plug in the parts you
> need, share the parts that are common.
same general idea.. Java just has a more mature way of dealing with
shared libraries in the source code.
the older model of shared libraries, and libraries in general, is
roughly like normal food preparation. you don't have to buy a new
food processor every time you want to make dinner, you can spend the
time and money to get a really good one, then re-use it over and over.
you can even use it for several different recipes at more or less the
same time. re-using the food processor is basically the same as
putting code in a library for future reuse. organizing your food
prep in a way that lets you do all your food processing at once, so
the machine can be cleaned and put away to free up more counter space
is what shared libraries are all about.
the key assumption in that system is that the food processor is a
generic, active machine that operates on a wide range of passive food
products. your carrots don't participate in the dicing process, they
just sit there and get chopped up. organizational strategies under
that model mostly involve queueing things up so they can be run
through the machine efficiently.
Java, being an object-oriented language, has a different way of
looking at things. instead of seeing a food processor as a single,
stand-alone machine, it looks at all the various types of chopping,
dicing, and mixing you want to do. for each task, there will be a
'dream machine' which would do that specific job as well as possible.
all of those machines would share a common, basic design.. they'll
need something to hold the food, something to do the chopping, a motor
to drive said chopper, and a way of getting power to the motor. the
trick of OOP is to define standard interfaces between those components
so you end up with something more like a LEGO set for the kitchen.
some of the components will be designed for general reuse, like the
power systems and motors. as long as the interfaces are always the
same, you can use anything from batteries to a nuclear pile for power,
and your motors can have any combination of torque and RPM. the
chopper part can be anything from a wire whisk to a mulching mower
blade (for *serious* julienne fries), and the part that holds the food
can be just the right size to hold the amount you actually need.
breaking up the design in that way allows each piece to be made as
simply, and therefore as inexpensively, as possible. in an ideal
world, you could go to the grocery store and buy food that's already
in a chopper-ready container, instead of a plastic bag. in the
normal course of buying food, you'd be accumulating kitchenware, which
could then be brought back to the store and re-loaded from bulk
hoppers.
taking it back to computer terms, Java makes it easy (okay.. *easier*)
to design components with standard interfaces. each component can
then be treated as a (potentially) shared library, and the JVM can
track the pieces which are currently in use. if program B wants a
certain component, and program A is already using it, the JVM knows it
doesn't need to reload the entire package for that component.
there will always be a certain amount of duplication necessary when
code is shared, but making the potential for sharing a normal feature
encourages people to build better compilers. standardizing the way
code is shared makes it easier to define strategies that are fast and
efficient.
Microsoft has made a fortune running the same idea in reverse.. they
define standards by which pieces can plug together, but they declare
those standards proprietary and charge people to use them. they also
make their proprietary standards different from anyone else's, so that
once you start using them, you're stuck. then they control the
competition and lock people in further by making small, incremental
changes to the standards over time. the longer your product uses the
Microsoft standard, the more completely twisted up it becomes in the
Microsoft Way.
that's one of the reasons Microsoft wants Java dead.. a truly useful
set of standards for a programming environment would give people an
alternative to the Microsoft treadmill. that would give developers
and public demand the power to force decisions about OS development
into the market, not vice-versa.
mike stone <[EMAIL PROTECTED]> 'net geek..
been there, done that, have network, will travel.
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
