Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Problem with Features of Type Class(Inconsistent implementation in EcoreFactoryImpl)
Problem with Features of Type Class [message #1855268] Wed, 05 October 2022 12:09 Go to next message
Thomas Kohler is currently offline Thomas KohlerFriend
Messages: 3
Registered: June 2018
Junior Member
Hello,

When using the type "Class" (any Java class) for a feature in an ECore Model null will be marshalled to "" for the xmi xml as defined in class org.eclipse.emf.ecore.impl.EcoreFactoryImpl:

public String convertEJavaClassToString(EDataType metaObject, Object instanceValue)
  {
    return instanceValue == null ? "" : ((Class<?>)instanceValue).getName();
  }


The conterpart method:

  public Class<?> createEJavaClassFromString(EDataType metaObject, String initialValue) 
  {
    try
    {
      if (initialValue == null) return null;
      else if ("boolean".equals(initialValue)) return boolean.class;
      else if ("byte".equals(initialValue)) return byte.class;
      else if ("char".equals(initialValue)) return char.class;
      else if ("double".equals(initialValue)) return double.class;
      else if ("float".equals(initialValue)) return float.class;
      else if ("int".equals(initialValue)) return int.class;
      else if ("long".equals(initialValue)) return long.class;
      else if ("short".equals(initialValue)) return short.class;
      else return Class.forName(initialValue);
    }
    catch (ClassNotFoundException e)
    {
      throw new WrappedException(e);
    }
  }


throws an Exception when trying to load a Class for name "". I think null instead of "" would be correct in convertEJavaClassToString.

It seems this is an inconistent implementation, we get an error in a ChangeDescription where a feature of type Class was set, the ChangeDescription stores "" which causes an error when we resume the ChangeRecorder.

Before someone asks: Yes, we store ChangeDescriptions. It works perfectlly, but now we have features of type Class the first time ...

If this is a bug, where is it possible to notify this?

Reagrds,
Tom

[Updated on: Wed, 05 October 2022 12:11]

Report message to a moderator

Re: Problem with Features of Type Class [message #1855269 is a reply to message #1855268] Wed, 05 October 2022 13:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33143
Registered: July 2009
Senior Member
Yes, this looks wrong and surprising that it's first reported/noticed after more than 20 years.

Please report the problem here:

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EMF&version=2.32.0&component=core


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Problem with Features of Type Class [message #1855277 is a reply to message #1855269] Thu, 06 October 2022 04:58 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

It's more an omission than a bug.

else if ("".equals(initialValue)) return Class.class;

could be added.

It's not so surprising it's unreported.EMF is for modeling and EJavaClass is for coding workarounds. On the rare occasions that I needed EJavaClass, it was for internal and so transient use. When classes need serializing they have a String serialization such as java.lang.String and so their metatype is EString.

Regards

Ed Willink
Re: Problem with Features of Type Class [message #1855278 is a reply to message #1855277] Thu, 06 October 2022 06:37 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33143
Registered: July 2009
Senior Member
If null serializes as "" then deserializing "" to Class.class doesn't seem correct nor helpful. I don't see the point of representing null as "" in the first place, so better to remove that instead continuing that questionable approach (which has never worked in terms of creating a deserializeable result).

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Problem with Features of Type Class [message #1855311 is a reply to message #1855278] Fri, 07 October 2022 08:39 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Yes, there is certainly a danger when changing one strange legacy behavior to a different behavior.

Legacy-wise, I'm wary of changing a ...toString method that doesn't return null to one that does.

Given the need for special nil XML handling, perhaps the null could/should have been handled before it was passed to convertToString.

Regards

Ed
Previous Topic:Model not shown properly in Model Explorer
Next Topic:Proper way to store and save EObjects
Goto Forum:
  


Current Time: Thu May 02 00:02:52 GMT 2024

Powered by FUDForum. Page generated in 0.03334 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top