Re: [infinispan-dev] Separating FluentTypes into a separate file?
Hi Galder,
since it's not a public class I don't think that would be a problem;
in fact since the fluent configuration is relatively new maybe it's
better to break such things now than later.
On 12 October 2011 17:14, Dan Berindei <dan.berindei(a)gmail.com> wrote:
Making a non-public type public preserves binary compatibility,
according to
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Achieving_API_Binary_C...
I don't think that's related with Galder's question is it? Why do we
need binary compatibility? I think he's referring to APIs. Anyway the
classname is changing as well as it was a nested class so I don't
think it's preserving binary compatibility.
Cheers,
Sanne
Cheers
Dan
On Wed, Oct 12, 2011 at 5:28 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
> Hi,
>
> Would it cause any problems if FluentTypes class in FluentConfiguration was separated
into a separate file? i.e. backward compatibility issues.
>
> Remember that FluentTypes is not a public interface per se, and it's not
something clients would reference directly.
>
> The reason I want to change this is cos it causes all sorts of access issues when you
try to use fluent configuration from Scala.
>
> If it can be problematic, no probs, I'll wait for 6.0 to separate this class into
a separate file and Scala can carry on with old configuration.
>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev