It is still a bad design decision to serialize objects (that implement
an interface) where the interface contract does not state that the
implementation have to be serializable or not.
On 24.03.2016 23:37, Franz Zieris wrote:
> Awesome! The nested annotations look slightly weird, but I guss it's
not hard to get used to it.
>
> Any reason for not using the simpler @Signature(String,class,
String.class)?
The @Argument annotation could also support additional properties,
e.g. being one for being optional:
@Signature({@Argument(type=String.class, optional=true)})
But maybe optional arguments aren't such a good idea anyway. Maybe we
could provide one browser function per valid parameter set.
> Have you considered that the EasyMock proxy objects might have
circular references internally? This would explain why the explicit
@Expose approach works, as these internal fields are not considered then.
Ah, sure! I used an EasyMock for the IPath field in ProjectTreeNode,
and who knows what's in there. So for testing it's either EasyMock
with the customized Gson or fully implemented Dummies with standard
Gson. Thanks for the hint.
Franz
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
