[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