I get this error in my project which I imported from my backup. Before I could run the project without issue in eclipse. I formatted my machine and now when I try to run the application I get this error. what could it be..
I am not using maven and I tried to remove the jars and adding them all back....
One thing that differs from my previous setting is that i was using java sdk 1.6.22 version before now i am using java 1.8
You are missing reference to the JAR file after you formatted your PC.
You put your JAR file again in classpath, and error will go off.
You have lost the reference to the jar.
Here you are two possible solutions:
If you are using Maven, check your pom.xml and then if all it's
correct make an Maven > Update Maven Project.
If you are adding directly the jars to the Buildpath, add again and
the error will dissapear.
Two issues:
There is no sun.utils.LocaleServiceProviderPool, at least not in the packages provided directly by the JDK (at least checked on my machine with JDK8 installed).
Maybe you mean sun.util.locale.provider.LocaleServiceProviderPool?
As stated before, the use of sun.* packages is not encouraged since they are internal API.
Related
I've been trying to set up on JavaFX in VSCode. I added the JavaFX jar files to the referenced libraries and added the following statement to launch.json (obviously with my path to the lib folder):
"vmArgs": "--module-path \"C:/path/to/javafx-sdk-19/lib\" --add-modules javafx.controls,javafx.fxml"
This is exactly what multiple youtube videos and other StackOverflow posts have said to do, but I still keep getting this error.
(I know that I can use Maven or Gradle in VScode but am completely unfamiliar with both and still want to try to make this work.)
Hopefully I didn't miss anything painfully obvious but thank you for any help.
You should download JavaFX for your JDK version.
Uncompress JavaFX.zip and move bin folder to your project.
You should create two classes, one for writing the JavaFX window code and one for running it.
The error can be fixed.
I suggest you learn how to use Maven or Gradle in vscode. It is very important.
At runtime, your app needs access to the JavaFX (OpenJFX) libraries.
Either:
Install a copy of the OpenJFX libraries with your app, as directed in the Answer by RedSnack-BCS.
Replace your Java implementation with one that includes the OpenJFX libraries.
I know of two such implementations of Java (JDKs) that include necessary libraries:
ZuluFX, a special edition of their Zulu product, by Azul Systems.
LibericaFX, a special edition of their Liberica product, by BellSoft.
You may have identified a third approach with the use of passing arguments to the JVM. But I am not familiar with that solution.
I'm writing a plugin for Spigot/Bukkit (Minecraft) in Java and can't figure out how to fix this problem for the life of me. Although I have done a lot of programming in other languages, this is my first attempt at programming in java. I have done many google searches, looked at dozens of pages, but everything just said to do things I have already tried.
I'm using eclipse and have converted my project to and from a maven project trying all sorts of variations of installing the mongo java driver. I've tried:
- Adding dependency/s
- Adding it to the buildpath using project->properties->Java Build Path->Add External Jar
- I've done a combination of both of the above
- I've tried using mongodb-driver, mongodb-driver-core and bson together, and with mongodb-java-driver(which should just work on it's own.)
- I've tried just using mongodb-java-driver
- I've tried using many different versions of the drivers.
It doesn't matter what I do, when I export my plugin to a jar and attempt to run it on my spigot server I get the following error:
java.lang.NoClassDefFoundError: com/mongodb/MongoClientURI
Where MongoClientURI could be replaced by any mongo class I use in my code. Am I not using the driver correctly, am I missing something? What's going on?
So I solved my own problem in the end. Turns out spigot doesn't recognize any jar files other than spigot plugins on execution. Shading would've solved my issue but instead I did this, which also works:
Created a file called MANIFEST.MF within my project directory.
Added the following to the file:
Manifest-Version: 1.0
Class-Path: libs/mongo-java-driver-3.2.2.jar
Created-By: 1.7.0_06 (Oracle Corporation)
Selected "Use existing manifest from workspace" in the final step of exporting my plugin.
This meant that at runtime spigot would include {plugin location}/libs/mongo-java-driver-3.2.2.jar in it's libraries.
I found my solution here:
https://www.spigotmc.org/threads/solved-mongodb-help.35922/
I'm developing an application that should run on a server. The application uses some external jars.
I have build the application and run it on a local machine without a problem.
Now, I need to deploy it on the server. The server has some of the jars located.
What should I do to make my application work on the server, using the jars that are already there?
I don't have much experience with Java, but I understand that there is a manifest file which has a class-path field that points to all the jars needed. Should I change the manifest "manually", so that it points to the location of the jar on the server? What do you do in situations like this, what is the correct procedure?
Also, if I use one version of jar during development, and there is a bit older version of that jar on the server, what should I do to perform the deployment correctly?
And what is the procedure in case of using maven, should I copy the jars from where it locates them on the local drive to one directory, or is there a way for maven to do it itself?
I'm using NetBeans btw.
Thanks
Re "using the jars that are already there":
See Introduction to the Dependency Mechanism, Dependency Scope: "provided ... indicates you expect the JDK or a container to provide the dependency at runtime."
Re "there is a bit older version of that jar on the server":
Update the library on the server or use the older when developing. I'd consider it a really bad idea to use different versions of a library for developing and runtime. This can lead to subtle errors that are hard to identify.
Re "And what is the procedure in case of using maven":
Does the introduction linked above help you in answering this as well?
Maven is supposed to work the same with any type of IDE.
I'm getting this error
Error:java: Fatal Error: Unable to find package java.lang in classpath or bootclasspath
in IntelliJ when I try to build/compile any project. Something that should be stated here is that NetBeans, Eclipse and even the javac command line can compile, build, and execute the same project without errors. This is why I suspect that the problem lies with IntelliJ, all other IDEs work well.
In IntelliJ I already:
Restarted, reinstalled
Invalidate Caches / restarted
Deleted / readded the JDK in Project JDK
Deleted / readded the JDK in Platform Settings
Rebuild / recompile
In Windows I already:
Deleted / Reinstalled Java SDK
Deleted / Readded the JAVA_HOME, PATH and CLASSPATH on System Variables
Tried the above on User Variables
Deleted and reinstalled IntelliJ IDEA
I already seached for issues like this on the Internet, here on Stack Overflow I found:
Question #1 | Question #2 | Question #3 | Question #4 | Question #5
And 30+ sites, and tried every answer...
Here you can see my IntelliJ Project Structure the last time that I tried to build/compile
I was using Java 1.8 when I got this error, after some hours, I installed Java 1.7 and the project worked fine. Maybe IntelliJ doesn't support Java 1.8?
Anyway, it would be great if anyone knew a way to make Java 1.8 work with IntelliJ.
I just spent quite few hours on this and found a solution which might work for you as well. IntelliJ seems to have a bug which expects the JDK to be in a different directory than is specified. I followed these steps:
open intelliJ, click help -> show log in explorer
modify build-log/build-log.xml and change <priority value="info" /> to <priority value="debug" />, you may have to run the editor as an administrator
run the compilation which fails with "Error:java: Fatal Error: Unable to find..."
open build-log/build.log and search for rt.jar, you should find it in a block with a set of other JRE libraries and the directory which points to the file should be wrong
In my case the JDK is included in D:\Development\software\jdk1.8.0_20, while the log points to C:\Users\Vladimir\Development\software\jdk1.8.0_20
I fixed the issue by copying my JRE to the place which is expected in the log. And just like in your case this seems to only happen with JDK 1.8.
The problem comes from IntelliJ bug (existing at least in version 14).
It happens when your JDK directory is under the user profile directory. For example, JDK located in this directory (for Windows):
C:\Users\myuser\jdk1.8.0_20
will be stored in IntelliJ internal configuration (file 'jdk.table.xml') as:
$USER_HOME$\jdk1.8.0_20
But your %USER_PROFILE% environment variable could point at some other (non default) location. Then IntelliJ will look at the wrong directory.
Possible fix:
Install your JDK at different directory, which is outside your profile directory. Like:
C:\Programs\jdk1.8.0_20
Then register this JDK for use in your IntelliJ project settings.
I encountered this on Arch Linux 4.16.13 with IntelliJ 2018.1.4 after importing a Java project using Gradle. I made sure that there is a registered JDK in "Project Settings" -> "Project" but IntelliJ was unable to find the classes from the JDK, java.util.List for example.
The solution was to add a new JDK entry at the same path as the existing JDK (/usr/lib/jvm/java-8-openjdk in my case). This will cause IntelliJ to put the files under jre onto the classpath whereas with the old JDK entry, only the files under lib were on the classpath.
Had the same problem. Simple fix to others in case the other answers are complex.
Go to File -> Project Structure
Under Project SDK, choose new and add another JDK.
The default use in my case was 1.8 that was of build 181. I choose the 1.8.0_192 I had recently downloaded.
After applying, the project loads itself.
When I re-ran the test, it works!
If this problem occurs when importing a project in netbeans then try to create a new project then check the properties of your new created project and match those properties with the project that you imported in my case there was a difference between target of android package version.
From what I understood, debugging for hours, the problem is with the location where the jdk1.8 gets installed(/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home), instead of under System/Library).
So the following has to be done to fix in intellij
1. For an existing project, right click and select module settings, and SDK and add 1.8 as a version.
2. Using a terminal go to ~/Library/Preferences//options/. Remove the old JDK specific lines in jdk.table.xml. Update the default version in project.default.xml
Clean you project in intellij and build. It should use the new jdk and sync.
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?