Slashdot Mirror
Apple Freezes Java Support for Cocoa
Nice2Cats writes "A little message on Apple's Developer Connection tells us that Cocoa for Java will get no new features after 10.4. The full text is:
'Features added to Cocoa in Mac OS X versions later than 10.4 will not be added to the Cocoa-Java programming interface. Therefore, you should develop Cocoa applications using Objective-C to take advantage of existing and upcoming Cocoa features.' Is this bad for Java, or bad for Apple, or bad for both, or doesn't anybody give a damn anyway?"
Recently, Microsoft announced "Digital Ink," a handwriting-recognition technology that many compare to Apple's InkWell, both respectively set to debut in the next major revisions of Windows and Mac OS X. As whenever similar technologies pop up at Microsoft, Apple Mac zealots ask a few questions: Was it developed in-house at Microsoft? Was it bought from a third-party? Grabbed from a sub-licensor?
The answer is that Digital Ink came directly from Apple, but the story behind how Microsoft was able to so simply buy InkWell and rename it for use in Windows is a tale of moral depravity and sordid carnal desperation that few are privy to until today! Read on to discover how Microsoft came to own yet another key Apple technology in the most sordid of political maneuverings.
It all began in the late Seventies. Steve Jobs, after a night of smoking marijuana and tripping on lysergic acid diethylamide, conceived of a way to interact with computers using only the mind. Well-known at Stanford for his telekinetic abilities, such as making entire fields of grass sway with but a thought, Steve wanted to move the "mouse" and "menu" (bizarre, alien concepts to anyone outside of his clique of 2600 hackers and EE alcoholics) with nothing but the power of his mind. Of course his compatriots the peaceful, bearded Steve Wozniak and the illegally immigrated Avie Tevanian dismissed the idea as yet another episode of harmless drug-induced rambling.
Twenty-six years after his messianic user interface vision, Steve Jobs was hard at work in the deepest part of Apple's labs, personally overseeing secret user interface experimentation. It turns out that Steve had never forgotten about his psychedelic user-interface dream and was tirelessly attempting to realize it thirty miles beneath Cupertino, Califnornia. Down here, in his "dungeon," the attempts to connect silicon to carbon were in full force and without regard to their subjects.
Some men had industrial-grade alligator clamps attached to their nipples and testicles which were randomly jolted with millions of volts of electricity in order to stimulate their brains. Other men had deadly mixtures of cocaine and heroin ("eight-balls") injected into their penises while being forced to watch gay porn. Another group endured horrible procedures in which their arms, legs, and scrotums were replaced with chimpanzee equivalents. One smaller group were forced to smoke opium eight hours a day while being whipped and beaten until they managed to move the cursor a pixel or two. The most successes, however, had come from Steve's own bizarre device dubbed "handJobs."
handJobs was a series of wires and electro-sensitive pads placed on the fingertips that allowed one to manipulate elements of the Mac OS GUI with simple motions. Steve Jobs, being telekinetic from years of tripping acid, wielded it more powerfully than anyone else in his RD dungeon. In fact, so powerful was his mind that he like to hook the wires and pads up to his own penis and controlled his Power Mac by means of pelvic thrusts and lewd gyrations of his hairy penis and scrotum.
Bill Gates, on a visit to the Apple Campus, accidentally stumbled onto handJobs in a moment that would change UI in computing forever. Feeling that he simply owned the Apple Campus as he did the rest of the world, Mr. Gates walked into Steve Jobs's private office without knocking. Steve was in the middle of "making love" to thin air, pants in a puddle at his ankles, hands on hips, thrusting his engorged member at the monitor! He had decided to take his latest revision of the device to his office to test out when Mr. Gates had walked in on him! Gates knew what he liked and liked what he saw, and began immediately bargaining with Jobs.
By the end of the day, Jobs had created a new technology agreement with Gates. Apple would begin partnering with Microsoft on alternative input technologies, and by late June MS would announce "Digital Ink" for Windows. In reality Digital Ink was a front, and b
Could this direction be to deal with the performance issues of Java on little endian systems like x86? Seems I recall reading that Java performance is generally better (or much better) on big endian systems such as Sparc (and, PPC970/G5). Given the migration to Intel, could it be the little endian performance issue (penalty?) is prompting them to make a preemptive move away from some of the Java support, so the Intel based Macs don't look like they perform badly for Java apps that are integrated tightly with Cocoa?
If memory serves, the performance penalty was related to numeric processing, including GUI interfaces.
I'm just speculating out loud, but that's the first thing I thought when I ready about this yesterday.
. 62,400 repetitions make one truth -- Brave New World, Aldous Huxley
The OpenStep Story
NeXT Computer Inc, and Sun Microsystems Inc. teamed up in late 1993 to push a free object layer API based on the NeXTSTEP object system. This agreement evolved into the OpenStep specification which was published by NeXT in a first draft back in summer 1994.
GNUstep Hype and History
Early on many developers (educational and business) realized that the NeXTSTEP environment provided a great tool and reduced the amount of time necessary for writing applications. Still the portability issue was hard to solve since these application were tied to machines running NeXTSTEP.
It was the team around Paul Kunz at SLAC who decided to port their application differently than others did. Instead of rewriting HippoDraw from scratch on the new system and only "reusing" the overall app design and ideas, they rewrote the objects their application depended upon...the NeXTSTEP object layer.
As a result they created the first version of libobjcX which enabled them to port HippoDraw to UNIX systems running X-Window without changing a single line of their applications source.
After the OpenStep initiative became public, The next logical step was to make a new "objcX" which would adhere to the new APIs.
GNUstep Implementation
The first thing that needed to be done was implement the FoundationKit as specified in OpenStep. The libobjects library was around even before the GNUstep idea was born, but it needed to be extended and repackaged to fulfill the FoundationKit's job. This has resulted in libobjects being renamed to the GNUstep Base Library; its new name signifies its important role as the underlying support for all of GNUstep.
The ApplicationKit is closely tied to the Display Postscript System because all of the graphics drawing is to be implemented in the Postscript language. The GNUstep developers realized implementing a Display Postscript System would be an incredible task so they decided take an approach which would allow the ApplicationKit to be implemented without necessarily having the Display Postscript System implemented.
The design involved splitting up the ApplicationKit implementation into two parts; a front-end and a back-end. The front-end would be independent of the graphics display system, so it would only implement behavior without performing any display operations. The back-end would be specific to a graphics display system and it would only need to perform the display operations for that graphics display system. The front-end is called the GNUstep GUI Library. The backend is called, simply, the GNUstep Backend.
You can get more detailed and technical information about the GNUstep implementation at the Developer Suite page.
Beyond OpenStep
While implementing a free software version of the OpenStep specification is a great idea; GNUstep is growing beyond this initial task to become a powerful development environment and a sophisticated user environment.
The GNUstep Database Library and The GNUstep 3D Kit are examples of two auxiliary projects that take OpenStep as the base API for extending into other areas; the former into database programming and the latter into 3D graphics.
More and more
A number of people and institutions are helping in this project.
But there are even more efforts which might be of interest to everybody who likes the GNUstep idea. A bunch of them is listed on our Resources page.
OpenStep compliance
The motivation behind GNUstep is to make porting our applications easier, to leverage the benefits of the Objective-C language, and to push the idea of OpenStep as a common object oriented API; especially on systems which are not covered by commercial implementations of this standard.
Our Time frame
Most GNU projects have no real time frame since all development is done for free. The current team is very interested in pushing the project ahead but "time" and "space" will remain limited. So if things are moving too slow for you... join and help us!