Re: JavaXPCOM components

retrev <[email protected]> Mon, 25 Feb 2008 13:45:22 -0800 (PST)
Newsgroups gmane.comp.mozilla.devel.java
Organization http://groups.google.com
Message-ID <c9381605-596d-41c9-8e88-cb0fcb2bf270__2710.64226185462$1203976267$gmane$org@e60g2000hsh.googlegroups.com>
On Feb 15, 9:14 am, Greg Bowyer <[email protected]> wrote:
> retrev wrote:
> > I sent an email to Javier Pedemonte's gmail addr but I haven't
> > received a response so I figured I'd float my email here and maybe
> > someone else can help me.
>
> > I work on a team that develops a C++ application with a plug-in
> > extension system. We are looking to write plug-ins in java and one of
> > the technologies we are investigating is XPCOM. It looks like the
> > JavaXPCOM code to write Java components is not in the current Mozilla
> > trunk. Comments on the bugzilla issue suggest that Javier has some
> > code that works but needs to be integrated with the current trunk. If
> > we decide to use xpcom, we would be able to spend some time getting
> > the JavaXPCOM component code updated. I would like to know the status
> > of this code so I can work up a level of effort. Does the code allow
> > creation of Java components on an older trunk and just needs updating?
> > Does it have minimal component functionality but is missing a lot of
> > features? We have a couple of strong C++ programmers with some minimal
> > XPCOM knowledge (we've spent about a month getting a trimmed down
> > version of our app working with XPCOM, C++, and PyXPCOM) so we are not
> > completely green but would likely need some guidance with the effort.
>
> As far as my current understanding of java XPCom compents goes, its only
>  possible at present to develop an XPCom component in Java *if* java
> hosts the gecko / xulrunner.
>
> The patches are for xulrunner being run in its own process, which allow
> xulrunner to host the JavaXPCom components (so xulrunner hosting java)
>
> Judging from what you say it sounds like you are only interested in the
> xpcom part of the bargin and not the entire xulrunner stack - is this
> right ?


Yes...I'm adapting an existing app with an extensive UI system and
event loop so I won't be using xulrunner...just xpcom standalone (or
as close as I can come). I'd be able to initialize a java vm in my
process before initializing the xpcom system but the main app is not
java based.