Is there a way to change the icons for symbols suchs the C for classes and the M methods. They're a little hard to distinguish on my laptop. Ideally I'd like to change it throughout the IDE but fine if it's just for the project pane or auto complete.
The icons can't be changed via the UI as far as I know. It is however possible to change them manually. All icons used by IntelliJ are located in $IDEA_HOME/lib/icons.jar, where $IDEA_HOME represents the IntelliJ installation directory.
It might be possible to modify content of this JAR (by unzipping it, changing the icons and creating JAR from it again) and replace the original icons.jar with it. But change such as this will probably be overwritten during IntelliJ upgrade.
One solution would be to package the icons into a plugin. There is a Idea 11 Icon Pack plugin which does exactly the same thing you want. It is a JAR with the same structure as the icons.jar. Except two things:
It has plugin descriptor (META-INF/plugin.xml) in order for the JAR to be registered as plugin
It has implementation class com/bulenkov/idea/Idea11IconPack in order to register the icons I guess
I would use this as an inspiration. You can modify the descriptor so that there are no clashes in plugins, and change all of the old icons for your modified ones. One thing I'm not sure about is the implementation class. You could keep it and it might work. Or you could decompile it to see what it does and create your own version.
You can then install the JAR with the plugin descriptor by clicking Install plugin from disk button in the plugin settings.
Here is also a documentation for plugin development which might be useful.
Related
I am a java beginner, the first java IDE I downloaded was Visual Studio Code, it was very easy to use and everything is auto configured. But it kind overheats my laptop all the time, so I want to try IDEA, so far it's a very good experience, except when I open a java file and tried to run it in IDEA, it always pops out this run configuration window and I don't understand how to configure it. In visual Studio Code I can open any java file any time and run without any issues, but now I have to go through creating projects every time. Is there any solution for this?
From how the file icon looks:
your file is not recognized as the part of the sources of your project. Check the project settings to ensure that source directories are correctly set.
I'd also recommend you to look up and follow the conventions for the directory structure of java projects.
Once you've fixed the problem with sources, you'll see "run" icon next to your class, main method, or when you're right clicking the file.
Command-line
To run a single file, there is no need for an IDE.
In Java 11 and later, the java tool at the command-line can both compile and execute a single-file Java class. See JEP 330: Launch Single-File Source-Code Programs.
If your class named HelloWorld were in a file named HelloWorld.java, on a console type:
java HelloWorld.java
To be clear: The java command-line tool really only executes Java apps, while the javac command-line tool compiles Java source code. As a convenience, the java tool was enhanced to effectively call javac on your behalf for a single-file.
JShell
If you just want to run a few lines of Java, try JShell, the REPL tool bundled with Java 9 and later.
See:
Java Shell User’s Guide by Oracle
JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
Search to learn more and find tutorials.
BlueJ
Using an IDE such as IntelliJ, NetBeans, or Eclipse can be a daunting task for the new student of Java. Those IDEs are heavy-duty tools designed for professional programmers.
I recommend using an IDE designed for beginners. BlueJ comes to mind, designed specifically for educational purposes. BlueJ makes getting started with Java easier.
If you insist on using IntelliJ, read on.
If using IntelliJ, define a project
IntelliJ is not designed to work with single files. IntelliJ expects you to work within a project.
I strongly recommend learning the basics of Maven to create and drive your new project. By defining your project in Maven, the configuration is independent of any one IDE. You can move your project between major IDEs such as IntelliJ, NetBeans, and Eclipse.
Maven is also very useful for downloading needed libraries ("dependencies") that you may want to leverage in your work. And Maven is good at packaging your Java app as a JAR (or WAR or EAR).
In IntelliJ, choose "New Project". In the New Project window, click the Maven item on left. Check the Create from archetype box. Scroll the list to find item for org.apache.maven.archetypes:maven-archetype-quickstart. Under that, choose the "RELEASE" item. Click Next button.
In Name field, enter something like MyFirstProject. Click Next button.
On the Maven settings page, just click Finish.
Wait a moment for IntelliJ to download some stuff and configure your project. Eventually you should see a BUILD SUCCESS message in the Run pane.
You will also see a pom.xml file displayed. The POM contains your settings for Maven to run your project, in XML format.
Change the <maven.compiler.source> and <maven.compiler.target> elements to the version of Java you are using. The current version is Java 17.
After editing the pom.xml, look for a little floating windoid with a tiny Maven icon. Click the icon to have Maven process your changed POM. Wait a moment.
In the Project pane, navigate to the App file. There you see code to print “Hello World!”. Let's run that code now. Click the green triangle button on the left, in the gutter, next to the main method line. A pop-up menu appears offering a Run item. Choose that item to run the app immediately.
Down in the Run pane, you should see the results, the Hello World! text.
At this point you can add your single file to the org.example package seen in the Project pane.
By the way, you can change that package name by context-clicking and choosing Refactor > Rename….
Later, learn to use the Run/debug configurations feature of IntelliJ.
Know that you need not create a new project for each time you want to do a little experiment. Create one project for such experiments. Keep adding new .java class files for each experiment. Delete old class files you no longer need.
Eventually, I suggest updating the versions of various items in your POM. The QuickStart archetype is not configured for the latest versions (for reasons I cannot fathom).
And when you learn about unit testing, replace JUnit 4 in the POM with JUnit Jupiter (Aggregator) to use JUnit 5. One of the benefits of using Maven is that you can easily switch out dependencies such as going from JUnit 4 to JUnit 5.
The IDE needs to know what's called the entry point of the program, i.e. where to start running your code. That's what the "Edit Configuration" window is wanting you to do.
If your file "Lab3.java" is in a package, make sure to fully specify that in the field you have in red. Otherwise without knowing how your project is structured (as the other answer alludes to), it's difficult to pinpoint what we're missing here.
When you create your IntelliJ project, add a directory /src right at the root of your project. Right click on that folder and tell IntelliJ that you wish to mark it as a source root. The directory should turn blue in color.
Put your packages under /src. IntelliJ will know that those are Java files.
When you want to run a class with a main method, choose Run->Edit Configurations. Tell IntelliJ that you want to add an Application. It should prompt you with the classes that have main methods in them. You'll have no trouble running them.
Use Maven or Graddle. Make sure the project is configured with the build tool enabled and integrated, it will do basic things automatically. If you are not sure, please create a new project and add your files in. Steps:
Open the IDE
New Project
Choose from the left side bar "Maven" or "Graddle"
Give it a name and the location in your machine.
Click Finish
Now you have the project ready. You need the appropriate method to run in java. A main class. In IntelliJ you can just type "main" and the auto-complete will add it for you, make sure you inside the curly brackets of the class {}. More info about the main class. You seem to have this nailed down.
Lastly make sure you have a JDK installed in the IDE. I am pretty sure this is your issue here, make sure to use one of the option IntelliJ provides. A full guide from the developers is here and should satisfy your needs. I would suggest OpenJDK for a beginner, because that served me well at the beginning, at the end of the day its your choice.
I'm trying to figure out which files to check in to version control when using Eclipse for Android development. I have a workspace with a single project. I found this which suggested that the .metadata folder did not need to be controlled (minus the comment there about launch params, however I don't mind re-picking those again on a different machine).
If I remove the .metadata folder then open Eclipse the project is no longer shown. I searched for posts on this symptom and they suggest re-importing the project. This solution doesn't make sense here, I'm trying to check in whatever is needed so another developer can open the workspace and see the project and work on it. Having them move the project then re-import it would be a bit messy.
So which files should I be version controlling so that someone else can get the latest and be able to open the project without controlling a bunch of user specific preferences?
I have had similar experience using Eclipse for version control, and decided to quit using it because it is very annoying and buggy. Now, for git, I use SourceTree, which I prefer over eclipse version control. I think you should version control the source code folders, along with configurations, and other files you program needs to function, but never the executable files. If the other person is using Eclipse, for easiness, it is good idea to include the .classpath configuration file. If not, then the other person would need to clone the repository and make the required changes so that it works with his/her IDE.
I think I've settled on the following approach. This seems to work well so far and avoids some of the headaches mentioned in my original question.
1) each developer creates an Eclipse workspace on their machine somewhere, outside of version control; only the project directory is checked into version control - the workspace is completely uncontrolled
2) developers checkout the project directory from version control (in a different directory structure than where the workspace was created) and then use File >> Import, but they leave the "copy into workspace" unchecked.
So with the above, you can checkout from version control and work with the files right where they were checked out. There's no need to move them out then import them back in. When you import with the copy option unchecked, the workspace (which itself is not controlled) is just referencing the files where they're at on disk.
The only minor downside is that any workspace stuff has to be setup individually. Other articles mention controlling the launch params, but so far this hasn't been an issue - pretty easy to pick that once the first time you launch.
So anyway, hopefully this helps someone else :) This seems to be a reasonably smooth way to do it and avoids the issues we ran into initially.
I have opened my project today and I noticed some weird icons beside my classes as in this image :
I don't know what that means !
when I run my application it works great, and I get no exception.
how can I resolve this issue
If you're using a Source Code repository like SVN or CVS (you might have checked out this project out of some code repository) your recent changes must have made your local workspace go out of sync.
By using different colour codes and icons, Netbeans is simply trying to inform you which of these files are in conflict with the repository and need to be merged.
Some of the other icons could simply be informative like that "play" sign on your .java files indicates that the file contains a main() method and can be executed.
You should not be scared at all, the IDE marks the different file types with different icons. Most of the IDEs have similar functionality.
I'm having two nb-projects.
One nb-project(a) has the other nb-project(b) as a library dependancy.
Now both nb projects compile/build fine, but the hints for (a) are out of sync.
This interferes when i want to run/debug saying 'one or more projects were compiled with errors'
I've tried
opening/closing both projects and recompiling
scan for external changes'
clean-build, removing the 'compile on save' flags for both projects etc.
en/disabling 'Build Jar after compiling' for the jtools project.
Removing the :
./netbeans/6.8/var/index
directory only made things worse for the nb-project(a)..
Now exclamation marks for all imports of packages from nb-project(b)
But still compile/build worked fine.
Even unit-tests within the same netbeans project in(b) didn't even recognize the root-package ?!
After some strugling its a bit better, but hints are still not correct in (a).
Now in (a) it says one method doesn't exist in project(b), but i've looked it up in the build-jar of (b).. it's there !?
Any ideas how to get the hints back on track?
Thanks
I've seen something like this when I upgrade a library but neglect to remove an earlier incompatible version from a path visible to NetBeans. Older JARs carelessly left in an extension directory are particularly troublesome, especially if they alias new entries you've added elsewhere. Also, review the Tools > Libraries dialog entries for duplicates and errors. Finally, check each project to be sure it's using the required libraries.
There are three ways to create dependencies in NB. You can add a project, add a library, or add a jar/folder. Only the "Add Project" button tells NB that the dependency is mutable. The other choices (Library and Jar/Folder) expect the jar will never change.
Try deleting the dependency on project(b), then add it back using the Add Project button.
I only use the Add Library for stable, third-party libraries (apache commons for example). I only use the Add Jar/Folder for third parties libraries I know I won't use anywhere else. Such as vendor libraries for communicating with a particular device.
I'd like to set up eclipse with a bunch of plugins and DB connection configurations, etc and re-zip it up so my team-mates and new starters can all be working on the same platform easily.
It seems that installing plugins is fine, but when I add in custom jars (e.g. ivy2, ojdbc, etc) they all save with full, absolute paths which probably dont exist on others machines (particularly if they unzip in a different location to me).
Anyway, I'm hoping that this idea is not silly and am working if this sort of process is documented somewhere or if anyone has any tips in general.
Thanks,
I would recommend against requiring all developers to place eclipse in the same location. There are times when some developers may want to try an alternate version of eclipse to explore a technology that requires a different set of plugins or a different eclipse base version.
Let developers install eclipse where they would like.
However, for jars that you need to run plugins (external dependencies that you need to configure for proper plugin usage):
Hardwire a directory for those jars (as opposed to the entire eclipse dir), like c:\eclipse-helpers or something.
To deal with third-party library dependencies (in the code you're developing), you have a few good choices:
Create project(s) to hold the third-party libs and check them into your source version control system (which you are using, right?). You can then add the libs to the build path(s) of the project(s) - make sure you mark them for export in the "order and export" tab of the build path page. You can then simply add these third-party projects as project dependencies.
Reference the third-party jars as CLASSPATH variables when adding them to the build path of your projects. This allows other developers to store the dependencies in different locations. Perhaps define a CLASSPATH variable (in eclipse's Window->Preferences->Java->Build Path->Classpath Variables) called THIRD_PARTY_JARS; each developer can map it to a different path where they want to hold their deps.
Reference the third-party jars as a "user library" (Window->Preferences->Java->Build Path->User library). This is similar to classpath variables, but acts as an explicit set of jars.
Include the third-party jars directly in your projects. Use this option only if you need the deps in a single location.
Although not exactly in line with the direction of the question, you could use Yoxos OnDemand. It allows you to "roll-your-own" Eclipse distro and download it as a zip. They add in their own perspective where you can add more plugins (direct from their repo), or update the plugins that you have.
Although I've never used the feature, you can make make your own stacks and name them, allowing anyone to go to the site later and download it (with the most up-to-date versions of the plugins). Also, dependencies for plugins are resolved automatically if need be.
In eclipse - in many places it's possible to use workspace relative paths or system environment infos to reference external files, too.
Another option could be to place your jars into a workspace project so that every team member can check it out from cvs/subversion/whatever and start working. Working like this ensures a reproducible environment for server builds or for desktops even after years.
Talking about Yoxos...
it provides "Workspace Provisioning" as well. This means you can attach Eclipse Preferences, checkstyle configurations and Mylyn setups additionally to your list of needed tools/plugins for your IDE to your yoxos profile.
This means your team could share a profile and would be able to start working with the same setup regardless of their OS or whatever. (Its possible to use multiple profiles at once, too.)
We did a similar thing with our development environment (it needed both Eclipse and our own plug-in which, in the early stages, had to run in a known location).
We just put it in c:\eclipse_<projName> and made that a requirement for the team. That's probably the easiest solution for you.
It's your team, you can dictate this as a requirement. Unless your team members are absolute idiots, they'll work with you.
I found Yoxos really good and it does very good work in determining dependencies.
Its really a good tool and worth giving a look.
I just started using git to manage my eclipse install. I did a write-up. The approach might work for you, and it's probably worth looking at.
If developers all don't have the same paths on their machine, instead of adding independent JAR files you could create what Eclipse calls a "library" and include a bunch of jars in that. Then another developer just has to change the location of the library and it'll pick up all the jars in there.