We are using Eclipse for our projects and we would like to revision control the JDK we use. (Different projects need to use different JDKs). Instead of configuring everyone's system to have the same JDK with the same names in Eclipse, we would like to include the JDK as part of our project in our source control tool and have the project point to the JDK that is part of the project.
We can't figure out how to tell Eclipse to use the JDK that is found in the project. It keeps wanting an absolute path to the JDK. Is it possible to use the JDK that is part of a project and use a path that is relative to the project?
Is it possible to use the JDK that is part of a project and use a path
that is relative to the project?
Straight answer: NO
You're asking to go around the basic abstraction that Eclipse provides between installed runtime environments (which are defined at the workspace level) and the project's compiler configuration (which is defined at the project level). If you want to use all the JDT features in Eclipse, you just have to live with configuring the installed JREs on each workspace of each of your developers.
However, I can think of a probably not-so-standard-way (I see the -1's coming for saying this, which is crazy!) to achieve what you want: to distribute the .metadata folder of a pre-configured workspace you've already set up with all your JRE's so you don't have to go on each machine and do the installation. This would also include committing the .settings folder and the .project .classpath files of each project. Want to include the JDKs? Well, you could put each of them in the SCM as individual projects and ask each developer to import and configure them. If you did this on your template workspace before distributing it, then it will have not only the JDK's but also the .metadata pointing to them.
What could go wrong with this? probably everything.
How do the pro's do it? Maven and the maven-compiler-plugin (and not committing any IDE specific files). This leaves developers free to choose any IDE they want, and most of them support automatic project configuration from POM files: target JDK, dependencies, etc.
This may not be the approach you are looking for, but one option is to use a drive letter using SUBST for the root directory of your project.
Having the same path to project on all development machines has many advantages. This strategy is most useful for developers working on a single codeline but I have successfully used it even with multiple codelines on my machine, changing the subst as necessary.
You can configure the JDK version in Eclipse. Right click your project, select properties, goto Java Compiler and there you can select a project specific version of Java for your project.
One approach would be to install all the JDKs on all the machines and use JAVA_HOME/PATH variables to point the appropriate JDK installation as required. You can write a simple batch file to take care of environment variable setting by just a simple double click.
No, that is not possible.
Either use Maven to just declare all your dependencies, including the SDK to be used. Or use Yoxos or Secure Delivery Center to centrally define Eclipse configurations, which are then deployed to your developers desk on starting Eclipse.
You're checking in the entire JDK? That seems likely to slow down your SCM quite a bit as it has to try and track a lot of large binaries, which won't diff well. Why not use a tool like Maven that declaratively states what JRE version to use?
Related
Out of pure curiosity, I want to browse Java sources in Eclipse in order to benefit the ease of navigation and search.
When I import sources into a newly created project, I encounter thousands of errors, how do I correct these errors ?
The sources of the JDK are located in JDK_HOME/src.zip
Unzip this archive in the folder of your choice.
Create a new Java Project under Eclipse
Import the content of src.zip into your new project. The compiler will raise several errors.
First, you need to add JDK_HOME/lib/tools.jar to your build path. Into project properties, go to Build Path, libraries and add external Jar.
Second, you need to give access to normally restricted classes from the JDK. From the libraries pane, click the JRE system library and select Access rules. Set the resolution to accessible for the rule pattern */**. This gives access to all the classes in the JRE jars.
Finally, there are two classes that have been reported missing since JDK7 that you have to import manually. There are various solutions , the fastest for me is to download from OpenJDK repositories :
sun.awt.UNIXToolkit.java
sun.font.FontConfigManager.java
Enjoy browsing Java sources !
There is no reason to import the JDK sources as a project in Eclipse or try to compile them. If you have Eclipse pointed to a JDK (as opposed to a JRE), it will automatically pick up the src.zip that it finds there and show source when you browse to JDK classes.
Package Explorer, Project Explorer, Java Browsing, and other Java-oriented views show the packages and classes just as they were any other library/JAR. In Package Explorer they show up under JRE System Library.
In Java Browsing perspective, it looks like any other packages:
How do I stop maven from constantly updating my Java System Library from JDK 1.8 back to Java SE 1.8? I have configured the build path and I even set my Java_Home Variable to the JDK path. I have also have updated the build configuration. Can someone please specify how to do this with some specific instructions as I am a novice. I also noticed this keeps changing back as well. FYI I am using Eclipse Mars if that matters.
In Regards to the comments below I have shared the Eclipse M2e Plugin screenshot. Even when selected I am not able to proceed to next. I also have shown what's already installed just in case another plugin is hindering me from using the m2e
You need to understand what an Execution Environment (EE) is in Eclipse. The concept of EE is an abstraction over JREs, allowing projects to be configured without absolute paths to JRE locations. From the wiki page:
Execution environments (EEs) are symbolic representations of JREs. For example, rather than talking about a specific JRE, with a specific name at a specific location on your disk, you can talk about the J2SE-1.4 execution environment. The system can then be configured to use a specific JRE to implement that execution environment.
In general, it's not advisable to configure a project to use "Workspace default" as its JRE System Library, because that makes the project inconsistent when loaded into different workspaces. Think about this: what if the project is being developed targeting Java 7, but I pull it into my workspace which has JDK 8; that could be a big problem. By using an EE, the project is configured such that it doesn't know (or care) where I actually have a matching JRE on my system.
I said all that to set up the answer for you, so you understand what Maven is doing and these instructions are doing. m2e, the Maven integration plugin for Eclipse, is (rightly) setting the project configuration to use an EE instead of "workspace default". From your screen shot I can see that you have both JDK and JRE 1.8 set up in your workspace, so ideally you should remove one (the JRE). Got to Preferences > Java > Installed JREs. There you'll see both the JRE and JDK listed. I suggest removing the JRE*.
Then go into the "Execution Environments" preferences section, select JavaSE-1.8 and make sure that your JDK is checked as the default implementation.
Now when m2e configures your projects to use an EE, that EE will be pointing to the JDK you have installed. And if someone else imports the project, it will point to wherever they have a matching JDK installed.
*By the way, it's perfectly acceptable and normal to have different versions of Java there; I often work on different projects that target different Java versions.
Right now I'm trying to get Java3D to work with JDK 1.8.0 in Eclipse on OS X. I've tried following this tutorial (among many others) and am finding varying levels of no success. I believe part of the problem is that there are currently 3 separate locations with the Java3D .jars are ending up on the build path:
/Library/Java/Extensions/ as a part of the JRE system library
/System/Library/Java/Extensions/ as a part of the JRE system library
My personal libraries folder as external included .jar files
Earlier in project development, I hadn't updated the files in the Library folders (they were whatever came with the Mac), and in that case there were no Eclipse errors, but the project could not be run (UnsatisfiedLinkError: no j3dcore-ogl in java.library.path)
Now that I've updated both of the JRE system library .jar files, the code has errors: Access restriction: The type '...' is not API (restriction on required library '/Library/Java/Extensions/j3dcore.jar')
What's the proper way to clean up all these locations so that the project only references one set of these .jars, and where should these .jar's be?
There is only one way to clean up: uninstall all those obsolete versions of Java3D provided by Apple ("whatever came with the Mac") and follow my instructions.
The extension mechanism has been removed from Java 1.9, relying on it is a very bad idea. Only use a carefully chosen "personal libraries folder" whose scope affects only your application and not the rest of the operating system.
If you need some help on Java3D, rather use its official forum.
I have a code written in java. when i load it in eclipse it shows an error in the java code import line " The import com.sun.java.browser.plugin2 cannot be resolved"
import com.sun.java.browser.plugin2.*;
How can i fix this error..??
It's possible that it's to do with the version of Java you're building your project with, since the new applet class files were only introduced in Java 1.6 / 6.0. So, right click on your project on the left, go to Properties, Java Build Path, Libraries tab, and scroll down the list until you see JRE System Library. Note the version. If it reads less than 6.0 / 1.6, you're using an old version.
Click on JRE System Library, click Remove (make sure you have at least Java 1.6 installed!) then click Add Library. Select JRE System Library and select your Java version. If this isn't listed, go to Window > Preferences, Java > Installed JREs, click Add, and locate your JRE. Then repeat the same process and it should work.
(Edit: ignore what I said, the com.sun.* classes are hidden from the user. I don't think you can use it)
As far as I know, packages com.sun.* are implementation details of certain jvm and must not be used by application developers. They can be slightly different even between minor versions of jvm. Difference between major versions or jvms of different vendors can be sufficient. So IBM's and Sun's jvms have different structure of those packages. Only packages java.* and javax.* and org.* should be used. To fix this error correctly you must not use this package. To hack it around, you can try configure eclipse to use appropriate jvm though I don't know how to do it.
Update:
There's a FAQ entry about those packages. Thanks to R. Bemrose.
Did you type this in? Then the build path in incorrect. If not no sure what is going on.
Are you sure you are using the right JRE for your project? Like Java6?
See also JRE settings, and then make sure your project uses a Java6 JRE.
You have to add the plugin to the MANIFEST.MF dependency entry
Open MANIFEST.MF
Got to tab Dependencies
Add the plugin your referenced class is placed
You also have to be sure, that the package, the called class is lying, is added in the "Runtime" tab of the MANIFEST file.
EDIT:
The MANIFEST file you can find in the /META-INF directory
I would like to have both Eclipse and Netbeans (with JUnit) installed on one system, so I can be somewhat familiar with both.
Besides GUI development (see "Using both Eclipse and Netbeans"), are there any other issues with using both IDEs on the same system, or even the same project?
We regularly use both Netbeans and Eclipse. We switch back and forth, between Vista, WinXP, and multiple versions of Fedora of the 32- and 64-bit variety, with no problems. Keeping the project files in version control makes keeping them in sync much easier. We even keep the launch files in the project directory as well. I posted a answer to another multiple IDEs question that describes what our project directory looks like.
Basically, I agree with Bill the Lizard about there being no issues, but disagree about the seamless nature and keeping the project files separate. The only thing we have to do is make sure that we update the build classpath in each project if a new library is added because Netbeans and Eclipse use different files to describe the classpath.
Using the IDE version control system integrations helps to encourage keeping the projects up to date for everyone else.
One thing that makes developing single project in NetBeans and Eclipse is using maven to keep dependencies together. Maven will generate IDE specific files that contain all classpath information, buildpaths etc.
Maven has pretty steep learning curve, but it is worth learning.
There are no issues at all with having them on the same system. However, each have their own project specific files, so using them on the same project isn't seamless. This is made a lot easier if you're using source control and keep your (non-source code) project files separate.
Maven is a very good way to keep both IDEs in sync (as suggested). In my experience though, you have to create an Ant build for any given project for the sake of developers not using IDEs. Since NetBeans's build system is based on Ant, it's pretty trivial to just base the entire NetBeans project off of that base build system. A little bit of tweaking in the project.xml ensures that the editor classpath is kept in sync with the Ant build classpath.
Netbeans 6.5 has an improved Eclipse project import which is supposed to sync changes from Netbeans back to Eclipse: http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization