Closed Bug 18277 Opened 25 years ago Closed 24 years ago

Need to lazily load the OJI DLL

Categories

(Core Graveyard :: Java: Live Connect, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 26516
Future

People

(Reporter: sfraser_bugs, Assigned: drapeau)

References

Details

(Keywords: helpwanted, perf, Whiteboard: [rtm-])

The OJI DLL gets loaded at startup now by the following call in
nsJSEnvironment::nsJSEnvironment().

  // Initialize LiveConnect.  XXXbe uses GetCID rather than progid
  NS_WITH_SERVICE(nsILiveConnectManager, manager,
                  nsIJVMManager::GetCID(), &rv);

OJI should only be loaded the first time it is needed.
Assignee: fur → drapeau
I think this is an OJI issue, not a LiveConnect one.  The LiveConnect API was
designed from the start to allow the JVM to load lazily, i.e. at the first
reference to LiveConnect from a script.  (From the viewpoint of LiveConnect, OJI
is just a JVM that wraps around the real JVM, so OJI should be able to load
lazily as well).  I *thought* that Warren got lazy OJI/JVM loading working a
long time ago, but perhaps that was in the MozillaClassic codebase.
Yeah, that was in mozilla classic.
Status: NEW → ASSIGNED
Target Milestone: M14
Will look into this, not for this milestone, though.
Updating QA Contact
QA Contact: cbegle → rginda
Blocks: 1785
New feature.
Target Milestone: M14 → M30
This is a *feature* ? Adding perf to the keywords.
Keywords: perf
I changed OS to All.  I don't think this should be M30, either.  Is there any 
hold-up that I can help with?

/be
OS: Mac System 8.5 → All
I agree that this shouldn't be M30 (which used to mean post-FCS). This seems 
like a simple win if someone just spends a few hours to clean it up.
I just discovered bug 26516 which is a dup. Drapeau - can you work with av to 
see who's going to own this?
Brendan, you can help if you can fix the bug.  Right now, we're trying to get 
security working in OJI and plugins for M16, plus some other bugs.  Just no 
staff to take care of this one right now.

I'll change the milestone date to "Future", which right now reflects the 
accuracy of my ability to predict when this will get fixed.

Warren: I won't be able to work with av on this for another week.  Ed Burns is 
the likely candidate to delve into this, and he's away on business all of this 
week.  If I can get somebody else to look into it this week, I will, but right 
now the other folks are busy on other tasks, so unfortunately I believe it's 
unlikely that I'll be able to determine the proper ownership this week.
Target Milestone: M30 → Future
I really think we should fix this.
Keywords: arch
Keywords: arch
Any chance this will get fixed for final release?  It's designed to be
lazy-loaded, after all.  Adding helpwanted
Keywords: helpwanted
I don't know how much time this costs during startup, but I'll nominate it for 
RTM, Mozilla 0.9. This should really be fixed...
Whiteboard: [Mozilla0.9] [RTM]
You nominate with keywords (which get spell-checked and are more queryable,
compared to made-up status whiteboard [PseudoKeywords] -- see the roadmap).  I
took the liberty of fixing these.

/be
Keywords: mozilla0.9, rtm
Whiteboard: [Mozilla0.9] [RTM]
rtm-, not stop ship, no patch.
Whiteboard: [rtm-]
Adding this bug to startup performance tracker bug 7251
Blocks: 7251
This is a dup of bug 26516.  This bug has some valuable status though.

*** This bug has been marked as a duplicate of 26516 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
No longer blocks: 7251
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.