My top prioity would be for the interface to use a standardised C ABI,
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
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!
Joshua Xia wrote:
> Henrik Gemal wrote in message news:...
>>Joshua Xia wrote:
>>>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
>>>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
>>>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
>>>Welcome to push our OJI/Liveconnect Redesign again!
>>What's the timeframe for this?
> 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!