java or objective c?

Dogcow

Registered
As a junior in CSC who has used java extensively during my education, I'm very well-versed in it and very comfortable with it. However, I've been encouraged by many to not use java with cocoa and instead use objective c. I am NOT going to use the java.swing libraries as they are extremely slow, but I was planning to use java to write the code, and then link that code with the cocoa elements. Is objective c really a better language to use with OS X? I've worked with dozens of languages and java has by far the best debugger, not even mentioning its excellent implementation of objects.

So I guess I have lots of questions about objective c. Why would one use it instead of java? What are the advantages? Do any of you have a lot of experience with both? If so, which do you prefer? And how does objective c handle objects? Very intelligently or does it do it the pathetic way that c++ does?

I really appreciate any advice you can give- I don't want to devote time to learn objective c if java would be a better choice.

-Dogcow "moof!"
Visit The Underground
 
I'm not familiar with Objective C, but one thing that I suspect is an advantage is compilation versus interpretation. Java is an interpreted language, as I'm sure you're aware, and I think (don't quote me on this) that ObjC is compiled, which would be a huge speed gain.

But once again I'm speculating wildly, so someone else can feel free to step in and call me silly. :)
 
Originally posted by nkuvu
I'm not familiar with Objective C, but one thing that I suspect is an advantage is compilation versus interpretation. Java is an interpreted language, as I'm sure you're aware, and I think (don't quote me on this) that ObjC is compiled, which would be a huge speed gain.

But once again I'm speculating wildly, so someone else can feel free to step in and call me silly. :)

You're right on this one. This alone makes me lean towards objective c. I'm hoping it's partially as intelligent of a language as java is though, as java is a joy to work with. Thanks.

-Dogcow "moof!"
Visit The Underground
 
I may be wrong here, but...

It is my understanding that, while what most people think of as "java" is an interpreted language ("cross platform" and run in a VM). java can also be compiled, yielding machine code like any other compiled program. The real question is whether the cocoa java-wrappers are feature complete and if the compiler can optimize worth a damn. I don't know the answer to either question, but the issue is not having the overhead of a VM, because you won't.

I'm sure someone will give me a good swat if I'm wrong....

-alex.
 
I think there are programs that compile java to a C stack, but they cost money. I developerd using Cocoa-Java for over a year, and was very happy to move to Cocoa-Objc. Here's why.

1) SPEED.
2) Better documentation and implementation. Some whole classes and many methods don't cross over the bridge from ObjC to Java, which can make things difficult
3) The bridge is a little buggy. I've gotten weird crashes and fileld several bug reports. Anything the requires efficiency (like dragging a window via it's content view) really ****s on the Java side of the bridge.
4) I personally think that my code written in ObjC ends up being more readable and an overall better implementation of OO principles. It may just be me, though.
5) There's a lot more support and help online in ObjC (although it's not that difficult to translate between the two)
6) The OmniFrameworks aren't bridged, so to take advantage of them, you woul dhave to have some objc code in your app (although you could actually mix ObjC and Java in the same app, it's pretty cool)

I actualyl think starting off using Cocoa-Java would be good for just learnign the API's, but to really get into programming for OS X, you need to use ObjC.

JMO
F-bacher
 
Originally posted by Ghoser777
I think there are programs that compile java to a C stack, but they cost money. I developerd using Cocoa-Java for over a year, and was very happy to move to Cocoa-Objc. Here's why.

1) SPEED.
2) Better documentation and implementation. Some whole classes and many methods don't cross over the bridge from ObjC to Java, which can make things difficult
3) The bridge is a little buggy. I've gotten weird crashes and fileld several bug reports. Anything the requires efficiency (like dragging a window via it's content view) really ****s on the Java side of the bridge.
4) I personally think that my code written in ObjC ends up being more readable and an overall better implementation of OO principles. It may just be me, though.
5) There's a lot more support and help online in ObjC (although it's not that difficult to translate between the two)
6) The OmniFrameworks aren't bridged, so to take advantage of them, you woul dhave to have some objc code in your app (although you could actually mix ObjC and Java in the same app, it's pretty cool)

I actualyl think starting off using Cocoa-Java would be good for just learnign the API's, but to really get into programming for OS X, you need to use ObjC.

JMO
F-bacher

