[forge-dev] in forge java model, are two different implementations of the same java class equal?
Lincoln Baxter, III
lincolnbaxter at gmail.com
Wed Feb 27 02:24:13 EST 2013
Yeah, I think I like that approach. Just mirror what ClassLoaders do.
+1
On Wed, Feb 27, 2013 at 2:12 AM, Thomas Frühbeck <fruehbeck at aon.at> wrote:
> perhaps something similar to class loading makes sense: origin of class
> (jar/file system) + qualified name
> IMHO: origin matters for the plugin (e.g. scaffold), qualified name
> matters for the generated application, I can't see a way to handle such
> completely different view in a consistent simple way
>
> I would stay away from anything more "intelligent" than is possible,
> equivalence of method signature is merely another - perhaps unwanted -
> coincidence, if the runtime provides more than one class per qualified name
> which are not _really_ equal, isn't it?
>
>
> Am 26.02.2013 23:18, schrieb Lincoln Baxter, III:
>
> Would it be too naive to simply take the fully qualified name and compare
> that? I understand that there may be different method signatures in the
> API, but...
>
> If we really wanted to, we could compare the public signature of the class
> and determine non-generic equivalence. Thoughts?
>
>
> On Sat, Feb 23, 2013 at 4:17 PM, John Franey <jjfraney at gmail.com> wrote:
>
>> But: Equality test is not going to work in all cases. Not all information
>> from the source is compiled into the class file by the java compiler. For
>> example, erasure (generics) and SOURCE and CLASS RetentionPolicy on
>> annotations.
>>
>>
>>
>>
>> On Sat, Feb 23, 2013 at 3:07 PM, John Franey <jjfraney at gmail.com> wrote:
>>
>>> I agree. Here is the impact on the implementation.
>>>
>>> First, equals/hashcode cannot depend on internals of their class,
>>> instead they must be implemented in terms of the public methods of the java
>>> model interface. JavaClassImplOne and JavaClassImplTwo would have
>>> different internal variables.
>>>
>>> Second, equals cannot fail if the compared objects are not the same
>>> class, e.g. JavaClassImplOne and JavaClassImplTwo. e.g., use
>>> other.isAssignable(JavaClass.class).
>>>
>>> Third, equals/hashcode implementations that depend only on the methods
>>> of the java model api would probably not belong in the impl package. They
>>> would probably be better located in the api package. Then
>>> JavaClassImplTwo would not have to depend on impl.JavaClass to share
>>> equals/hashcode. This would mean that some interfaces in api package would
>>> have to be abstract classes.
>>>
>>> Others?
>>>
>>> Thoughts?
>>>
>>> Regards,
>>> John
>>>
>>>
>>> On Sat, Feb 23, 2013 at 1:45 PM, George Gastaldi <ggastald at redhat.com>wrote:
>>>
>>>> IMHO, equals should return true in this case only if the class
>>>> structure (including attributes, interfaces, methods) matches. The fact
>>>> that a class is editable or not shouldn't matter in terms of comparison.
>>>>
>>>> Em 23/02/2013, às 15:38, John Franey <jjfraney at gmail.com> escreveu:
>>>>
>>>> >
>>>> > This is with respect to providing an alternate java model
>>>> implementation for binary classes defined in other projects.
>>>> >
>>>> > Given two JavaClass with exactly the same java definition, but one
>>>> comes from source code, and the other from a binary class file, (or in
>>>> other terms, one is editable, the other is not), would
>>>> (javaClass1.equals(javaClass2) == true)?
>>>> >
>>>> > It likely does not matter in practice. The likelihood of a forge
>>>> developer creating as source class with a definition exactly like a binary
>>>> dependency seems very low, not impossible, but low.
>>>> >
>>>> >
>>>> >
>>>> > John
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > forge-dev mailing list
>>>> > forge-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> forge-dev mailing listforge-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130227/ba1a5fe8/attachment.html
More information about the forge-dev
mailing list