Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Welcome to push OJI/Liveconnect Redesign

0 views
Skip to first unread message

Joshua Xia

unread,
Apr 17, 2003, 11:10:20 PM4/17/03
to
Sun's Java Plugin team and Browser Java team have investigated a lot
of bugs which related to Java, and focus on OJI/Liveconnect 's
stability and performance.

We have blueprint of redesign and the solution is to achieve the
following three goals:

1. XPCOM independent:
The new interface between OJI and JPI should be XPCOM independent. The
main purpose of doing this is to break the dependencies with
constantly changing Mozilla XPCOM APIs.

2. JNI Free:
The interface between OJI and JPI will hide JNIEnv from browser side.
Exposing JNIEnv interface to browser has at least two shortcomings:
1) JNIEnv interface is a low level interface to JVM functionality.
Exposing a low level interface to the browser makes the browser to
call into JVM randomly. This can cause a lot of subtle bugs.
2) It causes a lot of overheads especially for out-of-proc
implementation.

3. Gecko Plug-in API based:
Gecko Plug-in API has been adopted by different Netscape Plug-in
vendors for a long time. It is a stable C style API. Although it may
not be complete, the C style interface is a durable solution for cross
platform binary compatiblity.

If we can achieve these three goals, we can run java/liveconnect on
browser more stabile and efficient.

Soultion on browser side:
Create a new module works as OJI/Liveconnect 's function, this module
will:

1. Hide XPCOM, only provide C-style functions for JPI
2. Implement liveconnect function by using the APIs that JPI provides
(don't use JNI)
3. Backward compatibility, use different modules (select between
OJI/Liveconnect and New module on runtime) according to different
version JPI.

Welcome to push our OJI/Liveconnect Redesign again!

Henrik Gemal

unread,
Apr 19, 2003, 4:27:02 AM4/19/03
to

What's the timeframe for this?


--
Henrik Gemal
Mozilla Evangelist

Description of profile files:
http://gemal.dk/mozilla/files.html

Joshua Xia

unread,
Apr 20, 2003, 11:21:19 PM4/20/03
to
Henrik Gemal <sp...@gemal.dk> wrote in message news:<b7r0pj$hr...@ripley.netscape.com>...

Sun's Java Plugin team plan to add new APIs in "Tiger" project (J2SE
1.5) which will be code frozen on this Aug.
So we expect to add a new module on mozilla 1.5

Thanks for push!

Mark Phillips

unread,
Aug 7, 2003, 1:03:29 PM8/7/03
to
Sounds good.

My top prioity would be for the interface to use a standardised C ABI,
so that
a java plugin built with a completly different compiler (vendor and/or
version) than mozilla would work correctly.

In particular, I am currently struggling to get a working Solaris
Mozilla 1.4. All the official builds use CTL
which in turn (on at least sun and linux platforms) breaks cursor
updating when
lines are wrapped!!!

I can build a working Mozilla 1.4 using gcc 3.3, but I can't have Java
because that latest Java runtime only includes a Forte compiled lib and
the older ones only include gcc2 and Forte libs....

Keep up the good work!
Mark

0 new messages