macOS XCode or the Highway? (a Prediction)

[foidulus]

I'm not sure where you are getting this "voices in the Java community", or if you are working off "gut" feelings. Oracle has publicly stated support for Desktop Java, and made commitments to JavaFX and produced roadmaps for desktop features. And unlike Apple, Oracle does keep its commitment to developers.

I'm guessing you don't have much experience with Oracle, but significant portions of their database is written in Java. Their desktop administration suite is entirely written in Java (so that they don't have to write it natively for every platform). Almost every product that Oracle sells ( WebLogic, PeopleSoft) have significant Java dependencies, if not entirely dependant on Java.

That said, I'm not sure if Oracle would want to produce their own Java runtime for OSX. Apple just isn't a reliable partner. They tend to depreciate APIs whenever it suits them, regardless of past commitments. Anyone remember Apple's commitment to 64-bit Carbon?

You know what? I can still run MFC apps written from '92 on a Windows 7 PC. I can still run Java 1.0 binaries on any certified JVM.

Exactly. I don't think Steve really thinks through the whole "once bitten twice shy" consequences of his actions. He realized they got away with dropping a few things here and there and people still used the platform, but everyone has their line and Steve seems content to just keep on pushing it not realizing that eventually people are going to push back, and hard.

Developers aren't going to continue to support a platform where the whim of one man can render their entire program obsolete. Where I work we have about 200 macs all in total, and we will probably, as much as I hate to say this, go Windows next upgrade round. Apple simply isn't reliable enough.

 

[gnasher729]

Actually, there are some Cocoa specialists out there that speculate Apple will drop it eventually.

Any references? What Cocoa specialists? What time frame for "eventually"? What speculations? What sane reason is given for Apple dropping Cocoa any time in the next twenty years?

Standard C doesn't need to be "translated" in an Obj-C code. Obj-C is a strict superset of C == ANY C Code is valid Obj-C code.
C++ is a bit more complicated but it is mostly superfluous to "translate" it in Obj-C to develop for Apple's platforms. You just need to "bridge" your C++ code with the Cocoa envelope.

There is that other language, Objective-C++. Which is a strict superset to C++ == any C++ code is valid Objective-C++ code.

 

[DavidLeblond]

For all intents and purposes, yes. Much the same as C# can be considered a proprietary language. These languages are not used outside of their, one, original platform.

Say what? C# isn't used outside of Windows? Are you sure about that?

(PS you're wrong. I know a few large companies that use C# on Unix using Mono)

 

[wrldwzrd89]

I really don't like where this is going... Apple's path, not this thread

Being a Java developer, the death of desktop Java isn't such a good thing for me, for obvious reasons - I have plenty of desktop Java-based projects that will now need to find a new home in a different programming language. I'm leaning towards Python as the replacement, but I'm having difficulty porting everything over with the whole Python 2 to 3 transition.

 

[Bernard SG]

I really don't like where this is going... Apple's path, not this thread

Being a Java developer, the death of desktop Java isn't such a good thing for me, for obvious reasons - I have plenty of desktop Java-based projects that will now need to find a new home in a different programming language. I'm leaning towards Python as the replacement, but I'm having difficulty porting everything over with the whole Python 2 to 3 transition.

Again Apple has little influence on the future of Desktop Java. Even assuming that there won't be any JVM available for Mac OS X Lion, Mac users would still have the choice of Bootcamp or Windows Virtualization with Parallels and the like. That's not uncommon in an enterprise context.

Java's problems lie in the Java "Community" itself, and now that includes Oracle, Google with its Dalvik dissidence and all that jazz. That's where you need to be looking at, not Apple's moves that, after all, only concerns a tiny portion of the Desktop universe.

Now, in a purely consumer context, Java has never been a great solution in the first place. Not in Mac, not in Windows. If your target is that market, just forget about Java.

 

[wrldwzrd89]

Again Apple has little influence on the future of Desktop Java. Even assuming that there won't be any JVM available for Mac OS X Lion, Mac users would still have the choice of Bootcamp or Windows Virtualization with Parallels and the like. That's not uncommon in an enterprise context.

Java's problems lie in the Java "Community" itself, and now that includes Oracle, Google with its Dalvik dissidence and all that jazz. That's where you need to be looking at, not Apple's moves that, after all, only concerns a tiny portion of the Desktop universe.

Now, in a purely consumer context, Java has never been a great solution in the first place. Not in Mac, not in Windows. If your target is that market, just forget about Java.

Thanks for your insight. I appreciate it - I have already realized that I need to abandon Java as a deployment solution. Your post just reinforces that feeling.

 

[jnpy!$4g3cwk]

We could develop in Cocoa, but aside from the limitations imposed by the paltry availability of enterprise-level frameworks there, you have the exact same problem. What if Apple decides it's going to drop support for Cocoa? Unlikely but given their past history it wouldn't surprise me.

Drop Cocoa in favor of what? I'm confused by your argument.

 

[Bernard SG]

Drop Cocoa in favor of what? I'm confused by your argument.

Indeed, plus I find it funny that people who are in the software business seem to confuse Cocoa and Objective-C.

 

[mrbash]

Drop Cocoa in favor of what? I'm confused by your argument.

Drop the Cocoa framework in favor of another framework to access the WM and other OS services. Just like Apple dropped the Carbon framework in favor of Cocoa, even after promising to treat it like a 'first class citizen'. Or how about when Apple promised to support 64-bit carbon, only to drop it at the last moment, leaving many developers high and dry after spending a years of development effort.

Indeed, plus I find it funny that people who are in the software business seem to confuse Cocoa and Objective-C.

I think you are the one confused here.

Just Google "Java is dead". +14m hits.
For good measure I tried "Objective-C is dead" for 610,000 results (and not as relevant as those for "Java is dead").

Really? This is your representation of "voices in the Java Community"? I'm guessing you know that those 14M hits come from inside the Java Community? Why don't we keep to facts and not FUD?

 

[foidulus]

Any references? What Cocoa specialists? What time frame for "eventually"? What speculations? What sane reason is given for Apple dropping Cocoa any time in the next twenty years?




There is that other language, Objective-C++. Which is a strict superset to C++ == any C++ code is valid Objective-C++ code.

The reasoning is that Apple has shown 0 issues with dropping other frameworks with very little notice and thus may or may not drop Cocoa. They probably won't but given their past record I have essentially 0 confidence in that and thus I am unwilling to stake my time or money on betting that Apple will continue to support anything they make. They have really shot themselves in the foot by promoting platforms and encouraging developers to use them then dropping them on a whim.

QTJava
64 bit Carbon
Java
64 bit quicktime(QTKit is a joke and Apple hasn't touched that one in about 6 years).
the list goes on.

I am Apple's customer, not the other way around. I should not be forced to constantly retool my applications based on Apple's whim, but that seems to be what Steve expects of his "customers".

I have certainly been an MS basher in the past, but MS at least supports its products and gives plenty of warning AND a clear migration path when they do drop a platform. Apple just seems to say, "sorry, Steve has spoken, all that time and money you invested into our platform? Gone. But please believe us when we say our super duper new platform will never, ever be abandoned, unlike the countless other platforms we have promoted before!"

Also, FYI, Objective-C++ is NOT a strict superset of C++(unlike Objective-C being a strict superset of C)

For instance the keyword "boolean" is used by both, but it is actually a different size in C++ than it is in Obj-C. Your code will compile and then at runtime the difference will reek havoc on your symbol table. I've been burned by this one personally(solution was just to switch to ints and test if they were 0 or 1)

The wikipedia article on Objective-C has more exceptions, but needless to say it's a "mostly" superset of C++.

 

[Krevnik]

The reasoning is that Apple has shown 0 issues with dropping other frameworks with very little notice and thus may or may not drop Cocoa. They probably won't but given their past record I have essentially 0 confidence in that and thus I am unwilling to stake my time or money on betting that Apple will continue to support anything they make. They have really shot themselves in the foot by promoting platforms and encouraging developers to use them then dropping them on a whim.

QTJava
64 bit Carbon
Java
64 bit quicktime(QTKit is a joke and Apple hasn't touched that one in about 6 years).
the list goes on.

Can you really say 64-bit Carbon and Quicktime were pushed for developers to use, considering developers didn't actually get 64-bit Carbon/Quicktime delivered to them? Apple went an about-face on delivering it, sure, but no developers were ever on 64-bit Carbon except maybe Apple themselves. The lack of a complete 64-bit clean API for Quicktime is probably the biggest concern of these two, but considering the rewrite of QT that happened, I'm not entirely sure I can blame them on the order of operations unless QTKit remains stagnant after the rewrite. I'd not want to be transitioning devs to a 64-bit API that I was going to utterly break and destroy with the next QT version.

But you really haven't answered the question: "Replace Cocoa with what?" that others have asked on this thread. Sure, they have no problem dropping platforms they feel are not worth supporting. But would they just shut down all development on their platform? Carbon becoming a dead-end is not the end of their platform since Cocoa was still available. CoreFoundation as a C API still exists and has been ported to 64-bit, which hints more that Carbon was becoming a pain in the ass to port to 64-bit because the code base dated back too far and made bad assumptions.

Maybe I could see AppKit and UIKit merging into some UIKit 2.0 beast that allowed some level of shared code between the platforms, but that's just one part of Cocoa. It's more like saying WPF replaces Windows.Forms in .NET. They'd have to introduce something new and start pushing people to it before they could kill Cocoa, or otherwise their devs really don't have an API to write to anymore and the platform dies.

There's a loss of trust in the platform provider, and then there is diving off the deep end into a pool of paranoia, and assuming that Apple will just drop Cocoa on a whim is the latter. They simply couldn't do it even if they wanted to because they'd really be killing all 3rd party development without a replacement (in the literal sense, not just as hyperbole).

 

[lloyddean]

64-bit Carbon was shown at the Apple Developers Conference under a Non-Disclosure-Agreement that specifically states that anything shown may, or may not, become a released product.

At no time were there any "Promises" made. So would you folks stop repeating this "Promise" crap!

 

[mrbash]

64-bit Carbon was shown at the Apple Developers Conference under a Non-Disclosure-Agreement that specifically states that anything shown may, or may not, become a released product.

At no time were there any "Promises" made. So would you folks stop repeating this "Promise" crap!

That is false.

It was promised for 10.5.0 simply by being available in developer builds. At no time did Apple give any guidance not to use it, in fact Apple produced documentation and support for if. Apple engineers gave guidance and support on developer mailing lists for carbon. Then at the last minute they shipped Leopard without it.

We shouldn't need written guarantees for every little thing from Apple. Particularly something this big.

Additionally, literally millions of dollars of development effort was taking place using the carbon APIs, and Apple knew about it. yet they decided to say "forget you, I'll do whatever I want".

 

[lloyddean]

That is false.

It was promised for 10.5.0 simply by being available in developer builds. At no time did Apple give any guidance not to use it, in fact Apple produced documentation and support for if. Apple engineers gave guidance and support on developer mailing lists for carbon. Then at the last minute they shipped Leopard without it.

We shouldn't need written guarantees for every little thing from Apple. Particularly something this big.

Additionally, literally millions of dollars of development effort was taking place using the carbon APIs, and Apple knew about it. yet they decided to say "forget you, I'll do whatever I want".

And again developer builds are under non disclosure as well!