[
https://issues.apache.org/jira/browse/THRIFT-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Schuller updated THRIFT-1013:
-----------------------------------
Attachment: thrift-r1042609-libfqcn.patch
thrift-0_5-libfqcn.patch
I am attaching a patch against 0.5 and one rebased against trunk, that makes
the backend use fully qualified class names when referring to thrift library
classes.
However, I realized the domain classes must also be referenced fully qualified
(it's not enough to do it one-way). I was hoping to postpone that but we need
it for this particular case already.
However, In the interest of keeping patches more isolated I wanted to submit
these first for consideration before I make further changes to how the domain
class names are generated.
> generated java code may have name clashes with thrift library
> -------------------------------------------------------------
>
> Key: THRIFT-1013
> URL: https://issues.apache.org/jira/browse/THRIFT-1013
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
> Affects Versions: 0.5
> Reporter: Peter Schuller
> Attachments: thrift-0_5-libfqcn.patch, thrift-r1042609-libfqcn.patch
>
>
> We had a structure called 'State' in a thrift spec which caused the generated
> Java code to have a naming conflict; State conflicts with
> TAsynchMethodCall.State (an enum).
> Since part of the point of thrift is long-term compatibility and an evolving
> thrift spec, it's not very practical to have the potential for naming
> conflicts like this. So we want to fix it. But because it is at least
> slightly painful to do, I want to make sure people are fine with the intended
> fix.
> Proposed fix:
> (1) Remove t_java_generator::java_thrift_imports() completely.
> (2) Replace all references to imported Thrift library classes so their fully
> qualified class names.
> The generated code will be a bit less readable due to fully qualified class
> names, but the code should be correct and it should be obvious what comes
> from where (if fully qualified names matter that means a human is looking at
> the code, in which case importing * is not terribly nice anyway).
> Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
