Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apple Freezes Java Support for Cocoa

timothy posted more than 9 years ago | from the like-a-moolatte dept.

Java 154

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?"

cancel ×

154 comments

Sorry! There are no comments related to the filter you selected.

important (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13035674)

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 both it and InkWell for Mac OS were place-holders for what handJobs would eventually become. Until handJobs was ready, however, the masses would be fed OCR capabilities from the operating system. Before the ink on the contract was signed, however, Jobs had finagled Gates into receiving a "technology preview" of handJobs, with Jobs attempting to control Gate's breathing with nothing but his leathery scrotal sack and Gates's chin as a "touch pad."

Now you know the immoral, homo-erotic history behind InkWell, Digital Ink, and the next generation of OCR and handwriting-recogntion. I hope that Apple Macintosh zealots everywhere think about this before they blindly evangelize their operating system of choice, inadvertently infecting the minds of the masses with years of sweating gay RD and "bleeding edge" (of anus) techno-faggotry.

Re:important (0)

Anonymous Coward | more than 9 years ago | (#13036006)

Huh.

Re:important (0)

Anonymous Coward | more than 9 years ago | (#13038100)

Whew, you saved my life ! Dam, I wouldn't go near the thing knowing what I know now.

Toolkits (3, Interesting)

yasth (203461) | more than 9 years ago | (#13035681)

While it may not seem like such a big deal it complicates crossplatform toolkits, and the like. Of course the whole idea of having a "blessed" programming language seems rather old fashioned, and academic.

How? (5, Informative)

hargettp (74445) | more than 9 years ago | (#13036001)

Please remember, Java is still supported, it is simply the Cocoa-Java bridge that will no longer be improved. If you are not clear on what the Cocoa-Java bridge is (or event Cocoa), then here is a quick primer: Cocoa is the preferred API for Mac OS X, specifically for applications written in Objective-C. The Cocoa-Java bridge was a similar API that exposed essentially the same object model to Java based applications. As the API was specific to Mac OS X, any application written on top of the Java Cocoa APIs was specific to Mac OS X and thus not portable.

I would expect the impact to Java developers on OS X to be quite low. Most probably use Swing or SWT for cross-platform support, so the impact of this decision should be negligible.

Re:How? (1)

yasth (203461) | more than 9 years ago | (#13036399)

Well it limits the ease of someone creating a swing like thing that better integreated with the native OS. I mean it isn't a big loss just an annoyance. Like I said it only affects the toolkit authors not the users.

Re:Toolkits (1)

HTH NE1 (675604) | more than 9 years ago | (#13036070)

Apple registers "Numbers".
Cocoa Java frozen.

I have to wonder how will this affect the OpenOffice.Org port NeoOffice/J.

Re:Toolkits (0)

Anonymous Coward | more than 9 years ago | (#13036381)

It won't. The little bit of java they use is pure java, not Cocoa-Java.

Re:Toolkits (1, Interesting)

Frumious Wombat (845680) | more than 9 years ago | (#13036540)

Actually, this seems to be halfway to the Right Thing; you get rid of a non-portable extension to Java (good), but encourage people to use a minor (though clean) language for native-mode programming (iffy).

I've always wondered why that piece of NeXT heritage stuck around, as I'd be willing to wager a doughnut (pick your favorite pusher) that there are more Ada-programmers around than Objective-C gurus. (translation: take a deep breath, wave goodbye, and move to C++ or whatever the modern alternative compiled language would be, or at least make sure the library interfaces are correct for both languages).

Actually, I'd be just as happy, since they have the entire GNU compiler collection, is to simply define a uniform calling convention for their libraries from all languages, and stop worrying abou the One True Language. DEC did it back in the 80s with the Common Language Interface, which allowed me to call the same function (with pretty much the same syntax) from Fortran, C, or Pascal. I presume today that would mean using SWIG to generate a common set of wrappers, and remembering that there are Fortran, Ada, and C++ programmers out there somewhere when generating them.

Maybe my memory is fuzzy, but it seemed simpler to call those functions than on Unix systems where I always have to worry about the library interface on a language by language basis (one underscore or two; case-sensitive or not, etc.) I would like that level of transparency back.

C++ is not a replacement (4, Insightful)

mariox19 (632969) | more than 9 years ago | (#13036761)

With all due respect, have you tried Objective-C? It's far easier to learn than C++, and in some ways far more powerful. Objective-C is a dynamic (late-binding) language. The Cocoa framework could not have been written in C++ -- many, many decisions are made at run-time.

Don't get me wrong, I'm not one for "language wars"; I'm just saying that C++ is not a replacement. I'm not sure what is, given that Objective-C is fully compatible with C code -- all pointer and bit-twidling nonsense -- and dynamic.

Objective-C coders don't use the language grudgingly.

Re:C++ is not a replacement (2, Interesting)

1010011010 (53039) | more than 9 years ago | (#13037625)

Objective-C coders don't use the language grudgingly.

Since learning Objective-C, it's become my favorite C-type language. It's not something I have to use, it's something I like to use.

Re:C++ is not a replacement (3, Interesting)

entrylevel (559061) | more than 9 years ago | (#13037752)

I find it hard to believe you speak from experience. Did you write a program or did you just read some source code and figure some things out yourself? How long did you try at it? There's a lot to Objective-C, and being a superset of C is something I never saw as a detriment.

IMHO, it's far more elegant than C#, VB, or Java, used by millions (and loved by less). Certainly moreso than C or C++. It's not as elegant as Python, but few things are.

Most Objective-C programmers love the language a great deal and tend to be (at least on the Mac side) very vocal about it.

Re:C++ is not a replacement (1)

mariox19 (632969) | more than 9 years ago | (#13040978)

You're not talking to me are you? I'm all for Objective-C and I use it. I said that "Objective-C programmers don't use the language grudgingly" -- meaning, they enjoy using it.

Re:C++ is not a replacement (1)

entrylevel (559061) | more than 9 years ago | (#13041750)

So you did... My apologies on me unpossibly non-well English comprehension!

Re:Toolkits (2, Informative)

jericho4.0 (565125) | more than 9 years ago | (#13038133)

Objective-C is not some crufty old piece of legacy code that the old coots can't let go of. It's a stupidly simple, elegant extension to C. And there's a lot of good things in C, even with its "shoot yourself in the foot" power. C++ is far more complicated.

If you know C, a very small language, and are comfortable with objects, then you are an afternoon away from knowing Obj-C. The runtime delivers amazing flexibility, the reason why all the apps on OS X are so feature rich. The GNUStep implementation needs more, but is very powerful as is. It's a fabulous choice for a large system, where the "system" part is very important.

Again, the C to Obj-C transition is so easy that everyone who knows C should add it to their toolbox.

As I understand it, work on GNUStep themeing is coming along. I haven't checked it out in a while. The visuals really need freshening up.

Re:Toolkits (1)

the_greywolf (311406) | more than 9 years ago | (#13040067)

Again, the C to Obj-C transition is so easy that everyone who knows C should add it to their toolbox.

i know and use C as well as C++, and i'm quite comfortable in C++ (though Java is still completely foreign to me). i've been wanting and begging to learn Obj-C and C# to broaden my skillset, but non-.NET-specific resources on C# are disappointingly thin and i've been unable to find any books, turorials, or references on Obj-C anywhere. i've spent hours per day looking and have turned up very little. certainly nothing useful to me.

please, PLEASE point me to Obj-C resources so i can get learning!

Re:Toolkits (2, Informative)

jericho4.0 (565125) | more than 9 years ago | (#13040205)

gnustep links [gnustep.org]

The Apple stuff [apple.com] is well done, and much applies to GNUStep. The Apple community is the most active, of course.

Re:Toolkits (1)

harlows_monkeys (106428) | more than 9 years ago | (#13040048)

Actually, this seems to be halfway to the Right Thing; you get rid of a non-portable extension to Java (good)

What's good about getting rid of non-portable extensions? Some people lke Java as a general-purpose programming language, and want to use it, even when they are doing non-portable things.

ID-10-T Error (2, Insightful)

LordKazan (558383) | more than 9 years ago | (#13041292)

Anyone else see a contradiction in that statement, or is it just me?

What does this mean for WebObjects? (5, Interesting)

Millennium (2451) | more than 9 years ago | (#13035692)

WebObjects 4.5 had support for both Objective-C and Java, if my memory's right. In WebObjects 5.0, support for Objective-C was dropped, because this was during the time when Apple Wanted You To Use Java.

Now, of course, it seems as though Apple Doesn't Want You To Use Java Anymore. Does this mean that WO6 will drop Java support, or at least bring back Objective-C?

Re:What does this mean for WebObjects? (1, Redundant)

zsmooth (12005) | more than 9 years ago | (#13035745)

Let's hope so.

Re:What does this mean for WebObjects? (2, Insightful)

mr_rattles (303158) | more than 9 years ago | (#13035832)

I don't think this means anything for WebObjects. The announcement was very specific to the Cocoa-Java interface post-10.4 and nothing else.

This doesn't mean Apple doesn't want you using Java, it means they don't want people using Java for Cocoa applications after 10.4.

Re:What does this mean for WebObjects? (1)

Bin_jammin (684517) | more than 9 years ago | (#13036024)

No, WO6 will contain support for neither Objective-C or Java, but will instead be powered by pure wishful thinking.

Re:What does this mean for WebObjects? (4, Insightful)

Feral Bueller (615138) | more than 9 years ago | (#13036222)

"Now, of course, it seems as though Apple Doesn't Want You To Use Java Anymore. Does this mean that WO6 will drop Java support, or at least bring back Objective-C?"

Not. Really. It indicates that Apple wants you to use Java for Web services and Objective-C for applications. As previous poster already mentioned they are merely killing support for the Cocoa-Java API so I don't see there being much of an issue: I worked on a number of custom OS X apps at my last gig: this announcement would not have influenced any of our projects then and certainly wouldn't impact anything moving forward.

I'd be interested in hearing from an actual developer who *is* impacted by this.

Re:What does this mean for WebObjects? (3, Informative)

Yaztromo (655250) | more than 9 years ago | (#13037427)

I'd be interested in hearing from an actual developer who *is* impacted by this.

Hello! I'm here!

I'm doing some development using Cocoa-Java, and this could impact me, although as the information is extremely brief, I haven't figured out yet how or how much it will affect my work.

I'm in the situation where I already have a very large Java library which was written on other platforms (which has taken ~8 man-years of development effort, and has been heavily debugged and tested int hat time), but works flawlessly on OS X. The Swing application built atop it works on OS X, but many portions of its basic design don't work too well on OS X in terms of UI integration (it works, but it really looks like it was designed for another platform).

As such, to better support the Mac community, I decided one evening to create a Cocoa version using Cocoa-Java. It took me only about 2 hours of effort, and I had a native Mac version of my application that looks and acts like an OS X application, supporting all of the standard OS X controls and menu items.

Yes, Apple says I should just use Objective-C, but honestly I have years and years worth of work that has been put into the Java library and engine code. It's completely multi-platform, and is used on multiple platforms. Rewriting it in Objective-C isn't feasible from either a time standpoint, or from a platform availability standpoint (even if I did have years to rewrite and retest all this code in Objective-C, it would then only compile and run on OS X, and perhaps Linux if I was very careful). So it's not going to happen.

As such, I'm quite possibly impacted by this decision. However, the wording of the "annoucement" leaves much to be desired. Presumably based on their wording, they aren't dropping Cocoa-Java completely -- only that new Cocoa features won't be bridged. The GUI needs for my application are well served by the existing Cocoa-Java bindings, so if Cocoa-Java continues to be installed as a part of OS X, at least my application won't be unusuable before it is released to the public.

I am a bit surprised in some ways, however. With the announcement a few weeks ago of the move to Intel-based processors, I thought they might actually work to improve Cocoa-Java, due to its immediate cross-platform benefits (although Xcode 2.1 won't generate Universal Binaries for Cocoa-Java projects).

I'm holding out hope that OS X 10.5 and 10.6 don't drop the existing level of Cocoa-Java support. To be honest, I don't expect every feature of Cocoa to be made available to Java (as it doesn't always make sense to do so), so not putting anything new in, while disappointing, doesn't bother me a whole lot. It's the concern that at some point in the next few years Cocoa-Java could be dropped altogether that worries me.

Yaz.

Re:What does this mean for WebObjects? (2, Informative)

larkost (79011) | more than 9 years ago | (#13037760)

I think that you are fairly safe. Apple has mearly announced that they are not going to produce new bindings for anything after 10.4. They have not marked them depreciated in 10.4 (even then the old bindings would still work), so you have at least through 10.5, and quite likely through 10.6 until your apps are no longer supported. You might even make it to 10.7...

Re:What does this mean for WebObjects? (1)

am 2k (217885) | more than 9 years ago | (#13040299)

It's completely multi-platform, and is used on multiple platforms. Rewriting it in Objective-C isn't feasible from either a time standpoint, or from a platform availability standpoint (even if I did have years to rewrite and retest all this code in Objective-C, it would then only compile and run on OS X, and perhaps Linux if I was very careful). So it's not going to happen.

Ok, then write the controller part of the app using Objective C, and keep the model in Java. Problem solved. If you need some help on that, take a look at my article [cocoadevcentral.com] .

Re:What does this mean for WebObjects? (2, Informative)

putaro (235078) | more than 9 years ago | (#13038520)

I'd be interested in hearing from an actual developer who *is* impacted by this.

I am. We ship a commercial app for OS X which is Java/Cocoa. We wanted to have a good, native look and feel so we isolated the UI specific portions using a Model-View-Controller setup and have it running ontop of Cocoa and Swing. Swing does not provide a good enough Mac experience for a commercial app and SWT is not quite right either (the menu bar tends to go wonky, there's no support for sheets...)

Re:What does this mean for WebObjects? (0)

Anonymous Coward | more than 9 years ago | (#13039280)

NeoOffice/J is the only project I can think of that uses Cocoa-Java. Audacity uses Carbon, and they don't fully support long file names because of it. I think Apple's encouraging people to go with Cocoa o Xcode as much as possible because that's the easiest way to transition to Intel Macs. In a way they're not dropping support for Cocoa-Java, but dropping development for Cocoa-Java.

This only affects one app that I use... (4, Interesting)

Teancom (13486) | more than 9 years ago | (#13035695)

Cyberduck. It's the only cocoa-java app that I use, or even know about (not saying there aren't more, just that I don't know about them). Following the cocoa mailing lists, questions about the java bindings are few and far between, which probably lead them to this point. Why dump so much time and effort into a language that your developers aren't using? Either redirect the manpower somewhere else entirely, or into a language like python, which gives your users a meaningful choice - between objc (lowlevel) and python (scripting). And applescript, I guess :-)

Re:This only affects one app that I use... (1)

2starr (202647) | more than 9 years ago | (#13036271)

You'll find more discussion on the Java-dev mailing list... but not much. I think part of the problem is that the mentality behind Java is usually for cross-platform development. If I wanted to tie it to the OS, I'd be using Obj-C.

Re:This only affects one app that I use... (2, Informative)

Jeff DeMaagd (2015) | more than 9 years ago | (#13036654)

The thing is that the Coaco+Java stuff is what already works for Macintel computers, without porting, and it doesn't need a Universal Binary.

Re:This only affects one app that I use... (1)

WJMoore (830419) | more than 9 years ago | (#13039195)

Wow I've been using Cyberduck for ages and never knew it was a Java app. Sure enough a quick check of the CVS repository [cyberduck.ch] reveals that this is indeed the case. It shows how well the Cocoa-Java implementation is. However it does explain which Cyberduck can be a little unresponsive at times.

Probably not a big deal (4, Informative)

jtshaw (398319) | more than 9 years ago | (#13035719)

All this seams to say is that any new wizzbang features of Cocoa won't be directly accessable with Java... There are already features of the Windows and Linux UI's that Java doesn't use...

Fact is, Java apps will still work. Still look like MacOSX apps (at least as much as they do today). I don't see how this is much news really.

If they did have an interface to use these features, it would break cross platform compatibility anyway as they are bound to be Mac specific UI elements.

Re:Probably not a big deal (0)

Anonymous Coward | more than 9 years ago | (#13036678)

If they did have an interface to use these features, it would break cross platform compatibility anyway as they are bound to be Mac specific UI elements.

Uh, Cocoa-Java is not cross-platform to begin with--Cocoa is available only on OS X.

To clarify... (4, Informative)

Otter (3800) | more than 9 years ago | (#13035737)

After reading the comments at MacSlash, I figured it's worth clarifying here -- this has nothing to do with cross-platform Java applications (i.e. what "Java support" normally means). What's being pulled is the ability to write to the native Cocoa API in the Java language.

Good idea? As far as large software makers go, it probably doesn't matter. Adobe's Mac developers have all learned Objective C already. This does significantly raise the barrier of entry for hobbyist coders, though. Seems like a typical Apple decision, certainly.

Re:To clarify... (1)

Graymalkin (13732) | more than 9 years ago | (#13036185)

With the Aqua LAF for Swing having Cocoa available through Java doesn't do anyone much good. With a very simple "am I running on a Mac? [java.net] " if statement you can turn on the Aqua LAF and have a JMenuBar become the application's Mac menu bar. While being able to build a Java GUI in Interface Builder is nice it isn't something a whole lot of people are doing.

The biggest issue is in order to write Cocoa applications using Java you have to learn Cocoa. If you're going through that effort it is a lot simpler to spend the two days learning Objective-C and getting used to retain counts. You'll find there's a lot more support and documentation than writing Cocoa apps in Java.

When YellowBox was intended to run on Mach/PPC, Mach/x86 and NT/x86 a Java bridge likely made a lot of sense. A single application binary would run on any of those systems without recompilation. Java at the time was also seen as the Next Big Thing in application development. The plans for YellowBox never panned out and Java was not the Next Big Thing with client application development (despite its success on the server). It's entirely likely that the Java bridge will end up falling under the APSL and end up in the hands of third party maintainers or an entirely new bridge will be written by a third party.

Re:To clarify... (3, Insightful)

Yaztromo (655250) | more than 9 years ago | (#13036419)

The biggest issue is in order to write Cocoa applications using Java you have to learn Cocoa. If you're going through that effort it is a lot simpler to spend the two days learning Objective-C and getting used to retain counts. You'll find there's a lot more support and documentation than writing Cocoa apps in Java.

This line of reasoning bugs me, because it presupposes that you're building an application from scratch.

However, what if you have a large and specialized existing Java library that has taken years to write and has been very strenuously tested, and want to use it inside a Cocoa application? Cocoa-Java was excellent for this -- it took me less than an hour to build a Cocoa interface atop such a Java library, giving me much better integration with OS X's UI than Swing with an Aqua L&F ever would, with a lot less coding.

Yes, if you're building an application from scratch, Objective-C is a better option (I've developed some Obj-C Cocoa applications as well). But if you have an existing library which has taken you years to write in Java, why would you want to re-do all of that work in Objective-C, when you can just use Cocoa-Java?

I'm hoping we few of the Cocoa-Java community can convince Apple to release the Cocoa-Java framework to the Open Source community so we could contain to maintain and update it. The only consoltaion I'm gaining from the current "announcement" (if you can call it that) is that it looks like future versions of OS X will support Cocoa-Java -- they just won't be adding anything new to Cocoa-Java past 10.4. So at least my existing Cocoa-Java application (which is only in limited release at the moment) won't be completely obsolete the day it is released.

Yaz.

Re:To clarify... (1)

WatertonMan (550706) | more than 9 years ago | (#13039591)

Exactly how hard would it be to develop a Cocoa-Java bridge? If only to add extra features from Cocoa or even Carbon? I know Java can call C, so it can't be that hard, can it? Surely no worse than what went into the Cocoa-Python bridge.

Re:To clarify... (3, Insightful)

Feral Bueller (615138) | more than 9 years ago | (#13036433)

This does significantly raise the barrier of entry for hobbyist coders, though. Seems like a typical Apple decision, certainly.

How?

Objective-C is not the traditional point of entry for a hobbyist coder... AppleScript and Perl generally are. If I was going to recommend a programming language for such a person, it would be Java, on the strength of the API documentation alone, but certainly not Objective-C.

Who reads macslash anyway? Their headline for this article is Apple: You Can't Develop In Java Anymore , which besides being inflammatory is incorrect.

Macslash makes PowerPage seem like ArsTechnica.

Re:To clarify... (1)

Otter (3800) | more than 9 years ago | (#13037092)

If I was going to recommend a programming language for such a person, it would be Java, on the strength of the API documentation alone, but certainly not Objective-C.

And therefore eliminating the Java option raises the barrier to entry for Cocoa! We're basically agreeing, so I don't understand what you're objecting to.

Macslash makes PowerPage seem like ArsTechnica.

Well, these days Ars Technica seems a lot like Slashdot [slashdot.org] ...

History reconstructed (maybe) (3, Insightful)

fm6 (162816) | more than 9 years ago | (#13037601)

Good idea? As far as large software makers go, it probably doesn't matter. Adobe's Mac developers have all learned Objective C already.
When I interviewed at Apple in 97, the party line was that Java was going to replace Objective C as the standard language for accessing the NeXTSTEP APIs. But some of the NeXTSTEP people who came over to Apple after the buyout seemed less than convinced.

I haven't had much to to with NeXTSTEP/OS X since then, but your comments make me reconstruct the Java/Cocoa story as follows: after adopting NextSTEP as the basis for OS X, Apple management decides Objective C as a fringe language, and that Java, which was then being hyped as the language of the future, was an easier sell. But, as always, the developer community went with the tools it knew how to use, so Objective C never lost its dominance in OS X development. This latest move is just management bowing to that reality.

Oh Well. (-1, Flamebait)

bleaknik (780571) | more than 9 years ago | (#13035739)

It's Java. Does anyone really care? *ducks*

Re:Oh Well. (1, Funny)

Anonymous Coward | more than 9 years ago | (#13037610)

No,

signed

Everyone

Java scares the crap out of people! (-1, Redundant)

zulux (112259) | more than 9 years ago | (#13035752)


(as I sit here typing this on my iMac 20")

Java scares companies like Microsoft and Apple because it has the potential to make their closed platforms irrelevant. If the promise of Java did take off - people would be free to choose their platform without having to worry about buying all new apps or learning new look-alike apps.

By forcing programmers to use Objective-C - Apple can ensure that those apps are hard to port to any other platform.

That said, the 10.4 API is pretty feature complete, so by not too much harm is done by freezing the Java to OS X API right now.

Re:Java scares the crap out of people! (0)

Anonymous Coward | more than 9 years ago | (#13035792)

I'd say that any app that uses Cocoa, regardless of whether it is written in Obj-C or Java, is pretty hard to port to any other platform.

Re:Java scares the crap out of people! (1)

bwintx (813768) | more than 9 years ago | (#13035907)

(as I sit here typing this on my iMac 20")

Oh, so that's the burning smell I suddenly noticed.

Re:Java scares the crap out of people! (3, Insightful)

thefirelane (586885) | more than 9 years ago | (#13035924)

Note: Java is not being removed from OSX. It is just that you would not be able to access the OSX api from Java... which would mean your applications are not cross platform in the first place. You'll still be free to develope 'pure Java' Applications... so your comment about Apple wanting to kill Java doesn't follow.

Re:Java scares the crap out of people! (1)

Em Adespoton (792954) | more than 9 years ago | (#13036656)

Nothing's being removed, including the ability to compile Cocoa/Java apps. They just won't be adding any new features to the C/J API; even features that are available to C/oC. All this means is that if Apple decides to add a hook for something like kCOM to Cocoa, Java-based apps won't be able to access this information.

Re:Java scares the crap out of people! (3, Insightful)

99BottlesOfBeerInMyF (813746) | more than 9 years ago | (#13035928)

Java scares companies like Microsoft and Apple because it has the potential to make their closed platforms irrelevant.

Ok... now tell me how supporting java applications, including cross platform applications, but dropping cocoa bindings (largely irrelevant or even a hindrance to cross-platform java applications) is indicative of Apple being scared that java will enable people to move away from their platform? They are freezing support for cocoa bindings, not the java API in general.

One of the main reasons I prefer OS X over most other platforms for most tasks is all the added benefits from the OS. The system services that are usable across all applications, for example, like the spell checking in this text field (and all other native text presented by applications and the OS). Cross-platform apps and java apps are weak because they have to reinvent the wheel for everything every time because they can't count on the OS offering all the useful features. It's fine for little games and whatnot, but for the most part, it is just not as good.

Re:Java scares the crap out of people! (2, Insightful)

hunterx11 (778171) | more than 9 years ago | (#13035996)

Cocoa is OS X only. Apple is ending Java support for Cocoa. Java Cocoa applications run only on OS X. Any OS X apps written in Java in the future will now be more likely to be regular, cross-platform Java apps. I wouldn't be surprised if Java Cocoa applications were harder to port to GNUstep than Objective-C applications. How does Apple discontinuing a specific closed platform choice (which was never very popular in the first place) constitute trying to force people to use a closed platform?

Re:Java scares the crap out of people! (4, Funny)

Quarters (18322) | more than 9 years ago | (#13036224)

Java scares companies like Microsoft and Apple because it has the potential to make their closed platforms irrelevant. If the promise of Java did take off - people would be free to choose their platform without having to worry about buying all new apps or learning new look-alike apps.

Did you just get off the boat from 1996 or something?

Re:Java scares the crap out of people! (-1, Offtopic)

zulux (112259) | more than 9 years ago | (#13038413)

(as I sit here typing this on my iMac 20")

Java scares companies like Microsoft and Apple because it has the potential to make their closed platforms irrelevant. If the promise of Java did take off - people would be free to choose their platform without having to worry about buying all new apps or learning new look-alike apps.

By forcing programmers to use Objective-C - Apple can ensure that those apps are hard to port to any other platform.

That said, the 10.4 API is pretty feature complete, so by not too much harm is done by freezing the Java to OS X API right now.

(reposting... got mod bombed, but I have karma to burn)

Re:Java scares the crap out of people! (1)

Quarters (18322) | more than 9 years ago | (#13038448)

No, you didn't get mod bombed, the audience read your comment and rated it accordingly.

Here, I'll repost my response. It's already +5 Funny. Maybe I can double score on it.

Java scares companies like Microsoft and Apple because it has the potential to make their closed platforms irrelevant. If the promise of Java did take off - people would be free to choose their platform without having to worry about buying all new apps or learning new look-alike apps. Did you just get off the boat from 1996 or something?

Re:Java scares the crap out of people! (0)

Anonymous Coward | more than 9 years ago | (#13041179)

Objective-C _is_ portable, you idiot.

Apple has been advising against integration for so (4, Interesting)

Hungus (585181) | more than 9 years ago | (#13035762)

It has been considered best practice by Apple for some time to not use cocoa with java. Typically when someone has done this it has been for the GUI so that native widgets are accessible but with the Aqua widgets being accessible through Swing there is really no need for it now. If the argument is for cross platform writing of Java apps then pure java is always going to be more portable than Java + native elements.

What about SWT? (2, Interesting)

chroot_james (833654) | more than 9 years ago | (#13035920)

I wonder how this effects swt or if swt can provide similar functionality to java-cocoa?

Re:What about SWT? (3, Informative)

Anonymous Coward | more than 9 years ago | (#13036021)

Apple is currently porting SWT to cocoa (SWT is currently based on carbon). I wouldn't be surprised if thats why Apple's doing this. If you want to use native cocoa, SWT is the roadmap.

Re:What about SWT? (1)

chroot_james (833654) | more than 9 years ago | (#13036075)

I guess you and I have basically made the point of the rest of this thread null. *high five*

Ob Homerism (4, Funny)

NiceGeek (126629) | more than 9 years ago | (#13035962)

Mmmmmmmmm...frozen Cocoa Java

Re:Ob Homerism (0, Offtopic)

NiceGeek (126629) | more than 9 years ago | (#13036120)

Excuse me? Redundant? Last I looked no one had made this joke - I know it wasn't the funniest joke out there but mod me fairly at least.

Re:Ob Homerism (1)

tod_miller (792541) | more than 9 years ago | (#13037112)

Mmmmmmmmmm.... Apple

Re:Ob Homerism (1)

Geoffreyerffoeg (729040) | more than 9 years ago | (#13038579)

Mmmm...chocolate frappucino... ...with an apple...?

Its really not a big deal (3, Insightful)

PierceLabs (549351) | more than 9 years ago | (#13036032)

Apple is just telling people to stop using the Java-Cocoa bridge which was actually not useful for building cross platform applications and not used much by the development community anyways.

People wanting this functionality in the future will still be able to do so by just writing a little JNI to handle it - though I'm really not sure its worth the effort.

Sun refusing to license/port Java to Apple+Intel? (0, Redundant)

NZheretic (23872) | more than 9 years ago | (#13036279)

Is Apple having problems with Sun over Apple's transition to the Intel platform?

It might be that Apple on Intel is a little to close to the Sun on Opteron workstation market for Sun's liking.

Re:Sun refusing to license/port Java to Apple+Inte (0)

Anonymous Coward | more than 9 years ago | (#13037198)

oh how i wish i could elaborate, but i fear the power of apple/sun+lawsuits=slashdot giving my IP.

Re:Sun refusing to license/port Java to Apple+Inte (1)

aonaran (15651) | more than 9 years ago | (#13039200)

It might be that Apple on Intel is a little to close to the Sun on Opteron workstation market for Sun's liking

Not likely.
Apple and Sun are really in two very different market segments.

Sun has really cool hardware tricks that make their servers popular. Apple has really cool software tricks that make their Desktops popular.

People are not likely to switch from Apple to Sun or vice-versa in any major numbers. The Apple folks and Sun folks are coming from very different perspectives.

What this is is nothing to do with Sun/Apple relationship. It's just that there are newer, better ways to do this, so Apple is not going to continue to add new features to the old API when they really want developers to move on to the new one.

swt (3, Insightful)

jandockx (561203) | more than 9 years ago | (#13036281)

As long as they would now commit those resources to swt support on Mac OS X, this would actually be a Very Good Thing ...

Transition (1)

ross_winn (610552) | more than 9 years ago | (#13036311)

Apple is managing it's change. They are moving a huge code base, and will have to leave some things by the wayside as they do. This is not to say that there will never new support after the change, but I personally doubt it. My personal opinion? People are going to bitch. No matter what. If they win the lottery they will complain about taxes. It is just there nature, they are resisting change for its own sake.

Where does this leave the NeoOffice/J project? (1)

NZheretic (23872) | more than 9 years ago | (#13036394)

NeoOffice/J [planamesa.com] is the port of OpenOffice.org to MacOSX [openoffice.org] . It does make full use of the Java Cocoa interface.

Re:Where does this leave the NeoOffice/J project? (1)

Brannoch (255008) | more than 9 years ago | (#13037709)

According to the NeoOffice/J docs, it doesn't use Cocoa at all. Instead it uses the Java 1.3.1 Carbon interface. According to them the Java 1.4+ Cocoa code is buggy and doesn't support OS X 10.2; Java 1.5 doesn't support 10.3 either.

Re:Where does this leave the NeoOffice/J project? (3, Informative)

Macrat (638047) | more than 9 years ago | (#13038422)

From the NeoJ Forum [neooffice.org]

The Java that's used within NeoJ is "pure" Java, AWT and Java 2D at present, and perhaps some Swing in the future. Anything that's using OS X specific frameworks is written in either C++ or Obj-C. Since the majority of the application is already C++ based, we just call the frameworks directly. There's no need for us to add an extra layer with the CocoaJava language bridge and never will be.

To put this in perspective: (4, Insightful)

tod_miller (792541) | more than 9 years ago | (#13036502)

If someone writes a widget that places icons in the task tray, that only works on SCHOOMOO operating system, and then writes the Java class and JNI calls for this, but then goes and releases a new version of the widget, but doesn't update the Java classes.

+1 mod points to everyone who spotted this is neither anti-java or anti-Cocoa, in fact, it is pro Java because no Java developer wants to be bogged down with much non-portable code or mac only code.

I would wager than Apple was even nudged by some Java developers who said, yes, this was nice, but look, not much interest in it, we can use our own libraries and keep it cross platform.

This is GOOD for Apple, as this 'embrace the non-proprietary cross platform Java' rather than using Java Cocoa fixated programming, will mean more Java developers will target the Mac. Oooops! But they already do because Java is cross platform. Oh Hahah I am funny.

Now, sometimes you do want to access proprietary extensions, and in yesteryear, the extremely small quirky devices would give some benefits for being able to access their split bars, or their dialogue classes, so each platform had their own set of 'device API's', nothing too wrong with that, but with great power come great erm, device abstraction. Go spidey.

Why did anyone use it in the first place? (1)

idiot900 (166952) | more than 9 years ago | (#13036575)

I don't understand why anyone cares about the end of Cocoa-Java support in the first place. Why was anyone using it in the first place?

Java is a good language but restricting it to Cocoa destroys the cross-platform compatibility, which is pretty much why you'd use Java in the first place. I would understand if Cocoa were garbage and the Java class library was needed as an alternative, or if Objective-C were a complicated language to learn. But Cocoa is a great API and Objective-C is just a small and elegant bag on the side of C.

Re:Why did anyone use it in the first place? (4, Insightful)

TheRaven64 (641858) | more than 9 years ago | (#13036936)

Why was anyone using it in the first place?

I can think of one reason for using it. If you have an existing Java application and want to release if for the Mac, it makes a good choice. If you run a Swing or SWT Java app on OS X without any changes, it will look native, and it will almost feel native, and that almost is enough to really irritate users (including me). Replacing the original GUI with one drawn in IB (so you get the HIG spacing guide lines) and with controllers written in Java as a thin wrapper around the existing model code would be a significant benefit in terms of usability.

Re:Why did anyone use it in the first place? (1)

Pius II. (525191) | more than 9 years ago | (#13040475)

So what?
That's still possible. What's not possible is to use your cross-platform Java code, draw a GUI in IB for it, and then extend it with post-Panther additions to Cocoa in Java. Big deal: if you did, your code would cease to be cross-platform anyway.

Re:Why did anyone use it in the first place? (1)

SteeldrivingJon (842919) | more than 9 years ago | (#13038263)

"I don't understand why anyone cares about the end of Cocoa-Java support in the first place. Why was anyone using it in the first place?"

I've no idea. I think it was created because Apple was concerned that Objective-C would be too alien and would be rejected. So they created Cocoa-Java, sort of a comfy security blanket insulating the programmer from Objective-C.

Around the time of the Apple/NeXT merger, there was even some thought given to redoing Objective-C to have a Java-like syntax. Thankfully, they didn't do that.

One thing that *is* good, is the Objective-C/Java bridge, which lets Objective-C programs use Java library code.

For instance, you could use lucene from within a Cocoa app, and the bridge makes it pretty transparent to instantiate a Java object from ObjC, and use it like you would an Objective-C object.

That would be nice to keep around, as long as they can.

But maintaining Cocoa-Java means they need to create a Java facade for the Objective-C APIs, and they need to create Java equivalents for C constructs and Objective-C Categories which don't quite map cleanly onto Java. That's a fair amount of work.

It doesn't seem like a good use of resources. Cocoa Java has always been a masochistic way to build Cocoa apps.

Re:Why did anyone use it in the first place? (1)

bnenning (58349) | more than 9 years ago | (#13038693)

But maintaining Cocoa-Java means they need to create a Java facade for the Objective-C APIs, and they need to create Java equivalents for C constructs and Objective-C Categories which don't quite map cleanly onto Java.

Exactly. It's much easier for Objective-C to call Java than vice versa because all ObjC method calls are resolved at runtime. (Which allows an ObjC proxy object to take the invocation and transparently forward it to a Java object). Note that more dynamic languages can be better integrated with Cocoa, for example see PyObjC [sourceforge.net] .

Not a big deal (2, Informative)

SteeldrivingJon (842919) | more than 9 years ago | (#13036577)


It really isn't a big deal. Few people use Cocoa-Java to build apps, and it hasn't ever been very well supported or documented.

It doesn't effect cross-platform Java, won't effect WebObjects (which is 100% Java).

Bad for Cocoa-Java... very few give a damn anyway. (3, Insightful)

javaxman (705658) | more than 9 years ago | (#13036689)

If you don't know what Cocoa-Java is, it's a way of gluing a Cocoa native interface onto a Java bytecode program. I suppose the idea is that you have a Java application, for portability, but don't want a Swing UI ? That description is a little simplistic, really, but it's the general concept.

Who writes programs like that ? Very few people, it turns out. I'm sure there are excellent examples of Cocoa-Java programs out there. In fact, I know there are. But really, they are neither highly portable, nor are they fully native code. It's entirely like having a Java program with an ActiveX interface. It's neither native nor cross-platform, it's a mix of technologies, and has the advantages and drawbacks of both, oddly enough.

Apple has, for some time, been moving away from full Cocoa-Java support. If you're shocked by it going away, you haven't been paying attention. If you want a multi-platform Java application, use multi-platform libraries, i.e. Swing. If you want a native application code program, write one- if you don't want use Objective-C because you'd like to port it more easily ( GNUStep aside ) , use C++. But if you want to use Java, well... use Swing. Seriously. It's not as bad as you've been told.

Then again, having native binary projects designed for their respective platforms has it's advantages, too.

Don't get me wrong. I've always thought Cocoa-Java was neat. But mostly in a 'cool trick' sort of way, not in a "I'm going to use this all the time" sort of way. If I want a chunk of code that just runs on any JVM-supported system, I'm not going to use Cocoa-Java, I'm going to use Swing and avoid having more than one build. If I want a native Mac OS X program, Objective-C is easy. Cocoa-Java fit some in-between requirements space that I guess I never really fully understood.

You are completely wrong (1)

Geek Dash Boy (69299) | more than 9 years ago | (#13037592)

If you don't know what Cocoa-Java is, it's a way of gluing a Cocoa native interface onto a Java bytecode program.

no, no, no. Cocoa-Java is a way to write native Mac OS X applications using the Java programming language. The Java platform (i.e. java.lang.*), never enters into it.

Instead of using javax.swing.JFrame, you use com.apple.cocoa.NSWindow (the exact package name escapes me, but you get the idea), and you compile it into native code using Xcode, not bytecode using javac.

Reading articles such as this one [apple.com] should explain further. Excerpt:

"Because Cocoa is an Objective-C framework without automatic garbage collection, however, Java applications sometimes need to take steps to handle peculiarities in this mixed-language environment."

see what I mean? You're using the Java language, which has no free() method, so you have to use weak references or other such idioms to mimic memory management.

Mod the parent down. It's not "Informative", it's "Misleading"

Re:You are completely wrong (4, Informative)

Yaztromo (655250) | more than 9 years ago | (#13038042)

Mod the parent down. It's not "Informative", it's "Misleading"

That's better advice for your response, as opposed to the grandparent post.

The Java platform (i.e. java.lang.*), never enters into it.

That's not true. All of the java.lang.* classes are available. In fact, you can even make calls to javax.swing.* classes (although you have to be really careful in terms of event threads, so it's dangerous to do so). Cocoa-Java still uses java.lang.Class, java.lang.Object, java.lang.String, java.lang.Classloader, and any of the other java.lang classes.

Instead of using javax.swing.JFrame, you use com.apple.cocoa.NSWindow (the exact package name escapes me, but you get the idea), and you compile it into native code using Xcode, not bytecode using javac.

That is also not true. Cocoa Java bundles include the JAR files for their Java components. Only a small stub is compiled natively. Just view the package contents of any Cocoa Java application and you'll find the JAR file. Or build a Cocoa Java application in Xcode, and see something like the following in the build log (with lots of snippage...):

JavaCompile.default Cocoa blah.app
frameworkjars=""
for i in `echo /System/Library/Frameworks/Cocoa.framework/Resourc es/Java/*.jar /System/Library/Frameworks/Cocoa.framework/Resourc es/Java/*.zip ` ; do if [ -f "$i" ] ; then frameworkjars="$frameworkjars":"$i" ; fi ; done
classpath="/blah:"`/usr/bin/javaconfig DefaultClasspath`
/usr/bin/javac -J-Xms64m -J-XX:NewSize=4M -J-Dfile.encoding=UTF8 -g -encoding MACINTOSH -sourcepath ...

Sorry, but you're talking out of your ass, and have no idea what you're talking about.

Yaz.
(Cocoa-Java Developer).

Re:You are completely wrong (2, Insightful)

javaxman (705658) | more than 9 years ago | (#13038470)

The Java platform (i.e. java.lang.*), never enters into it.

Look, I don't want to make you sound silly, Yaztromo already did a fine job of that [slashdot.org] , but when Apple says that the Cocoa-Java NSObject [apple.com] "inherits from Object", exactly what "Object" class do you think they're talking about ?

Hint : it's in the package you don't have to import in the Java language.

Further hint: NSObject [apple.com] in Objective-C ( native Cocoa as opposed to Cocoa-Java, I suppose ) doesn't inherit from anything else, it's a root class.

It's hard to blame you too much for your misconceptions about Cocoa-Java, though, if you're using the Apple "Cocoa Tutorial for Java Programmers" you linked as your guide. I think they're almost intentionally misleading you there... notice there's actually no talk at all of what compiler is being used or what's going on behind the scenes ( it's javac ). Really, Cocoa-Java, IMHO, is there to lure Java programmers into Cocoa. It's a hook to get you to see how easy Objective-C really is...

Basically, there are enough application developers for OS X that Cocoa-Java serves no real purpose now. Just my own little theory, that.

Incompletely wrong... (1)

argent (18001) | more than 9 years ago | (#13038083)

There's quite a few Cocoa Java apps out there, and some seem quite good... but I've found that I'm using very few of them... probably due to the fact that I'm a low-end Mac user [lowendmac.com] . Cocoa already has a fairly significant overhead (presumably due to Aqua rather then Objective C, since NeXTSTeP was quite practical on a 68030). Java just gave it that little extra punch to push it over the top, kind of like turning the lag up to 11.

On faster machines I'm sure it's a lot better, and I would assume that they'd run under native Java on Intel rather than adding Rosetta's overhead to the devilish mix, so I doubt that performance is a direct issue for Apple. But the lack of adoption of Java by users could be.

And of course there's a huge difference between the object models of Java and Objective C. Unlike languages like F-Script, I doubt that it's just a matter of translating the calling mechanism, so I suspect maintaining the interface has been pretty labor-intensive.

As for Swing, what does that do to the native look and feel? What's an example of an application that uses it that I can try on Mac OS X?

Re:Incompletely wrong... (1)

javaxman (705658) | more than 9 years ago | (#13038358)

Cocoa already has a fairly significant overhead (presumably due to Aqua rather then Objective C, since NeXTSTeP was quite practical on a 68030).

You're right there- if you're running on a machine with a non-hardware-acceleration graphics card, you really do need to try the turn-off-the-eye-candy tricks ( disable bouncing dock icons, window and sheet effects, etc ), and if you're on an early G3, ouch. Tiny delays imposed by Objective-C message passing are just that- tiny.

Java just gave it that little extra punch to push it over the top, kind of like turning the lag up to 11.

In fairness, most noticeable Java-related lag is going to be the first time you launch a Java app ( time to launch the JVM and allocate it's memory and threads... ). There might be a few extra instructions involved in packaging bits from the Java side and pushing them into the Cocoa-native UI classes, but it's not that bad there performance-wise.

Sure, for Intel, Java would run on it's own VM, and Cocoa compiled code would still be Intel-specific, so... the more I think about it, the more I think dropping Cocoa-Java has *nothing* to do with moving to Intel. It was in the cards already, since, as you say :

I suspect maintaining the interface has been pretty labor-intensive.

I'm thinking "not terribly labor-intensive for Apple, but how great has the benefit been, when people are already screaming for them to keep up with Sun's Java releases and so few people are really using Cocoa-java ?"

As for Swing, what does that do to the native look and feel? What's an example of an application that uses it that I can try on Mac OS X?

I can say from my own experience, it's pretty good in general. You'd be hard-pressed to notice the UI difference in most Swing programs. Of course, I can't exactly send you my app... but, unless they actually go out of their way to use the Metal Look-and-Feel ( which some apps do, I suppose in the name of avoiding possible look-and-feel bugs, or just out of laziness ), any Java app will start using the native look-and-feel by default. You could always pick up the developer tools install and look at the /Developer/Examples/Java/JFC/SwingSet2/SwingSet2.j ar "SwingSet" demo application, I guess. It runs through a majority of the UI objects.

The weak link, as with any look-and-feel it seems, is of course the file picker ( JFileChooser ). It's not *terrible*, it's just missing the sidebar and search area, really... rather than looking for "OS X Java" applications, just look for Java applications.

There are a few things you can do in Java to make your app look more like a real OS X app, though- use a screen ( instead of window ) menu bar, have Apple UI-compliant menus, support the Application menu commands ( about, preferences, quit )... that takes a small amount of actual code, but there are plenty of apps out there that just don't take that extra step. I did find one, though, after a quick google search. It's a bio-related sequence analysis [informagen.com] program. No idea how it works, but it's an example of what you're asking about.

NeoOffice/J? (0, Redundant)

mindbooger (650932) | more than 9 years ago | (#13036880)

Ouch. I wonder what that means for an OOo 2.0 (and beyond) version of NeoOffice/J?
http://www.neooffice.org/ [neooffice.org]

It means developers will be pissed off (-1)

NekoXP (67564) | more than 9 years ago | (#13037244)


Move to x86 = anger
Lack of Java support = more anger

Are Apple just trying to piss off their loyal developer base? Maybe they are
arrogant enough to think they can replace them with thousands of mindless
VisualBasic migrants and AppleScript/Automator?

Neko

No, actually, it won't bother many developers (1, Insightful)

green pizza (159161) | more than 9 years ago | (#13037475)

Move to x86 = anger
Lack of Java support = more anger
Are Apple just trying to piss off their loyal developer base?

Most developers are happy to see the move to x86 as it will simplify the performance-optimization stage of software development or software porting. But that's another arguement for another time.

This announcement has nothing to do with Java support in general. Apple and Sun are going to continue supporting Java on Mac OS X just as they always have. If you want your Java app to look like a native Mac app, then use SWT, just like you would do to make your java app look like a native Windows app. This hasn't changed one bit.

The announcement refers to using Cocoa (native Mac OS X GUI and API) with Java, rather than Objective-C. Very few people use Java in this way as this JavaCocoa code only runs on the Mac and is not portable. There are many 10 freeware applications written like this, it's more of a technology demonstration than anything else. Because of this, Apple is not going to develop JavaCocoa past 10.4 Tiger. They are not removing anything from 10.4 Tiger, and chances are it will live on in 10.5, albeit a straight copy from 10.4 Tiger.

Intel Java Performance issues? (0, Troll)

linuxtelephony (141049) | more than 9 years ago | (#13037579)

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.

Nope... (1)

SteeldrivingJon (842919) | more than 9 years ago | (#13038222)


It's just because maintaining it is too much work considering how few people use Cocoa-Java.

Java itself will still be available.

Jonathan Schwartz ramblings (4, Funny)

joshstaiger (213677) | more than 9 years ago | (#13037666)

I'm going to go out on a limb an guess that this means that Apple isn't going to take Jonathan Schwartz up on his offer that they adopt Solaris 10 for the underpinnings of the Mac OS and adopt NetBeans as their development environment... [sun.com]

Shocking, I know.

Oye vey...

--
http://joshstaiger.org/ [joshstaiger.org]

Move to OpenStep now ! GNUStep RULES ! (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13037989)

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!

Might mean good things for Cocoa/ObjC in 10.5 (0)

Anonymous Coward | more than 9 years ago | (#13038416)

On the plus side, this hopefully means that there's some really good things coming out for Cocoa/Objective-C which simply aren't able to be duplicated in Java without significant effort or sacrifices in speed. Certainly Java compatibility won't be a potential hinderance anymore.

How about NeoOffice/J ? (1)

constantnormal (512494) | more than 9 years ago | (#13038880)

I thought that NeoOffice/J used Java to integrate with the OS X GUI, providing a Java layer for the OpenOffice innards to paint the screen through.

Or is this announcement something similar to the recent pronouncement that with 10.4, APIs were frozen, so developers would no longer have to target a morphing platform?

I believe that either the same or a similar situation exists with Camino.

Re:How about NeoOffice/J ? (1)

constantnormal (512494) | more than 9 years ago | (#13039109)

Duh-oh!

Camino has nothing to do with Java -- it uses a native Cocoa to wrap the C++ Gecko innards in.

Strange timing... (1)

Anonymous Coward | more than 9 years ago | (#13039264)

... given the ongoing hardware switch - just think about it.

JavaCocoa was _the_ way for a new app to use Cocoa, avoiding the universal binaries - getting and testing on a second platform - thingie.

Of course if you get your app right, universal binaries are OK, and there's no need to test on both plaforms... though if you always got it right the first time, there'd be no point testing at all... :P

Re:Strange timing... (0)

Anonymous Coward | more than 9 years ago | (#13039695)

JavaCocoa was _the_ way for a new app to use Cocoa, avoiding the universal binaries - getting and testing on a second platform - thingie.

Not quite. While the guts of the app are in Java, the stub that makes it run is Objective-C -- meaning you'd still end up compiling Universal Binaries.

Never saw the point (2, Insightful)

Bastian (66383) | more than 9 years ago | (#13039740)

Cocoa-Java apps are _not_ cross-platform. About the only advantages I could see getting from it is not having to make your developers learn Objective-C and being able to work in a garbage-collected environment.

But I don't think either of those advantages are great enough to make it worth Apple's while to spend money on maintaining Cocoa bindings for Java. Objective-C is really not difficult to learn, and has plenty of syntactic sugar to keep you happy - especially if you're using Apple's runtime. And reference counting isn't perfect, but it's also almost brainless to use after a few days of really getting used to it.

Much better in my opinion for Apple to put their Java efforts into trying to keep the JRE on OS X up to date, and possibly to put a bit more effort into getting it to run well.

Third party bridge (4, Informative)

Have Blue (616) | more than 9 years ago | (#13041359)

If there's really demand for Java support of new OS X features, someone else can write a bridge for it- how to do this is well understood. There are already third party Cocoa bridges for Python [sourceforge.net] , Ruby [sourceforge.net] , and Perl [sourceforge.net] .

this is really a shame. (1)

Suppafly (179830) | more than 9 years ago | (#13041448)

This is really a shame, it is cool how fast you can throw together a decent app using java.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?