Should i use Java instead of Obj C?
-
Java feels more comfortable for me, but i was wondering, would Java be any
slower than Obj C? Every Java app i've run always seems so slow, but Java
Cocoa apps are native, so they should be just as fast right?
Also, it seems like Obj C is Apple's "preferred" languauge now, does that
mean that i would be limiting myself by using Java, i.e. most people are
probably writing Obj C classes and stuff so that i would be left out in the
cold? Or is there some sort of Obj C <-> Java conversion utility or can they
be used together in the same project, or...? -
At 9:57 AM -0400 4/8/01, Joel R. wrote:
> Java feels more comfortable for me, but i was wondering, would Java be any
> slower than Obj C? Every Java app i've run always seems so slow, but Java
> Cocoa apps are native, so they should be just as fast right?
Your own program will not be native, it will still be executed by the
java-vm but for many kind of applications, this is sufficient.
Cocoa and, I guess, the bit of common ObjC and Java have, allow the
whole scheduling of GUIs in a good way...
> Also, it seems like Obj C is Apple's "preferred" languauge now, does that
> mean that i would be limiting myself by using Java, i.e. most people are
> probably writing Obj C classes and stuff so that i would be left out in the
> cold? Or is there some sort of Obj C <-> Java conversion utility or can they
> be used together in the same project, or...?
Oh I would dream about such a thing !
And the other dream would be to convert the entire swing to ObjC....
crazily quick suddenly... or maybe I'm dreaming....
Paul
-- -
Learn ObjC and experience the freedom!
For a Cocoa app, there really isn't a choice -- at least if you want people to
use your app.
I, for one, will not be using an Java apps unless I really have to and there
is no other choice.
http://www.bignerdranch.com/Java.html
nuff said
./aj
> Java feels more comfortable for me, but i was wondering, would Java be any
> slower than Obj C? Every Java app i've run always seems so slow, but Java
> Cocoa apps are native, so they should be just as fast right?
>
> Also, it seems like Obj C is Apple's "preferred" languauge now, does that
> mean that i would be limiting myself by using Java, i.e. most people are
> probably writing Obj C classes and stuff so that i would be left out in the
> cold? Or is there some sort of Obj C <-> Java conversion utility or can they
> be used together in the same project, or...?
>
-
Java is more portable than Objc / Cocoa. Java is more widely implemented,
and Cocoa is tied to MacOS X. Java class libraries are cross platform. I
was writing a frontend to Unix fortune for MacOS X / Cocoa and Unix /
Linux / KDE with common code in a Java class and the fortune program
itself. This would not be possible in ObjC. With another frontend using
only Swing / AWt it would run on any java platform.
Apples documentation for Java is bad, where it isn't absent. Wait for an
OReilly Book on Cocoa, and hope it has Java coverage. The CtoF tutorial is
OK as far as it goes, which is v.little. The java browser is not good
enough, and a Javadoc html output would have been nice too.
Code reuse - how much ObjC code is out there vs Java? Java has extensive
clas libraries. Both ObjC and Java can access libraries etc written in C/C+
+, in javas case using JNI.
There is quite some bias towards Java in favor of ObjC by MacosX
developers, the ex NeXT community etc. This does limit your help. Also,
cocoa is primarily documented for use with ObjC.
Use jikes for a faster Java compiler. Use cli javac for better error
messages than through ProjectBuilder. Execution time - wait for GCC to
support Java via libgcj. Since the cc in MacosX is gcc, this should come
free with time.
Java vs ObjC, the languages. Java is currently far better suited to
beginner programmers (me ;-) by strict typing, simplicity, lack of pointer
problems / array scribblings, clean up of C's many problems, garbage
collection, many class libraries / data collections, and widespread use in
Academia resulting in many books about everything you could want to do in
Java.
Thats my mix of opinion and fact, anyway.
George Russell -
That's all in all not true. Java apps developed for Cocoa can be pretty fast.
Paul
At 11:36 AM -0400 4/8/01, Alykhan Jetha wrote:
> Learn ObjC and experience the freedom!
> For a Cocoa app, there really isn't a choice -- at least if you want
> people to
> use your app.
>
> I, for one, will not be using an Java apps unless I really have to and there
> is no other choice.
>
> http://www.bignerdranch.com/Java.html
>
> nuff said
>
> ./aj
-- -
The question wasn't about which language is better or more portable. The
question was whether to use Java or ObjC in a ****COCOA**** app.
If you code in Java using the cocoa api's your code ISN'T portable!!
If you want to use Java, write a PURE Java app, not a bridged one. A pure Java
app will have the benefits George mentions below.
Remember, cocoa apps written in Java are not pure Java apps, they are hybrid
Java/Obj-C apps -- even if all the code you write is 100% pure java.
The bottom line: Either write pure Java apps or pure ObjC apps! Writing a
bridged app is the dumbest thing you could do (no offence to anyone) -- it's
worst of both worlds.
Also, no offence to anyone who coded the bridge because it IS a technical marvel!!!
./aj
P.S. if there a Obj-C or Carbon app that does the same thing as a Java app --
Guess what, the Java app ain't gonna even make it to my computer -- I just
don't have the patience or time.
> Java is more portable than Objc / Cocoa. Java is more widely implemented,
> and Cocoa is tied to MacOS X. Java class libraries are cross platform. I
> was writing a frontend to Unix fortune for MacOS X / Cocoa and Unix /
> Linux / KDE with common code in a Java class and the fortune program
> itself. This would not be possible in ObjC. With another frontend using
> only Swing / AWt it would run on any java platform.
>
> Apples documentation for Java is bad, where it isn't absent. Wait for an
> OReilly Book on Cocoa, and hope it has Java coverage. The CtoF tutorial is
> OK as far as it goes, which is v.little. The java browser is not good
> enough, and a Javadoc html output would have been nice too.
>
> Code reuse - how much ObjC code is out there vs Java? Java has extensive
> clas libraries. Both ObjC and Java can access libraries etc written in C/C+
> +, in javas case using JNI.
>
> There is quite some bias towards Java in favor of ObjC by MacosX
> developers, the ex NeXT community etc. This does limit your help. Also,
> cocoa is primarily documented for use with ObjC.
>
> Use jikes for a faster Java compiler. Use cli javac for better error
> messages than through ProjectBuilder. Execution time - wait for GCC to
> support Java via libgcj. Since the cc in MacosX is gcc, this should come
> free with time.
>
> Java vs ObjC, the languages. Java is currently far better suited to
> beginner programmers (me ;-) by strict typing, simplicity, lack of pointer
> problems / array scribblings, clean up of C's many problems, garbage
> collection, many class libraries / data collections, and widespread use in
> Academia resulting in many books about everything you could want to do in
> Java.
>
> Thats my mix of opinion and fact, anyway.
>
-
On Sunday, April 8, 2001, at 09:52 AM, Paul Libbrecht wrote:
> That's all in all not true. Java apps developed for Cocoa can be pretty
> fast.
Can you provide an example of a "pretty fast" Java/Cocoa app?
-jcr -
Show me one!
Are you sure you aren't talking about Objc-Cocoa apps?? (there seems to be
some confusion about Java-Cocoa apps and Pure ObjC-Cocoa).
./aj
> That's all in all not true. Java apps developed for Cocoa can be pretty fast.
>
> Paul
>
> At 11:36 AM -0400 4/8/01, Alykhan Jetha wrote:
>> Learn ObjC and experience the freedom!
>> For a Cocoa app, there really isn't a choice -- at least if you want
>> people to
>> use your app.
>>
>> I, for one, will not be using an Java apps unless I really have to and there
>> is no other choice.
>>
>> http://www.bignerdranch.com/Java.html
>>
>> nuff said
>>
>> ./aj
>
-
At 2:17 PM -0400 4/8/01, Alykhan Jetha wrote:
> Show me one!
>
> Are you sure you aren't talking about Objc-Cocoa apps?? (there seems to be
> some confusion about Java-Cocoa apps and Pure ObjC-Cocoa).
At 11:05 AM -0700 4/8/01, John C. Randolph wrote:
> Can you provide an example of a "pretty fast" Java/Cocoa app?
>
> -jcr
In public-beta, there was Sketch.app which was running pretty
smoothly but since then, I have to agree I don't see any-more...
pretty much of a shame.
Anyways. I do believe that the Cocoa library allows a much better
thread control which makes it way more handlable and allows
applications that do not need to make a lot of computations (or
networking) to run pretty well. I'll make mine one day... but that
could be in six months.
Paul
-- -
[snip]
> In public-beta, there was Sketch.app which was running pretty smoothly
> but since then, I have to agree I don't see any-more... pretty much of
> a shame.
>
> Anyways. I do believe that the Cocoa library allows a much better
> thread control which makes it way more handlable and allows
> applications that do not need to make a lot of computations (or
> networking) to run pretty well. I'll make mine one day... but that
> could be in six months.
>
> Paul
I am writing a networking app in Java with a Cocoa front end. Run pretty
well. I get transfer speed of 1Mb/sec. I have tested it with NFS, FTP
etc. I got exactly the same. So I think speed isn't a issue for Java
anymore (not since hotspot jvm's). If all goes well I will be releasing
the app in 2 weeks so then you can see it for yourself.
Bernard van Gastel
- - - - -
A woman is asked why she cuts the ends off a ham before baking it. She
explains that her mom alway did so. Her mom explains that she learned it
from grandma. And grandma says, "Silly, my pan was too short for the
entire ham."
- - - - -
"When I was 16, I though my father was the most ignorant ass that there
ever was. But by the time I was 21, I was surprised to discover just
how much he had learned in only 5 years."
-Mark Twain -
> Learn ObjC and experience the freedom!
> For a Cocoa app, there really isn't a choice -- at least if you want people to
> use your app.
The shortcomings with using Java rather than Obj-C for Cocoa apps has
deeper implications for the long term future of Mac OS X. Developers
are going to be loathe to learn a complex new language and framework
that only exists on one (minority) platform, no matter how insanely
great the RAD environment is.
If the developer can leverage his/her prior knowledge and experience
of, say, Java then the barrier drops to a lower position. At least
then the "guts" of an app can be made portable across platforms, even
if the GUI has to be rewired elsewhere, and there isn't a new
language to assimilate.
I am personally having major startup problems on Mac OS X: I can see
that Cocoa is insanely great, but I really, really don't want to
learn a type-unsafe C-based language, even if it's less of a pain
than C++.
If Apple could make Cocoa/Java a first class citizen, I'd be the
first to sign up. Mind you, if Borland could get Kylix running on Mac
OS X then I will have died and gone to heaven.
Paul Rodman -
On Sunday, April 8, 2001, at 02:17 PM, Paul Rodman wrote:
>> Learn ObjC and experience the freedom!Good thing Objective-C isn't a complex language, then. Ask anyone who
>> For a Cocoa app, there really isn't a choice -- at least if you want
>> people to
>> use your app.
>
> The shortcomings with using Java rather than Obj-C for Cocoa apps has
> deeper implications for the long term future of Mac OS X. Developers
> are going to be loathe to learn a complex new language and framework
> that only exists on one (minority) platform, no matter how insanely
> great the RAD environment is.
>
took a day and learned it.
-jcr -
On dimanche, avril 8, 2001, at 11:17 , Paul Rodman wrote:
>
> I am personally having major startup problems on Mac OS X: I can see
> that Cocoa is insanely great, but I really, really don't want to learn
> a type-unsafe C-based language, even if it's less of a pain than C++.
It would be better to be more open minded than that. The more you learn
the better is.
And one thing that people don't understand, to build robust you need
abstraction, encapsulation and information hidden, static typing is not
so useful, it forces you to write complicated stuff like templates and
RTTI and the things you get on one side you lost them on the other side
at the power 10.
Look at Mail.app, IB, PB, Omniweb... Look also at the Omnigroup
frameworks.
Sincerely.
--
<gerard_iglesias...>
Ph.D. in Computer Graphics MacOS X-Cocoa to have fun
Project manager at www.visiotics.com Win32/MFC to eat -
On Sunday, April 8, 2001, at 02:17 PM, Paul Rodman wrote:
> I am personally having major startup problems on Mac OS X: I can seethat Cocoa is insanely >great, but I really, really don't want to learn
a type-unsafe C-based language, even if it's >less of a pain than C++.
Well, to some extent, Objective-C is still reasonably type safe, and
IMHO moreso than C++ in some cases.
As long as you are using statically typed object pointers, the compiler
will do method type checking for you, and warn you when it doesn't think
the object you are sending a message to responds to that method. It
will also check pointer assignments as best it can. For example, it
will let you assign an NSView * to an NSResponder *, but not
vice-versa. In those cases you must do an explicit cast.
Obviously, if you use 'id', the compiler is unable to do as much
checking, but from a coding style standpoint I try to avoid using 'id'
except in those cases where I really won't know the type of object I'm
dealing with, which is fortunately fairly rare.
As far as C++ goes, I don't think it's static type checking is all it's
cracked up to be. For example, you can do something like this:
class A
{
public:
void foo();
};
class B : public A
{
public:
void foo();
};
void goofytest()
{
A *a;
B *b;
b = new B();
a = b; // No error generated!
a->foo(); // Calls A::foo() on a B object.
}
IMHO, C++ ought to issue a warning if you assign a derived class pointer
to a base class pointer and there are any non-virtual members present.
Otherwise C++ will happily just call the wrong code. Of course, any
C++ programmer will tell you that "Well, you screwed up by not using
virtual". Well if it's such an obvious programming error, why allow
non-virtual members in the first place? (As a side note, inline member
functions have the same "defect".)
In Objective-C, you can use any kind of pointer you want, and no matter
what you do (short of going behind the runtime's back), the right code
is always going to be executed.
The other really annoying situation I ran into a few days ago was that
C++ method/function overloading actually caused a bug, with no warnings
generated at all.
Up in the kernel we have a virtual member callback function on
IOAccelerator devices so they can get notified when the display mode is
about to be changed. The original version looked, something like this:
virtual void display_mode_will_change();
However, this was changed in the base class to this:
virtual void display_mode_will_change(UInt32 event);
Now, because I also had the original version re-declared in the GeForce3
driver header file, and the IOAccelerator base class defined a default
implementation of the new method, my version of the method didn't get
called, and yet there were no warnings generated anywhere. The compiler
quite happily decided that we really *did* want two different methods
with the same name but different arguments (even a different number of
arguments).
Eventually we figured out what was going on, and decided to change the
base class version to an abstract virtual, so that if it wasn't
implemented in a derived class we'd get a failure when someone actually
tried to instantiate an instance of the derived class. We also made
sure to never re-declare virtual methods in derived classes, which also
would have caught the error.
So, as with any OO language, somewhere along the line you're going to
get bitten by one thing or another. I happen to like the fact that with
Objective-C, there seems to be a lot fewer things that can mysteriously
go wrong.
-Ken -
At 2:35 PM -0700 4/8/01, John C. Randolph wrote:
> Good thing Objective-C isn't a complex language, then. Ask anyone who took a day and learned it.
I agree 100%. It took me a single day to learn ObjC, it's an elegant language.
I know Java as well, and the Objective-C Cocoa source code is a lot easier to understand. Cocoa and Objective-C fit each other like a glove. -
At 12:08 AM -0700 4/9/01, strobe anarkhos wrote:
> At 2:35 PM -0700 4/8/01, John C. Randolph wrote:
>> Good thing Objective-C isn't a complex language, then. Ask anyone who took a day and learned it.
>
>
> I agree 100%. It took me a single day to learn ObjC, it's an elegant language.
I would like to know what resources you used to learn ObjC. Would you share them with the list, please ?
Thanks.
--
------------------------------------------------------------------------
Dan White
------------------------------------------------------------------------
"Sometimes I think the surest sign that intelligent life exists
elsewhere in the universe is that none of it has tried to contact us."
Calvin (Bill Waterson) -
At 00:08 -0700 4/9/01, strobe anarkhos wrote:
> At 2:35 PM -0700 4/8/01, John C. Randolph wrote:
>> Good thing Objective-C isn't a complex language, then. Ask anyone
>> who took a day and learned it.
>
>
> I agree 100%. It took me a single day to learn ObjC, it's an elegant language.
>
> I know Java as well, and the Objective-C Cocoa source code is a lot
> easier to understand. Cocoa and Objective-C fit each other like a
> glove.
I have no doubt that Objective-C is an insanely great language, but
for me personally it is a problem since:
a. I don't use C/C++ and have never used them in my 29 years of
programming because creating code is just too difficult with weakly
typed languages. Java, Object Pascal, etc. are much more appealing to
my tidy mind I guess...I I "did" C or C++ then Obj-C would not be a
problem.
b. Most of my time is spent developing software for the dark side,
and I just don't have the time/energy to assimilate another
single-platform proprietary language. Delphi and Java are second
nature to me.
c. My existing Mac app (started in 1985 in Object Pascal) is not
working on Mac OS X under Classic and needs redeveloping (from
scratch) in a hurry and I was hoping to keep my learning curve
shallow.
d. Using Java would also help leverage the code onto "other"
platforms at a later stage (probably not the GUI, but perhaps most of
the "guts").
Thanks for your comments.
Paul Rodman -
On Mon, 9 Apr 2001, Daniel E. White wrote:
>
> I would like to know what resources you used to learn ObjC. Would you
> share them with the list, please ?
>
Object-Oriented Programming and the Objective-C Language
http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/index.html
is excellent. I recommend it to anyone who wants to do OO because it's
nice even ignoring objective-c.
http://www.cetus-links.org/oo_objective_c.html
is a good jumping-off point.
for source examples check out gnustep
http://www.gnustep.org/
they've implemented much of foundation and appkit, as well as an old
(1.0-style) version of EOF.
If you want to know more about Objective-C from one who believes
<understatement>Objective-C and Apple are _not_
synonymous</understatement> you want to read up on what David Stes has to
say (beware of falling Blocks)
http://users.pandora.be/stes/compiler.html
That should keep you busy reading for a while ;)
--
Ian P. Cardenas
Computer Scientist, Software -
On Monday, April 9, 2001, at 07:18 AM, Daniel E. White wrote:
>> At 2:35 PM -0700 4/8/01, John C. Randolph wrote:
>>> Good thing Objective-C isn't a complex language, then. Ask anyone
>>> who took a day and learned it.
>>
>>
>> I agree 100%. It took me a single day to learn ObjC, it's an elegant
>> language.
>
> I would like to know what resources you used to learn ObjC. Would you
> share them with the list, please ?
Apple's own books, "Object-Oriented Programming and the Objective-C
Language" as well as "Objective-C Tutorial" are quite good. I read the
first one back in 1990, and it did the trick back then, and it's even
been improved over the years.
You can find both of these at Apple's web site:
http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/ObjC.pdf
and
http://developer.apple.com/techpubs/macosx/Cocoa/ObjCTutorial/CurrencyConve
rterTutorial.
pdf
Alex Raftis
---
<alex...> -
At 10:18 AM -0400 4/9/01, Daniel E. White wrote:
> At 12:08 AM -0700 4/9/01, strobe anarkhos wrote:
>> At 2:35 PM -0700 4/8/01, John C. Randolph wrote:
>>> Good thing Objective-C isn't a complex language, then. Ask anyone who took a day and learned it.
>>
>>
>> I agree 100%. It took me a single day to learn ObjC, it's an elegant language.
>
> I would like to know what resources you used to learn ObjC. Would you share them with the list, please ?
http://developer.apple.com/techpubs/macosx/Cocoa/CocoaTopics.html
Look under "Getting Started" -
>
> c. My existing Mac app (started in 1985 in Object Pascal) is not working on Mac OS X under Classic and needs redeveloping (from scratch) in a hurry and I was hoping to keep my learning curve shallow.
Why not just continue using Pascal then?
Metrowerks has committed to porting their Pascal compile to make Cabon apps. Also you can do that already with their existing compiler using instructions from pascal-central.com
Another possibility is porting freepascal compiler, or trying to get the gcc pascal front-end working. -
> Why not just continue using Pascal then?
Anybody else find the concept of an Object Pascal Cocoa bridge
interesting?
I don't know enough about Object Pascal to know if it would be more or
less feasible than a C++ one, but I still think it would be cool :)
I keep getting told that "real" programmers use Pascal, so... :)
(still, I call myself a developer, so who cares? :)
-- Rob
This has been a recording. -
At 4:30 AM -0400 4/10/01, Rob Rix wrote:
>> Why not just continue using Pascal then?
>
> Anybody else find the concept of an Object Pascal Cocoa bridge interesting?
Only if CoreFoundation is expanded to include all of Cocoa which isn't going to happen this century.
I was referring to using Carbon with Pascal which people have already done. -
At 01:21 -0700 4/10/01, strobe anarkhos wrote:
>>
>> c. My existing Mac app (started in 1985 in Object Pascal) is not
>> working on Mac OS X under Classic and needs redeveloping (from
>> scratch) in a hurry and I was hoping to keep my learning curve
>> shallow.
>
> Why not just continue using Pascal then?
>
> Metrowerks has committed to porting their Pascal compile to make
> Cabon apps. Also you can do that already with their existing
> compiler using instructions from pascal-central.com
I'll believe that when I see it...
Metrowerks has also categorically stated that it will be the end of
the line for Pascal.
Anyway my Pascal code is so intensely bad that I'm also looking for
an excuse to start from scratch :^) Carbonising the existing code
would probably be way too expensive and time-consuming.
That being said, I did look into this possibility for a while.
--
Paul Rodman -
On Monday, April 9, 2001, at 12:09 PM, Alex Raftis wrote:
> Apple's own books, "Object-Oriented Programming and the Objective-C
> Language" as well as "Objective-C Tutorial" are quite good. I read the
> first one back in 1990, and it did the trick back then, and it's even
> been improved over the years.
I haven't finished it yet, but I agree that the former book is a pretty
good beginner's guide.
My gripe with it is that it seems (to my still underinformed eye) to
really muddle the distinction between the Obj-C language and the
NeXT/Apple implementation. I'm sure the grammar will help when I get to
that, but so far it's really an annoyance that the two seem to be treated
interchangeably.
Steve -
On Sunday, April 8, 2001, at 05:17 PM, Paul Rodman wrote:
>> Learn ObjC and experience the freedom!
>> For a Cocoa app, there really isn't a choice -- at least if you want
>> people to
>> use your app.
>
> The shortcomings with using Java rather than Obj-C for Cocoa apps has
> deeper implications for the long term future of Mac OS X. Developers
> are going to be loathe to learn a complex new language and framework
> that only exists on one (minority) platform, no matter how insanely
> great the RAD environment is.
The developers that will create the next generation of great apps are
not the sort of developers that will quail at learning a new language.
