Subject: RE: Intel the revenge. help! - question Fri Sep 18 10:03:12 1998 > > (Geek alert: shared libraries enable executable binaries to use > > less memory than they would otherwise. ..... > > [ ... ] > > Can't answer why you felt compelled to write 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.