In my Eclipse Plugin I have a table that shows Integer and String values. To edit the String values I'm using a TextCellEditor which is in the package org.eclipse.jface.viewers.
I have found a NumberCellEditor which I want to try. It is in the package org.eclipse.ve.internal.propertysheet.NumberCellEditor.
I cannot see this package in eclipse it is not listed in the plugin.xml file under Dependencies. It's not in the list that shows up when clicking the "Add"-Button either.
How can I use this class?
org.eclipse.ve appears to be the old Eclipse Visual Editor plugin which is no longer available.
Additionally classes in a package with internal in the name are off-limits (see Eclipse API Rules of Engagement). They may be changed or removed at any time.
Related
When trying to write a class that extends I get the error message:
The hierarchy of the type 'MYEditor' is inconsistent.
import org.eclipse.cdt.internal.ui.editor.CEditor;
public class MYEditor extends CEditor {
}
This answer says:
These errors happened because some interface/class in the hierarchy
cannot be resolved.
This indicates that eclipse cannot find a class in the hierarchy. But when I use the class in my plugin.xml, it works. I am using it like this:
<editor
class="org.eclipse.cdt.internal.ui.editor.CEditor"
contributorClass="org.eclipse.cdt.internal.ui.editor.CEditorActionContributor"
default="true"
filenames="*.grasp, *.c"
icon="icons/small.png"
id="de.blub.ide.myeditor"
name="My Editor">
</editor>
This works, but lacks a few features that I need for my plugin. That's why I want to use a class that inherits from CEditor.
This answer didn't work, to (remove and add JRE System Library).
I've also read that the jar file needs to be put in the Classpath section of the plugin.xml. But the "Add" and "New" Buttons don't provide a way to chose an external jar file. I can manually copy that jar file from "~/.p2/pool/plugins" into my projects lib folder, but that didn't help.
Plug-ins reference code in other plug-ins by including the other plug-in in their dependencies list. This is the Require-Bundle entry in the plug-in's MANIFEST.MF.
In the MANIFEST.MF/plugin.xml/build.properties editor you can set the dependencies in the 'Required Plug-ins' section on the 'Dependencies' page.
Do not copy plugin jars, do not put plugin jars in the Java Build Path.
But note that extending internal classes is against the Eclipse API Rules of Engagement. Internal classes may change without warning and may be different in older releases.
The CDT Plug-in Programmer's Guide covers the official APIs for Eclipse CDT.
I am learning Java on Visual Studio Code. I have installed the "Microsoft extension for Java" in it. My basic Java programs runs fine without package declaration. But I would like to package my program. How ?
Earlier I used "IntelliJ IDEA". I used to start a New Project and declare "package com.java.learn". In Visual Studio Code there is no option to create New java Project. There is an option to create Workspace but I still have the same issue.
I have two java class. "Index.java" & "InputHelper.java". Index.java is the main java file. InputHelper is a seperate class which I use in Index.java. I want to make a project and package both ( or more ) files.
Error Message:
The declared package "com.java.learn" does not match the expected package
A package is a path of subdirectories. Say your java sources are in (subdirectory of) a directory src. All sources immediately under src have the "default" package = no package declaration.
In src/com/java/learn (4 nested directories) the package com.java.learn; is expected for java sources.
In your case create a path of 3 directories: com, java, and learn the latter containing your java source.
For the rest, try to follow the coding conventions of java: class names starting with a capital like Index, variable and method names with a small letter.
In fact though Microsoft is often underestimated, I would chose a more mainstream IDE for learning java. IntelliJ IDEA (Community edition) is fine; NetBeans IDE is a clean an nice IDE too; eclipse is used very often - though a bit overdone IMHO.
I faced a similar issue, coming from Eclipse/IDEA background you find it difficult to not have a feature in your java IDE to create a new package.
Although, Joop Eggen's answer is correct that package is a path of subdirectories but you might find it tedious to create subdirectories when the number of sub packages is greater and name of sub packages is long.
You can use the below VSCode extension :
https://github.com/jiangdequan/vscode-java-saber
It is a very handy extension.It provides support for:
New: Java files(annotation/class/interface/enum/package/JSP/HTML)
Generate Getters and Getters
Copy Qualified Name
Sort Project By Name
Run Maven Goals
Generate Docs
You can try this extension.
You can use Java Projects panel to create a new project, package, class.
Also I think there's an issue in VSC 1.63.2, because a new item is created but it's not displayed in project structure until I reload VSC window.
Another option is to put right package declaration on the first line of a class file and use inline 💡light bulb button to move that class to the package it belongs.
P. S. I'm learning Java now so I could be missing something
I am getting this error:
Java : The constructor JSONTokener(InputStreamReader) is undefined
I found the latest version of json and add that library but the problem didn't resolved, which I guess is because it is using another library.
Based on this post I need to find which library contains JSONTokener.How can I do that? None of the libraries' names contains json! I am using eclipse.
This is the import line of my program for this class:
import org.json.*;
To the OP: note also that as well as configuring the list of libraries, jars, folders, etc. in the build path, you may have to manually-adjust their order (using the 'Order and Export' tab).
Apparently, since Android SDK 17, builds generate an automatic class called BuildConfig and add it to my package. http://android-developers.blogspot.com/2012/03/updated-sdk-tools-and-adt-revision-17.html says:
Added a feature that allows you to run some code only in debug mode.
Builds now generate a class called BuildConfig containing a DEBUG
constant that is automatically set according to your build type. You
can check the (BuildConfig.DEBUG) constant in your code to run
debug-only functions such as outputting debug logs.
Since this source file is generated, I can't see how to add JavaDoc comments to it. Is there an easy way to exclude this class from my package documentation? or is there an easy way to add some comments to this class? Since this class is added to my package, I can't simply exclude the package from the docs.
I'm using Eclipse Indigo on Windows and the standard Doclet.
To remove BuildConfig.java, simply untick your project/gen folder in the javadoc export wizard. Note that this also remove the R.java from exported javadoc:
We have a package that ends with exception e.g.
package a.b.c.exception;
Our code base had no issues up till eclipse 3.3, however when we shifted to eclipse 3.4, it started giving errors related to this package:
"The package a.b.c.exception collides with a type"
When I refactor the package name to a.b.c.exceptions, there are no issues. Is this due to a bug in eclipse 3.4 or is there some setting to rectify this behavior?
It's because you have a class named exception (with a lower case "e") in the a.b.c package and a package named a.b.c.exception.
It causes a name collision because if you have the code a.b.c.exception.doSomething(); - does that mean you want to call the static doSomething() method in the a.b.c.exception class? Or does it mean there's a class called a.b.c.exception.doSomething that you're trying to invoke the constructor of?
Stick with the Java naming conventions - packages all lowercase, classes starting with an uppercase and camel-case after - and you'll never see this problem.
==========EDIT==========
This is the only legitimate reason this error should be showing up...
It doesn't have to be in your project directly, it could be in another project or library that your project depends on. This should show you any occurrences of the class anywhere on the build path or your project : Hit the Flashlight looking button in the Eclipse toolbar -> Choose 'Java Search' -> enter a.b.c.exception in search field -> select 'Case sensitive' -> select 'Type' in 'Search For' -> make sure all options are selected for 'Search In'.
Are you using any tools that generate classes? Could they be putting them into the build directory of your project? When you see the error, if you go to the project's build directory, and go down into the a/b/c/ directory do you see a .class file for 'exception'?
Of course Eclipse in general could have a bug (though I'd expect there would be a bug report in Eclipse 3.4 and you'd be able to find more complaints if it was...), your Eclipse install could be broken in some way (Can anyone else open your project in Eclipse 3.4? Could you do a clean Eclipse 3.4 install in another directory? Does the error appear there?), or your project could be messed up in some way (Create a new project with no dependencies other than the JDK, create the a.b.c.exception package in your new project, create a class in your project to import a.b.c.exception.*; and see if the error occurs.).
In Java you can not have a class name that is the same as a package name.
That means the JDT package must have enforced that rule only in 3.4
See bug 63668 for instance.
As Nate comments:
A class named Exception won't prevent you from creating package exception.
Case matters.
Also remember the full name of a class includes the package it's in.
So a.b.SomeClass (class name) is different from x.y.SomeClass (package name).
There would be no name collision here.
The class name and the package name have to match in both case and package to cause this error.
See his more accurate answer.
I encountered a similar problem in a huge code base that I inherited. It turns out that the clash was caused by an partially qualified class name in a JavaDoc link.
To paraphrase, Eclipse was telling me that I had a package/type clash for a.b.c.d. when compiling a.b.c.d.London. Doing a java search on the code for a.b.c.d revealed that Eclipse thought that a JavaDoc comment in a.b.c.Paris was a match. The JavaDoc comment contained {# link d.NewYork}. When I changed the it to read {#link a.b.c.d.NewYork} the compilation error was resolved.
It should also be noted that NewYork was not imported into the Paris class as it only appeared in the JavaDoc comment. This also made it un-resolved in its abbreviated form and clicking on the link in the comment did not work. Making it an absolute reference also makes the JavaDoc link work.
I know this will sound silly, and possibly too simple to be true, but I solved this exact same error message by:
Deleting the entire line of the package name causing the error message.
Saving the .java file(this triggers a new error on the same line stating "The declared package "" does not match the expected package"), which it should do.
Re-typing the original package name onto the same line.
Saving the .java file.
Could not tell you why this worked, but it did, and Eclipse stopped throwing a tantrum on the spot.
Safe typing and speedy coding.
-Goodge
I changed one of the compilation option in eclipse and the problem disappeared.
Under workspace properties:
Java Compiler -> Errors/Warnings ->
Change 'Unused import' from 'Warning' to 'Ignore'.
If you have a class Foo, you cannot have a package that ends with Foo, such as com.my.Foo.
Also if you are using maven style, you have resources in your project under something like src/main/resources
The folders in your resources also have a package style and there, also, you cannot have a folder that contains the name of your class.
you will definitely encounter this problem when developing a Jenkins plugin according to the recommended conventions.
if you follow the Jenkins conventions, and you create a builder in a class named MyBuilder in package x.y then you are also supposed to place your .jelly in a resource folder named x.y.MyBuilder. This will result in the above problem.
However, if you name your resource folder x.y.myBuilder (notice lower case 'm' in myBuilder), unlike the recommended convention, the plugin will still work as you intended