[
https://issues.apache.org/jira/browse/THRIFT-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15626227#comment-15626227
]
ASF GitHub Bot commented on THRIFT-3301:
----------------------------------------
Github user bgould commented on the issue:
https://github.com/apache/thrift/pull/1120
@jeking3
Yes exactly. I added it to the build process that compiles the java unit
tests... so if some change to compiler introduces a regression, the IDL in that
file should fail to compile. I didn't add a unit test for this as I felt that
the compilation itself was the test.
Consider the following IDL:
struct String {
1: string val
}
struct Object {
1: map<string, String> somemap
}
It would be possible to make a modification to the compiler that
erroneously generates the map type as `java.util.Map<String, String>` instead
of `java.util.Map<java.lang.String, String>` or to add some reference in the
generated code to `java.lang.Object` that is not fully-qualified... however
with the generated classes above in the `thrift.test` package, `javac` should
flag the unqualified reference(s) as ambiguous.
> Java generated code uses imports that can lead to class name collisions with
> IDL defined types
> ----------------------------------------------------------------------------------------------
>
> Key: THRIFT-3301
> URL: https://issues.apache.org/jira/browse/THRIFT-3301
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
> Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2
> Environment: Tested on Linux (Ubuntu 14) with Oracle JDK 8
> Reporter: Alexander Volanis
> Attachments: thrift-issue-3301.tgz
>
>
> The Java generator will produce Java classes with the following set of imports
> {code}
> import org.apache.thrift.scheme.IScheme;
> import org.apache.thrift.scheme.SchemeFactory;
> import org.apache.thrift.scheme.StandardScheme;
> import org.apache.thrift.scheme.TupleScheme;
> import org.apache.thrift.protocol.TTupleProtocol;
> import java.util.List;
> import java.util.ArrayList;
> import java.util.Map;
> import java.util.HashMap;
> import java.util.EnumMap;
> import java.util.Set;
> import java.util.HashSet;
> import java.util.EnumSet;
> import java.util.Collections;
> import java.util.BitSet;
> import java.nio.ByteBuffer;
> import java.util.Arrays;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> {code}
> Any one of the imported classes may cause a name conflict with generated code
> that happens to define a same name class and uses such class as argument or
> result to methods.
> The generated code should always use fully qualified references to the
> classes when necessary and avoid all use of imports.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
