Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : BORL: Time to BUY! -- Ignore unavailable to you. Want to Upgrade?

To: David R who wrote (7547)	11/19/1997 11:20:00 PM
From: Kashish King	Respond to of 10836

QUESTIONS: In either a networked or disconnected environment, would it be possible to run 100% pure Java bytecode compiled into 100% pure Intel opcode by a Way Ahead of Time (WAT) compiler? What if any downside would be manifest with such an implementation? ANSWERS: Part I: A WAT compiler could be easily developed for Java on Intel, that's the historical approach, like duh. Part II: The only downside is the same downside we have for every other Windows language and/or system available today: the application must reside on your local system and if you want to upgrade you must initiate that process at your own leisure. The Java source is still happily running away on every other platform supported with Java support, and it will run on yours, too. It's just that you decide to install a pre-compiled version on your office's Windows 95 systems. No biggy, not an issue really. Fred, the Nerd Johnston in cube #45 refuses to use the WAT version, he runs off the server so if a class library change is detected he will get the latest version, immediately. Ginger in cube #7 has a laptop with a whopper hard-disk and prefers the WAT version since she is always unplugging from the network anyway. I am using ActiveX as an alternative to DLLs for software modules which must communicate with an executive after the executive has done been written. The executive gets the names of controls from the registry and allows the user to pick one and execute methods on that object. Everything on the both sides of the aisle are 100% pure C++ but we cannot pass objects across the gap. The mounds of code that would be required to bundle and unbundle simple types doesn't make it enomical, practical or reliable. Even passing an array is like pulling teeth. The reason is simple: the supported types are a small subset of VB types. Visual C++ 5.0 has this OCX grid which when added to your project generates several dozen files. The thing is riddled with numerous documented and undocumented bugs which render it almost unusable. To access, say, a column you have to write piles of hideous COM-like code instead of using simple method calls. The only samples are in VB, and since it's not officially part of MFC, it isn't supported. Nobody can tell me that MFC or some other framework could not have annihilated VB if they had two development teams working in parallel: one on VB and one on Visual C++. The bottom line is that Microsoft will pay for letting C++ twist in the wind when we all move to Java. It's garbage collection and security, not bytecode X = Opcode Y that is costing CPU cycles in Java. The performance will be taken care of.