Community
Participate
Working Groups
I am unable to use the Visual Editor on Eclipse 3.1 under Windows XP and Sun's Java 1.5. I can reproduce this every time using either an existing project or a new one: When creating a new Visual Class from File->New->Other the Visual Editor eventually shows and I have: The Palette with only three tools: Selection, Marquee and Choose Bean. The content area is empty and,, The code area contains a bare class with a constructor and the initialize method. I have the following installed (from scratch, no old plugins around) VE-runtime-I20050720.zip (latest) GEF-runtime-3.1.zip emf-sdo-runtime-2.1.0.zip eclipse-SDK-3.1-win32.zip and Sun's 1.5.0_01 SDK The Eclipse log contains (and no, I can't explain the 1.5.0_02 vs. 1.5.0_01 jvm discrepancy either...): !SESSION 2005-07-20 15:00:52.629 ----------------------------------------------- eclipse.buildId=I20050627-1435 java.version=1.5.0_02 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_GB Framework arguments: --clean vm \java\jdk1.5.0_01\jre\bin\javaw.exe Command-line arguments: -os win32 -ws win32 -arch x86 --clean vm \java\jdk1.5.0_01\jre\bin\javaw.exe !ENTRY org.eclipse.ve.java.core 4 0 2005-07-20 15:02:07.879 !MESSAGE Exception thrown. !STACK 0 java.lang.NullPointerException at org.eclipse.ve.internal.java.codegen.java.rules.DefaultVisitorFactoryRule.retrieveFromCache(DefaultVisitorFactoryRule.java:83) at org.eclipse.ve.internal.java.codegen.java.rules.DefaultVisitorFactoryRule.getTypeVisitor(DefaultVisitorFactoryRule.java:109) at org.eclipse.ve.internal.java.codegen.java.JavaBeanModelBuilder.visitType(JavaBeanModelBuilder.java:508) at org.eclipse.ve.internal.java.codegen.java.JavaBeanModelBuilder.build(JavaBeanModelBuilder.java:417) at org.eclipse.ve.internal.java.codegen.core.JavaSourceTranslator.reverseParse(JavaSourceTranslator.java:831) at org.eclipse.ve.internal.java.codegen.core.JavaSourceTranslator.decodeDocument(JavaSourceTranslator.java:911) at org.eclipse.ve.internal.java.codegen.core.JavaSourceTranslator.loadModel(JavaSourceTranslator.java:577) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart$Setup.run(JavaVisualEditorPart.java:1856) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) !ENTRY org.eclipse.ui 4 4 2005-07-20 15:02:10.926 !MESSAGE Unhandled event loop exception !ENTRY org.eclipse.ui 4 0 2005-07-20 15:02:10.926 !MESSAGE Failed to execute runnable (java.lang.IndexOutOfBoundsException: Index: 1, Size: 1) !STACK 0 org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.IndexOutOfBoundsException: Index: 1, Size: 1) at org.eclipse.swt.SWT.error(SWT.java:2942) at org.eclipse.swt.SWT.error(SWT.java:2865) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:126) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3057) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2716) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1699) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:367) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:103) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948) Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 at java.util.ArrayList.RangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart$32.activeToolChanged(JavaVisualEditorPart.java:799) at org.eclipse.gef.ui.palette.PaletteViewer.fireModeChanged(PaletteViewer.java:175) at org.eclipse.gef.ui.palette.PaletteViewer.setActiveTool(PaletteViewer.java:383) at org.eclipse.gef.EditDomain.loadDefaultTool(EditDomain.java:188) at org.eclipse.gef.EditDomain.setPaletteRoot(EditDomain.java:339) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart.rebuildPalette(JavaVisualEditorPart.java:839) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart$14.run(JavaVisualEditorPart.java:1962) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) ... 18 more
Following Rich's advice on the newsgroups (regarding old workspaces) this bug seems to have two causes: Cause 1: Old workspace ~~~~~~~~~~~~~~~~~~~~~~ I created a fresh workspace and imported my existing projects. VE worked only on certain projects and not others - so my problem was at least partly due to the old cache you referred to. Cause 2: Vendor-specific JRE container ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The only difference between the ones that worked and the ones that didn't was that some of our project don't use the default JRE container (this is replaced by a vendor specific one) and I believe VE sources its core classes from that. Looks like I may have to go through some project gymnastics to use VE with these projects :( Lowering severity to major, as it's no longer a total loss of functionality
As mentioned in the newsgroup, it must be a JREContainer. Without it being a JREContainer we can't even launch the vm correctly because we would use the default java, not the one the special container points too. About the best I can do is launch with the default vm instead of barfing. But that means anything special about the vendor jre will be ignored. This is actually what JDT does too, they may compile against the vendor's classes, but if you did a launch java application it will launch the default vm instead of the vendor's vm. Could you please send us some info on this vendor container? Is it really not a JREContainer, or is it a JREContainer that points to a non-standard java? Is it because the jre the vendor is pointing to needs to be launched in a non-standard way?
It may be that a project is not configured with a full blown JRE, but rather with a JRE stub. This is a problem for VE, as it needs a JRE based VM to instantiate the visuals, and render them. There is really not much that VE can do, if an invalid JRE is defined. We can try and come up with the default (IDE) JRE. It will not solve cases where the default JRE conflics with the various stubs/jars that are in the project.
