"Java Model Exception: Java Model Status [Update conflict]" encountered while QuickFixing

282 views
Skip to first unread message

FloGa

unread,
Nov 16, 2012, 2:43:29 PM11/16/12
to eclim...@googlegroups.com
Hi!

There are several situations where I get such an Exception while doing a :JavaCorrect in (G)Vim.

The first is, if I open the java file in Vim and then I start Eclipse with embedded eclimd-view.

The second method to reproduce is to have the same file open in Vim and in Eclipse, then do a QuickFix in Eclipse. Every :JavaCorrect in Vim from that time on will result in the said Exception. It first stops coming if I restart the eclimd-view in Eclipse.

What happens in detail? Let's assume, I have a minimal Java file.

import java.util.ArrayList;

public class TestClass {
    ArrayList al = new ArrayList();
}

I force a QuickFix situation by deleting the import-line, then the line with ArrayList will ask me to insert the import-line again.

As I said, if I've done one of the two steps I explained above, then :JavaCorrect will show me the option to import the module and if I enter on it, it will produce the following error on the statusline:
Java Model Exception: Java Model Status [Update conflict]
while executing command (port: 9091): -editor vim -command java_correct -p "TestCase" -f "src/TestClass.java" -l 2 -o 25 -e utf-8 -a 0

The import-line will be inserted, though, but I have to reload the file to see it. 
 
With :let g:EclimLogLevel = 10, it says
Java Model Exception: Java Model Status [Update conflict]
^Iat org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:784)
^Iat org.eclipse.jdt.internal.core.CompilationUnit.commitWorkingCopy(CompilationUnit.java:391)
^Iat org.eclim.plugin.jdt.util.JavaUtils.format(JavaUtils.java:565)
^Iat org.eclim.plugin.jdt.command.correct.CodeCorrectCommand.apply(CodeCorrectCommand.java:345)
^Iat org.eclim.plugin.jdt.command.correct.CodeCorrectCommand.execute(CodeCorrectCommand.java:135)
^Iat org.eclim.command.Main$1.run(Main.java:98)
^Iat org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
^Iat org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
^Iat org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3529)
^Iat org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3182)
^Iat org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1029)
^Iat org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
^Iat org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:923)
^Iat org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
^Iat org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588)
^Iat org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
^Iat org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543)
^Iat org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
^Iat org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
^Iat org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
^Iat org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
^Iat org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
^Iat org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
^Iat org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
^Iat sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
^Iat sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
^Iat sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
^Iat java.lang.reflect.Method.invoke(Method.java:616)
^Iat org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
^Iat org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
^Iat org.eclipse.equinox.launcher.Main.run(Main.java:1438)
^Iat org.eclipse.equinox.launcher.Main.main(Main.java:1414)
while executing command (port: 9091): -editor vim -command java_correct -p "TestCase" -f "src/TestClass.java" -l 2 -o 25 -e utf-8 -a 0

Any suggestions on that?
I use Gentoo Linux with (G)Vim 7.3+ and Eclipse Juno (4.2), current version of eclim (v2.2.3).

Eric Van Dewoestine

unread,
Nov 16, 2012, 9:11:21 PM11/16/12
to eclim...@googlegroups.com
This should be fixed now in the latest code on github. If you could
try it out to make sure you don't run into any more problems that
would be great, otherwise I'll plan on release it, along with some
other fixes, in the next few days.

--
eric

FloGa

unread,
Nov 17, 2012, 3:15:52 AM11/17/12
to eclim...@googlegroups.com
Hi! Now it works just perfectly, I couldn't reproduce the error anymore. Thanks!

But while I was compiling it from source, there was some sort of warning:

build:
build.eclipse:
init:
     [exec] fatal: Not a valid object name indigo
     [echo] Unable to get indigo release information - do you have an indigo branch?
     [echo] eclim.version: 2.2.3.35-ge109e8a
     [echo] eclim.release: 2.2.3
     [echo] eclim.release.indigo: none
------ init

Is that normal?

FloGa

unread,
Nov 17, 2012, 3:32:56 AM11/17/12
to eclim...@googlegroups.com
Sorry, my bad. I was on the master branch. On the indigo-branch, it works just fine.

Eric Van Dewoestine

unread,
Nov 17, 2012, 10:04:09 AM11/17/12
to eclim...@googlegroups.com
That's nothing to worry about. I have a separate branch for continuing
indigo support and the build script attempts to pull in version
information from that branch so that when I build the eclim docs, I
can have them include accurate current version information for both
the juno (master) and indigo releases.

I've updated the build script to suppress those messages since pretty
much no one but myself will care about having the docs include indigo
version numbers and there is not need to alarm users with "fatal: ..."
type messages.

--
eric

FloGa

unread,
Nov 18, 2012, 11:22:39 AM11/18/12
to eclim...@googlegroups.com
So, it doesn't matter which branch I use to compile, am I right?

The master branch then can also handle Eclipse Indigo?

Eric Van Dewoestine

unread,
Nov 18, 2012, 11:37:20 AM11/18/12
to eclim...@googlegroups.com
On 2012-11-18 08:22:39, FloGa wrote:
> So, it doesn't matter which branch I use to compile, am I right?
>
> The master branch then can also handle Eclipse Indigo?

No, the master branch only supports Juno and the indigo branch is
really more of a fork of master to support Indigo.

--
eric

FloGa

unread,
Nov 18, 2012, 11:52:05 AM11/18/12
to eclim...@googlegroups.com
Okay, I got it. Thank you!
Reply all
Reply to author
Forward
0 new messages