Where can I find the midpapi20.jar source files?
I started J2ME applications development using eclipse and I'm not able to view the javadoc of the classes. I tried with NetBeans and it asks me to attach sources for midpapi20.jar but I can't find them.
It's very annoying not being able to find such informations on google, I couldn't find anything.
Use (if the licence attached to midpapi20.jar permits you) jd-gui.exe which is a java decompiler. This will yield a good approximation to the original source files although enums, string switches and <> will be messed up.
Related
I can not prove to the management the futility and even harm of saving IDE specific files and folders in GitHub
There is even a problem in the deliberate mixing of two different issues:
I want to use Eclipse;
If we use Eclipse, then its files should be stored in the repository;
I tried everything:
from "files not related to the project should not be there"
to "every developer knows how to configure their IDE for the project based on the pom.xml"
and "if two programmers use two different IDEs, should their files also be saved?"
and so on... like "specially designed gitignore.io provides recommended gitignore based on what you are using."
What arguments can be given besides “no one does that for a long time because it's obvious”.
PS. I am not going to start another holy war, I need arguments that are clear to the management.
The rule is not do not share IDE-specific files, but as long as tool-specific files are maintained, they should be shared, even if they are not used by everyone.
This applies to specific files of GitHub, Jenkins, FindBugs/SpotBugs, Eclipse and other tools. The presence of these files does not harm (files and folders starting with a dot meant to be hidden). This is well documented (e.g. here for Eclipse) and after all, the tools do not place these files in the project directory for no reason, although it would be possible otherwise, but because they are meant to be shared.
However, there are still people who believe that there should be one Maven-specific pom.xml file only, which is focused on building only. But since none of them is a tool developer and none of them has never convinced the tool developers, it is very unlikely that you will convince your management.
Also be aware that Eclipse-specific files are not specific to the Eclipse IDE, as they are also used by e.g. VS Code. Eclipse-specific are not even IDE-specific, since, for example, the Eclipse compiler for Java (ecj) can be used as a linter inside a build to run on a server.
I am looking for a easier way to manage my eclipse code snippets. I know and have used Eclipse's template and snippets features. But as far as I have found, they can only be exported and imported as XML files.
Since I use many versions of eclipse and I keep migrating between machines managing the snippets is a hassle. I am looking for a UltiSnips like method to manage these snippets/templates. Is there one?
I also looked at snip2code, but it didn't appeal to me because I sometime work offline. Also, I want to have much greater control over the snippets using version control.
Oh well! I couldn't find anything that matched the set of requirements I had. So, I've ended up creating my own.
There are quite a few questions with similar titles, but please read on as this is subtly different and I've not yet been able to find a solution in the many answers given to those other questions.
Scenario:
I have an external JAR file with a separate HTML tree javadoc. I have pointed Eclipse at the javadoc by completing the JAR's "Javadoc Location" in the build path dialogue. The source is not available to Eclipse.
At first it looks like this is working fine. If I hover over a class name (say, Wibble) the corresponding javadoc text pops up.
However, if I hover over a method (say the word create in blah = Wibble.create();), I get the pop-up "...the Javadoc could not be found..." which is confusing as it's just shown me the javadoc for the Wibble class.
Indeed, if I click on the icon within the pop-up to "Open Attached Javadoc in a Browser" it correctly opens the HTML and presents me with the text for the method that it just said it could not find!
Technical notes:
My Eclipse version is Android Developer Tools, Build: v22.2.1, though this was happening on vanilla Eclipse before I updated to the ADT version.
The javadoc is being generated by command line using the Doclava doclet.
Any suggestions about either what might be wrong in the javadoc, or in eclipse settings, or...?
EDIT In the course of subsequent experimentation I've found that this problem only occurs with a combination of Eclipse and javadoc generated by Doclava. My pragmatic solution has been to generate the javadoc twice - once for human readability by using Doclava, and once for Eclipse readability using vanilla Javadoc.
If anyone knows these systems in depth I'd still love to know why.
(In order to not leave this 'unanswered' now that I have a solution)
In the course of subsequent experimentation I've found that this problem only occurs with a combination of Eclipse and javadoc generated by Doclava. My pragmatic solution has been to generate the javadoc twice - once for human readability by using Doclava, and once for Eclipse readability using vanilla Javadoc.
If anyone knows these systems in depth I'd still love to know why.
is there a code visualization plugin for eclipse?
http://marketplace.eclipse.org/content/code-rocket-eclipse
it's too expensive however so is there a open source version?
ModelGoon is probably the most promising open source project for code visualization based on Eclipse JDT. GreenUML may also be of interest, but it doesn't seem too active. I even had to patch a few things to get it working properly in my case (see my github fork).
If you want visualization based on runtime capture of program execution you may want to see this answer to a related question.
Finally you may want to explore the Source Code Analyzer category on Eclipse marketplace, the listing is a bit broader in scope and includes both proprietary and open source solutions.
I'm evaluating the possibility of developing an Eclipse plugin to modify the source code of some Java files.
The Eclipse plugin should:
add one menu option or context menu option to launch the modification process.
add a key binding
only alter the UI in that way when an editor has been open on a Java file.
the modification process would not open a dialog, or maybe, a very simple one.
the modification process would traverse the AST of the Java file and would modify it.
Considering that we have no experience with Eclipse plugins and we need spend time in reading docs, how much time do you estimate in developing that plugin?
Thanks in advance.
It's really not that difficult at all... I had students in my design patterns class doing it for an assignment (adding/removing javabean getters and setters)
See http://help.eclipse.org/ganymede/topic/org.eclipse.jdt.doc.isv/guide/jdt_api_manip.htm
[EDIT: added the following article reference]
And a great article on it at http://www.eclipse.org/articles/article.php?file=Article-JavaCodeManipulation_AST/index.html (from 2006 -- there may be a few API changes since)
Yes, writing plugins takes a little getting used to, but so does any API.
And you can modify the AST -- see the page I reference above.
(I should note that the above link is from the eclipse help, which can also be accessed via Help->Help Contents inside Eclipse -- there's a lot of good info in there, but it's just a starting point)
You'll probably spend quite some time cursing the complexity of the eclipse plugin system. There are some example plugin development projects that can be very helpful if they cover the area you're working in.
I'd say you're looking at 2-4 days of work, spent mainly getting familiar with the platform - someone with a lot of experience writing eclipse plugins would probably take no more than an hour.
However, your step 5 could be tricky. I don't know how easy it is to access and change the Java AST; my experience is based on developing an editor plugin for an exotic file format rather than Java code.
Well, the four first points are easy to achieve, even by monkey coders that look at the eclipse PDE documentation shipped with Eclipse. These can be achieve in 1 day of work, maybe 2.
The hardest point is really the fifth one and the kind of modification you expect to do. Acting directly on the editor content is simple, accessing the editor internal AST and modifying it is really a bigger challenge and I doubt that it could be achieve in less than a week by unexperimented people (it can take longer, depending of what kind of modification you want to apply).