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!
    >> 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.
    >
    Good thing Objective-C isn't a complex language, then.  Ask anyone who
    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 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++.

    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.
previous month april 2001 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            
Go to today