Thanks man, I really appreciate the reply. I especially appreciate the length and the fact that you were in a similar position to me... I have a great book to learn cocoa and obj c (Cocoa Programming for Mac OS X) so I think I may be fine to start with obj c. Thanks again!

-Dogcow "moof!"
Visit The Underground
 
some clarification of speculations above:


1) cocoa/java is not natively compiled.
2) GCC, the compiler that apples ships with the developer tools is completely free and has an extension for compiling java into native machine code called GCJ, see gcc.gnu.org/java. dunno how swing would react to being natively compiled... there are too many issues here... don't think it's possible to actually compile java natively if one does not create a new java-class-library, the sun-ditto is probably not an option.


another thing I wanted to say is that SPEED IS NOT AN ISSUE. if it was, we would all be trying to hack PPC-assembler, which is an almost impossible thing to do if my SE/CS-teachers are to be belived...

so, sure you could switch to objc, that's what I did, but not for speed, but because I think it good knowing a new way of doing things. java is not slow (although it's not good for everything, graphics ARE slow, but the shouldn't have to be, but that's another story), there is probably no difference whatsoever in a gui-app. as long as we're not talking mathematical calculations (of which graphics are a part), java is as fast as anything. faster than perl or python (which are interpreted) and almost as fast as objc. the thing is that the user will not know the difference.

the microsoft .NET platform is based on semi-compiled code, much like java. that's because speed is no longer an issue. the compilers are so good and the processors are so fast that we no longer can make things go faster, since there are so many bottlenecks... just think about the user! he/she is the slowest component in the system... so it doesn't matter that it takes 5 or 10 milliseconds to show the window, the user can't react anyway.

as I have said (too many times I think) this does not apply to maths or grapics, however. but for the rest SPEED IS NOT AN ISSUE (a thing that I can say many more times...)


your-daily-rant-by
theo
 
I disagree. You can say that speed is not an issue because the computer is so fast that it doesn't matter, but I feel that a fast program is going to be better received than a slow one.

Let's take everyone's favorite OS, for example. OS X was not written in Java, to the best of my knowledge. Actually, now that I think about it, I have no idea what OS X was written in. But it's slow. Don't get me wrong, I love it, and have no problems with it being slow. But compare it to a Unix system with a window manager, and you'll see what I mean. Especially when you can get a Unix system to perform as well or better than OS X and the Unix system is running on a 300 MHz processor and the OS X system is running at 800 MHz.

If you're taking SE/CS classes, iconara, you probably know about advanced data structures such as trees and stacks and hashes. Why use those? They're complicated, difficult to debug, and difficult to use in relation to simple one-dimensional arrays. Speed is the answer. A search through a large array will take a lot longer than a search through a large hash.

So when you say speed is not an issue I have to disagree. It is a very big issue, one that a lot of people spend a lot of time trying to improve. We don't hack at assembly because the compilers for C/C++ do that for us, and probably do a better job.

There may not be a large difference in execution times once the program is loaded and running, but that loading takes time. Java is a unique language, in that it's partially compiled before running, which makes it faster than Perl or Python. But it's still not as fast as pure C/C++, which is why the majority of software companies on the market still use C/C++ as their primary programming language.

Anyway. Not trying to start a flame war or anything, just had to put in my two cents.
 
Hold on a second. Does UBB not like S-U-C-K? I think that's what I typed initially, I think.

Now, about speed. How could you possibly say that speed is not an issue? There are levels at which speed is not an issue. I even think that using an object oriented model is going to be slower than otherwise, but it's more readable, and the speed difference isn't that huge on machines now a day. If all you're doing is some simple interface stuff, then speed doesn't matter that much. BUT, there is a noticeable difference because all java calls have to go through a wrapper layer (try doing a borderless window in Java and one in ObjC and notice the difference in dragging from an NSView subclass).

There are people who still do all their coding in assembly, as small projects done in assmebly can be done faster than writing code to be compiled, but it can be more tedious and extremely difficult to maintain a large assembly code project.

So, yes, use the language you want to use, but Obj-C will run faster than Java. Half the point of java is its portability (compile once, run anywhere), which is pretty much lost when using it in a Cocoa project. Then there's garbage collection, but I enjoy being able to allocate and deallocate memory when I want.

F-bacher
 
Back
Top