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)

All
Other
defect
Not set
normal

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).
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.
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.
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.
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.
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.
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.
Blackconnect no longer builds and hasn't been worked on since 2001. -> WONTFIX
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.