• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Disadvantages of Bridging Java in Objective-C Cocoa Apps
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Disadvantages of Bridging Java in Objective-C Cocoa Apps


  • Subject: Re: Disadvantages of Bridging Java in Objective-C Cocoa Apps
  • From: Don Yacktman <email@hidden>
  • Date: Tue, 4 Feb 2003 22:46:00 -0700

On Tuesday, February 4, 2003, at 03:20 PM, Eric Czarny wrote:
On Tuesday, February 4, 2003, at 04:41 PM, June Van Dyke wrote:
Well, loading Java is slooooooow. Look at LimeWire. Granted, since most of
your app would be Obj-C, you'd get OK speed once running, but it will take
anywhere from three to ten seconds to load Java (and thus your app).

Unless you have a very good reason, I'd suggest you don't use Java, for the
end-user's sake (and to reduce debugging times :p).

Thanks for the advice! I would like to find another way in which to use XML-RPC in my application;

While loading Java is slow, there is one other way you can use Java with Cocoa and not impact launch time. (You still have to pay the JVM startup time penalty at some point, though.) The idea is to put all the code that interfaces with Java classes into a bundle. Then, while the app is running, you load the bundle. The JVM won't start at app launch. Instead, it will start if and when the bundle is loaded. This works well if only a part of the app uses Java and if the user won't always run that part of the app when they run the app. (I realize that this might not work well for your app, but someone else might find it handy.)

For an example of this, look at the games from illumineX.com. The registration wizard (apple-shift-R) is actually a Java-based bundle. (We've been using SOAP since 10.0 days, and Java was the easiest way to get a SOAP library at the time we created the registrar.) The game only fires up the JVM if you open the registrar (triggered by opening the bundle, which happens when you try to open the panel). We wrote a tiny bit of Objective-C to load the bundle and jump into it; that's what the menu item actually calls. Thus, no Java in the main app and no penalty for firing up the JVM on launch. You'll note a hefty delay the first time you open the registrar, so that will give you a good idea of how long it takes to fire up Java! (It's long enough that we put up a panel to tell the user something is happening so that they know the app didn't go into la-la-land.)

--
Later,
Don Yacktman
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Disadvantages of Bridging Java in Objective-C Cocoa Apps (From: Eric Czarny <email@hidden>)

  • Prev by Date: Kernal/Quartz extension to "snap" mouse to nearest control
  • Next by Date: Re: createDirectoryAtPath problems
  • Previous by thread: Re: Disadvantages of Bridging Java in Objective-C Cocoa Apps
  • Next by thread: Re: Disadvantages of Bridging Java in Objective-C Cocoa Apps
  • Index(es):
    • Date
    • Thread