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.
Related
Hi I am interested in understanding how eclipse autocomplete works. I want to understand how eclipse distinguishes between local and global variables in a piece of Java code. I would also like to understand how eclipse stores method signatures for an infinite number of classes and how it associates a method to a given class. And is it possible for one person to develop an autocomplete feature for a language like JavaScript.
There is already an AutoComplete feature for Javascript. You just need to let Eclipse install the appropriate extensions.
Eclipse maintains a model of your program, including the project and all the dependencies. It's big, but it's not infinite. When you hit the dot, it figures out based on the variable type what the target type can be, and then displays the relevant methods based on its internal model.
This is easy for Java because you can usually know the static type. Much harder in other languages.
The Eclipse plug-in developer's guide discusses how different things, including the internal model and auto completion works. There are extension points to implement yiur own.
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
Ie. I have a GUI package, and a Logic package.
How can I prevent the Logic classes from importing GUI classes? Others(or myself) working on the same project might do that, which I want to prevent.
A solution could for example be a check in JUnit, that fails if its done, or a runtime check that throws an exception. Something along these lines, but how to do it?
You can write such a test using JDepend or DependencyFinder or Degraph.
Degraph is the only of the three tools that explicitly is intended to actually write tests for cases like this. Also AFAIK JDepend does not find all dependencies in more recent Java Versions (like classes mentioned in Annotations).
I'm the author of Degraph so I'm obivously biased.
I created the JabSaw project. It allows you to define modules by using annotated classes and to express the relationships between the modules. By default, a module contains all classes in a single package.The restrictions can be checked using a Maven plugin, from the command line or from a unit test. This should solve your problem.
One solution which comes to my mind is make GUI classes package private. Although you cannot isolate only one package and say, only Logic classes cannot use GUI, but other can.
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.