Closed
Bug 96888
Opened 23 years ago
Closed 19 years ago
Java XPIDL does not support new scriptable IDL type AString
Categories
(Core Graveyard :: Java to XPCOM Bridge, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: jonsmirl, Assigned: blackconnect)
Details
AString is a new scriptable string type in XPIDL. It was created as part of
SCC's rework of the Mozilla string support. BlackConnects type support needs to
extended to cover AString (alias DOMString).
Comment 1•23 years ago
|
||
Looking in nsrootidl.idl, the only thing that marks the AString typedef as such
is an astring attribute. Is there a declaration of AString in IDL? Looks like
Bug #84186 was solved in way that only C++ and Javascript can use this type.
Comment 2•23 years ago
|
||
Any language mapping can do AString (and the newer UTF8 and ASCII variants). The
libxpt type system indicates these types just like any others. BlackConnect has
C++ code that does type conversions (just like xpconnect and PyXPCOM). It is
just a matter of adding cases to deal with these C++ types. This is not trivial,
but not exclusionary either.
Comment 3•23 years ago
|
||
I looked through xpcconvert.cpp this morning. It assumes that anything marked
as T_ASTRING or T_DOMSTRING in the typelib is an nsAReadableString.
But the actual type of the argument could be any subclass of nsAString.
So, if the actual type behaves differently from nsAReadableString, a javascript-
method will produce results that differ from the same method written in C++.
We could do the same for java and python. But I'm not sure it's the right thing
to do.
Comment 4•23 years ago
|
||
I'm not that familiar with BlackConnect. But isn't there some kind of parameter
translation, or has all the previous types mapped directly to Java types and
were just passed through? I would expect there is machinery in place to convert
xpidl "string" (char *) params to Java Strings. I would expect the same thing to
take place when passed a UTF8String.
Comment 5•22 years ago
|
||
Is it okay to assume that the IDL types AString, ACString, and AUTF8String
are 'const' types, where their values will never change? If so, then it would
be easy to implement support for them in Java, since we could convert them into
straight Unicode over on the Java side and back into their particular encodings
when passing over to the rest of the XPCOM world.
Comment 6•22 years ago
|
||
It really shouldn't be that much different than how "string" is currently
handled, since that has to be converted as well. On a call into Java, you should
copy the string to a Java string and pass that in. If it's an in/out parameter,
you'll need to convert the Java string back to the Mozilla string.
Comment 7•19 years ago
|
||
Blackconnect no longer builds and hasn't been worked on since 2001. -> WONTFIX
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Updated•10 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•