"Dictionary" as a name generates NullPointerException

[e-grigorov]

Steps to reproduce:

• Vorto 0.10.0.M2, Eclipse 4.7.3.M20180330-0640
• In Vorto Model Project Browser, choose one of:
  • New Entity
  • New Enum
  • New Functionblock
• Use "Dictionary" for the name
• Choose ok

As a result, the error log contains:

java.lang.NullPointerException
	at org.eclipse.vorto.wizard.AbstractVortoWizard.openTypeWithDefaultEditor(AbstractVortoWizard.java:69)
	at org.eclipse.vorto.wizard.datatype.AbstractDatatypeWizard.performFinish(AbstractDatatypeWizard.java:53)
	at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:778)
	at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:417)
	at org.eclipse.jface.dialogs.Dialog.lambda$0(Dialog.java:619)
	at org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:81)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:249)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4428)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1079)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4238)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3817)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:818)
	at org.eclipse.jface.window.Window.open(Window.java:794)
	at org.eclipse.vorto.perspective.vorto.view.DatatypeTreeViewer$1$3.doAction(DatatypeTreeViewer.java:116)
	at org.eclipse.vorto.perspective.command.ProjectAction.run(ProjectAction.java:39)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
	at org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:397)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4428)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1079)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4238)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3817)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1499)

[Ebolon]

@aedelmann: Here is the exact same problem solved by adding a new rule which includes keywords like Dictionary. But maybe a better solution would be to change the rule for Dictionary. A functionblock, entity, etc. name is required to start with a capital letter. When Dictionary would have written as dictionary like all other types there would be no conflict. This would be a backward compatibility breaking change. How do you feel about this?

[aedelmann]

Yeah, we should definite have a consistent declaration and therefore change it to lowercase.
But the link you provided would also solve a lot of stuff. Currently it is not possible to use the keyword status e.g. as part of the namespace. This would solve this prob. I like that. :)
You are right that this would break the current DSL. But still we need to address it.

[e-grigorov]

Yeah, we should definite have a consistent declaration and therefore change it to lowercase.

I would like to vote for this approach i.e. data type unification. Let's say that built-in types will be: camelCase. In this way, we have a clear separation from the custom types where they are forced to start with an uppercase letter.