I am writing a software in java and this inheritance problem always crops up. Funny enough, I don't get problems when i run the program in my IDE (Eclipse Kepler) but once i export it to an executable jar, problem starts. I think I am the only one experiencing this problem because all searches on google show the direct opposite.
My problem is I have an interface named VoteType. This interface is implemented by several concrete classes. I save the concrete implementation to a file using XMLEncoder and retrieve it using XMLDecoder.
But when i try to cast it to the interface it implements VoteType, I get a ClassCastException. What could possibly be causing this?
You are not precise enough to track this down, but I assume that the interface and the object implementing the interface and which is created via XMLDecoder are created by different class loaders. Could that be the reason?
See also this problem: Solution for the ClassCastException due to ClassLoader issue
Related
in java the Thread.join(long millis) method is not a synchronized method. also you can see this method declaration form this link: https://docs.oracle.com/javase/9/docs/api/java/lang/Thread.html#join-long- but eclipse and idea showing this method as synchronized. you can look at the following picture to what I want to mean. by the way, I am using java 9 in eclipse
how can I fix this problem in eclipse ?
Eclipse and IntelliJ are showing you the actual code, and thus are correct by defintion. The apparent mismatch is because Javadoc doesn't show whether a method is synchronized.
This was a deliberate design decision; see this bug report. Quoting:
It's important for the developer to know whether it's safe for multiple threads
to operate on an object concurrently, However, this synchronization can be
done either in public methods or in private methods, and the Java Platform API
spec should not declare one to be preferred over the other. A licensee should
be able to achieve synchronization internally if they wish.
Therefore, the general description of a class should mention whether the class is thread-safe or not. Individual method descriptions that are exceptions should mention that they are exceptions.
The TL;DR is that synchronized is an implementation detail, not part of the method contract. So Javadoc doesn't show it.
I got a little problem. I want to use hibernate in an eclipse rcp. (i'm new to osgi and eclipse rcp). So I added the jar into the plugin-project folder and the build path and the bundle build path, but when I try to use hibernate from my bundle, it crashes with a ClassNotFoundException.
What is the proper way to do this?
Pls look at eclipse buddy policy. This might help you if you are facing class not getting loaded because of osgi classloading.
Hibernate, and many other classic Java programs (ab)use dynamic class loading to to connect the different parts. They classes they use are read from a file and then loaded with Class.forName. This is fundamentally not-modular since these classes are by definition implementation classes, which should be hidden.
Since OSGi is a modularity framework it puts fences around a module (a bundle) and refuses to load anything that is not properly exported and imported. So if Hibernate does its Class.forName it will run right into this fence, as it should be to get the advantages of modularity.
Eclipse Buddy policy is like a huge hole in this fence, moving things back tot he bad old classpath: linear search. With a buddy policy, Eclipse will just start searching if there is a class somewhere that has that name. Since this ignores versions, you can no longer rely on proper version handling. The good news is that it works most of the time. The bad news is that you loose privacy and when it does not work you get weird errors.
With Hibernate, only solution is to not use the text file setup but use the API and give Hibernate the actual classes. In those cases Hibernate will use the class loader of those classes and that works. In OSGi, as long as you follow the Java language rules there are no problems.
To handle the kind of problems that class loading hacks address OSGi uses services.
I want to have a possibility to decode error stacktraces that appear in the production environment.
If you kept your symbolMap around, yes; e.g. check out
http://code.google.com/p/speedtracer/wiki/ResymbolizationProtocol
(disclaimer: never tried it, myself)
you need to use the JsEmulateStackTrace class. Its seemly very complex and have never really gotten around to implementing it fully myself.
http://code.google.com/p/google-web-toolkit/wiki/WebModeExceptions
this hypothetically remaps your symbol map for you, but honestly i doubt it works fully as i haven't seen a library/module yet that provides proper stack tracing for gwt. So that tells me its pretty hard or not fully working.
honestly it might be better to create some code to inject at compile time that provides stack trace support, that allows you to generate your own stack trace rather then using the actual java script stack trace. IE.. you might be able to create a single base class for all of your classes that you compile. With maybe an annotation or something. Then have your build script extend all of your classes pre compile so they are transparent to the dev, but included with the compiled cache file. You could have your base class grab the class name and or method name or something. and manage it with a simple stack that you can pop.
Lately I've been using a lot of JUnit tests which have the predefined names for methods I will need to implement in my code. I find the "Create method 'x'" tool very useful but I was wondering if there was a tool that creates all the undefined methods, would anyone happen to know? This really isn't a huge problem but it would be very convenient for me to just add all of the missing methods at once as opposed to one by one.
I'm afraid that is not possible. Eclipse is able to generate all methods which you need to implement an interface, but you do not seem to have an interface here. If I understand your scenario right, you get Unit-Tests which do not compile because your class does not provide the tested methods yet.
When the class exists already, then Eclipse should suggest you to create a method with the needed signature. That is what you probably mean with "one by one".
In your case the fastest way is:
create the class
go into your unit test
jump through all non-compiling methods using command + . and create the methods using auto-suggest
I'm posting this on behalf of the 30 or so projects that seem to be suffering from this problem without any resolution.
Basically the problem boils down to, a subclass of org.eclipse.jdt.internal.ui.wizards.NewElementWizard (which is the "Wizard" that controls the creation of new JDT elements like projects, packages, classes, etc -- this problem seems to happen no matter what reason you're subclassing for) overloads performFinish() and calls super.performFinish() as part of that call. So far so good, but for some reason if this happens on an empty workspace (which is often the case for new projects), the super.performFinish() call fails with an exception similar to the following:
java.lang.reflect.InvocationTargetException
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:350)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:851)
at org.eclipse.jdt.internal.ui.wizards.NewElementWizard.performFinish(NewElementWizard.java:133)
at com.canoo.wizard.newproject.NewULCProjectWizard.performFinish(NewULCProjectWizard.java:118)
at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:680)
at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:355)
at org.eclipse.jface.dialogs.Dialog$3.widgetSelected(Dialog.java:660)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
or something similar to that -- the error is strikingly similar across dozens of different projects that I've found in the process of Google'ing about for this error, whether the subclass of the NewItemWizard happens to be a Project Wizard, a Class Wizard, whatever.
Some of the people reporting this problem later post that it was caused by a "version mismatch" but, maddeningly, they never give any details as to what versions were mistmatching with what -- and I've tried my code on Linux, Windows, and OS X so I doubt it's some very version-or-platform-specific nuance.
Lastly, there does not seem to be anything in the Eclipse bugzilla even tangentially related to this problem.
Has anyone run into this before, since it seems so ubiquitous? Any help would be greatly appreciated!
InvocationTargetException is a checked exception that wraps an exception thrown by an invoked method or constructor
Every case I have found report some kind of incompatibility between Eclipse and a module:
VE (Visual Editor) with this thread, or that one, or this GTK64 SWT issue.
bug 161621 (enum is a Keyword for Java5 and cannot be used as a Enum name), where the NewElement Wizard didn't reject enum as a class name on a 1.5 project.
In other words, this kind of exception is often the symptom of another issue.
The enum issue is a good example of such an incompatibility, but each time it can be a different problem related to the specific operations or configurations of the project.