slice2java

[alexander]

i'm not sure if it's a bug and not a feature.
slice2java generates code with wrong class names in case of using external ice-modules and using --package option. I need that option to explictly specify package name as I want to have the following directory/class hierarhy:
test/
server/
client/
common/

where package test.server consists of server implementation, test.client - client implementation and test.common - slice2java generated stuff shared by both client and server. i know that if i use "module test.common" in test.ice i get what i want but i think it's a wrong way to mix declaration and implementation things.

$ slice2java --package test.common test.ice

------------------ test.ice ------------------
#include <Ice/BuiltinSequences.ice>

interface Test {
void testByteSeq(Ice::ByteSeq seq);
};

------------------ test/common/_TestDisp.java ------------------
...
public static IceInternal.DispatchStatus
___testByteSeq(Test __obj, IceInternal.Incoming __in, Ice.Current __current)
...
byte[] seq;
seq = test.common.Ice.ByteSeqHelper.read(__is);
...

------------------ test/common/_TestDelM.java ------------------
...
public void
testByteSeq(byte[] seq, java.util.Map __context)
...
test.common.Ice.ByteSeqHelper.write(__os, seq);
...

------------------
Notice wrong type in both files test.common.Ice.ByteSeqHelper instead of Ice.ByteSeqHelper

[mes]

Hi,

You're right, currently the translator applies the package prefix to all types. Unfortunately, this is a tricky issue. If instead we only applied the prefix to types defined in the current file (and not to types in #include'd files), then there is a similar risk of generating incorrect code, since some of those files may have been generated using a (potentially different) package prefix.

The 'module workaround' you mentioned is one possible (although not very attractive) solution. You could also try to avoid including external Slice files, but that may not be possible for you.

In any event, this is something that needs to be fixed. We'll discuss this and come up with a solution.

Thanks for bringing this to our attention.

- Mark

[alexander]

I see the problem with module - package mapping. And I can not see any rational way to fix it while it is possible to override package name at the time of generating code so there is no information about package names in ice sources.
IMHO, one solution is to:
1) remove comman line option to redefine package name (optional, could be kept for compatibility)
2) add somthing like the following to the ice syntax:

["java:<package_name>"] module <module_name> {
}

Thanks for your work
Alexander

[mes]

Hi,

Yes, the best solution is to have the package information in the Slice file. We considered using the existing metadata facility for specifying the package. The problem, however, is that you would have to repeat the metadata for every top-level definition in the file, and it introduces some perplexing issues. We solved it a slightly different way.

In the next release, Slice will support "global" metadata, which is metadata that can only appear once in a file, must appear before any definitions, is not affected by and has no effect on included files, and applies to all of the definitions in the file. For example:

[["java:package:com.zeroc"]]
module M {
    // ...
};

Thanks again,
- Mark

[alexander]

Hmm... Does "global" mean that all top level definitions in the ice file share package name from such metadata? What about following collision:

module m1 {
interface I {};
};

module m2 {
interface I {};
};

However, it makes sense if such metadata used as "prefix" so the following ice definition

[["java:package:test"]]

module m1 {
interface I {
...
};
};

module m2 {
interface I {
...
};
};

produces test.m1.I and test.m2.I without any namespace confilicts

[mes]

Right, the global metadata defines a package prefix for all of the definitions in the file.

- Mark

[alexander]

Ok, thanks for your answer.