I've come back to project after a long diversion, and upgraded tooling. This means Netbeans 12.5, Java 17, Gradle 7.3… at least allegedly. For some reason, despite setting the Gradle version to 7.3, it appears to build with 7.0.
Per the image below, setting the Gradle version to 7.3 doesn't seem to be picked up. (That is immediately after hitting Apply.) It still tries to build with 7.0. And – for some indeterminate reason – it can't.
Restarts don't help; I can't get the configuration to be picked up. (Searches for reference to similar issues provide 5-year-old answers that are no longer relevant.) I've even tried deleting the 7.0 distribution; to no avail, it comes right back.
Can anyone provide guidance on getting this to work properly?
Netbeans 12.6 fully supports Java 17 and Gradle 7.3. Gonfiguring the Gradle wrapper for 7.3 gets picked up correctly, eliminating all errors I was experiencing.
Don't bother with gradle in Netbeans. It's a horrible, buggy disaster and 12.6 just seems to want to up the ante.
Netbeans does NOT support gradle in a meaningful way for normal users.
You now get complex multi-projects whether you want them or not.
When creating a Java Application you don't get a choice at what the Main class is called. It will be App with app.java and you will like it.
If you try to rename app.java to something useful. It will not change "Class App" to "Class Useful" it will instead change it to "ClassUsefulp". It will not rename the test file and you will be left with several syntax errors that you can have fun cleaning up.
No, you cannot rename the subproject itself. That will continue to be the extremely descriptive and useful "app" subproject. The IDE will not provide you a way to rename that.
There is no meaningful, intuitive way to create/delete/modify subprojects.
If your gradle version is somehow out of sync there is still no useful way to reset/recreate the gradle wrapper other than creating a whole new project and moving your source code over to the new project.
Oh, so you gave in and accepted the multi-project structure. You noticed that if you go through the multi-project creator GUI then you can create multiple subprojects. Yeah, good luck with that. They won't have gradle build.scripts or wrappers. You won't be able to build your awesome creation.
Want to use command line arguments? Forget it. There is no "run" element in the project properties. You cannot create different run configurations.
Want dependencies? Or any other project configuration? It's all manual editing of gradle files. There's no GUI to assist non-gradle-wizards.
Yeah. you can probably work around a lot of this by dropping to a command line shell and editing the gradle scripts/files manually and running gradle commands manually. A) you're going to need to be a gradle wizard, and B) why are you using an IDE in the first place? you've got gradle, you've got vi available. Bathe in the nostalgia because you'll have to anyways.
Do you like the idea of gradle? Do you use Netbeans? Stick with Ant, or Maven if you need external dependencies; you'll thank me later.
My application makes use of a third party jar that I want to improve and that has bugs in it. I can see from using a decompiler where the bugs are and can easily fix them. I am unable to extend the class and overwrite the problem methods as they are private and final, and make use of private and final fields.
At the moment, I solve this using a decompiler (which isn't perfect) to re-create the class in a project with the same class name, package etc. My gradle build script then extracts the contents of the original jar to $buildir/main/java so that when gradle compiles my version of the class, it overwrites the broken one, resulting in a new jar that is bug free.
I think this method is dirty and unmaintainable as if a new version comes out, merging changes could be difficult. Also, Eclipse and IntelliJ won't build the project when both projects are in my workspace with a compile project dependency, even though it builds on the command line, as the IDE is unable to see the source for all the extracted jar, but only the class I redefine to fix.
What is the best way to cleanly solve this problem?
This is my problem: I'm new at Java, I started a Maven project because I needed to use a lib that requierd that. Then I no longer needed it but keep going with the Maven project. Now I'm trying to build it but the .jar does not run the project when double clicked.
Since I don't know Maven very well (I found this but didn't understand it), I thought that the easiest way was to convert the proyect into a "normal" Java App project. So I copied all files with classes from the Maven project folder to a new Java App project folder manually.
It opens fine, but I got this error when retrieving an ArrayList:
Exception in thread "pool-1-thread-5" java.lang.ClassCastException: java.util.concurrent.CopyOnWriteArrayList cannot be cast to java.util.ArrayList
Since this doesn't happen in the Maven project I assume that it happens due to my archaic method to copy the classes...
So, is there a way to convert my Maven Project into a normal Java Project? I have found a lot of topics about doing the opposite but anything useful about what I need (only this but it is not what I need).
Thanks!
You can try closing the project on NetBeans and importing a project from existing file system.
However I feel that is not the ideal way to do it, but it should allow you to run it as you require.
Disabling the Maven nature is also viable.
According to Java Docs, java.lang.ClassCastException is
thrown to indicate that the code has attempted to cast an Object to a subclass of which it is not an instance.
There might be a chance that you are getting that exception cause you are missing some library or class which implements the same interface or allows you to convert the object to a given type.
This error is just bizarre, my code compiles fine, I can see there are no problems with it, yet this error has just popped up. I have tried re-starting NetBeans and there is no additional exception information.
What can cause this?
If it is Netbeans, try to uncheck "Compile on save" setting in the project properties (Build -> Compiling). This is the only thing which helped me in a similar situation.
I guess you are using an IDE (like Netbeans) which allows you to run the code even if certain classes are not compilable. During the application's runtime, if you access this class it would lead to this exception.
It's caused by NetBeans retaining some of the old source and/or compiled code in its cache and not noticing that e.g. some of the code's dependencies (i.e. referenced packages) have changed, and that a proper refresh/recompile of the file would be in order.
The solution is to force that refresh by either:
a) locating & editing the offending source file to force its recompilation (e.g. add a dummy line, save, remove it, save again),
b) doing a clean build (sometimes will work, sometimes won't),
c) disabling "Compile on save" (not recommended, since it can make using the IDE a royal PITA), or
d) simply remove NetBeans cache by hand, forcing the recompilation.
As to how to remove the cache:
If you're using an old version of NetBeans:
delete everything related to your project in .netbeans/6.9/var/cache/index/ (replace 6.9 with your version).
If you're using a newer one:
delete everything related to your project in AppData/Local/NetBeans/Cache/8.1/index/ (replace 8.1 with your version).
The paths may vary a little e.g. on different platforms, but the idea is still the same.
I also got the same error and I did clean build and it worked.
Add selenium-server-standalone-3.4.0.jar. It works to me.
Download Link
Recheck the package declarations in all your classes!
This behaviour has been observed in NetBeans, when the package declaration in one of the classes of the package refers to a non-existent or wrong package. NetBeans normally detects and highlights this error but has been known to fail and misleadingly report the package as free of errors when this is not the case.
I had the same issue with one of my netbeans project.
Check whether you have correctly put the package name on all the classes. I got the same error message because i forgot to put the package name of a certain class (which was copied from another project).
Disable Deploy on Save in the Project's Properties/Run screen. That's what worked for me finally. Why the hell NetBeans screws this up is beyond me.
Note: I was able to compile the file it was complaining about using right-click in NetBeans. Apparently it wasn't really compiling it when I used Build & Compile since that gave no errors at all. But then after that, the errors just moved to another java class file. I couldn't compile then since it was grayed out. I also tried deleting the build and dist directories in my NetBeans project files but that didn't help either.
Organize your code as a maven module.
Once done run the command from terminal
$mvn installl
to check if your code builds fine.
Finally import the project in netbeans or eclipse as maven project.
change the package of classes, your files are probably in the wrong package, happened to me when I copied the code from a friend, it was the default package and mine was another, hence the netbeans could not compile because of it.
I had this problem with NetBeans 8.0.1. Messages about problem in project deleted class. Deleting the ~/.netbeans didn't work. Also I looked for ANY reference to the deleted class in ALL my projects, nothing found. I deleted the build classes, everything. Then, when I started Netbeans again, compile and magically appears the message in Run and into the mother compiled class. I tried the uncheck "Compile on save" Dime solution, and works, but it's not practical.
Finally, my solution was edit and force recompile of the mother class. This way the new .class doesn't contains the message and Run works OK.
Just check the packaging, the simplest answer I can provide is that your package has been mislabeled (within a class).
Also, you may have some weird characters. Try white-flushing the code in a Notepad (or Gedit) and then pasting it into a newly created class with your IDE.
If you are using Netbeans, try to hit the Clean and Build button, let it do the thing and try again. Worked for me!
I had the same problem. My error was the packaging. So I would suggest you first check the package name and if the class is in the correct package.
Implementing my own functional interfaces resolved this for me (so instead of using java.util.function.* just create your own single-method interface with the parameters and return-type you want).
Similar questions to this have been asked several times, but none of the answers fits my situation.
I have a Java project which I originally wrote to run on a PC. The classes containing the functional stuff are separate from those containing the GUI and PC specific bits and pieces. Now, I want to reuse those "generic" classes in an Android version.
I've created a new project in Eclipse. I've used the Build Path / Link Source item to point to the folder of my original project. Now links to the the .java files appear within my new project. I still can't invoke a method from the original project in my new one. I believe this option is only to allow the files to appear in the project and that it doesn't actually do anything functional.
Elsewhere, I learned of the ability to add the source in the Source path tab of the Build Path / Configure Build Path option. No joy with that either.
Another responded suggested adding the original project in the Projects tab of this dialog. This didn't help, either.
I've even tried multiple cantations of "import." Not even sure I should need to. No luck.
How can I resolve my "blah cannot be resolved to a type" warning in my Android project, when trying to call the method from my non-Android project, please?
Is there something missing from the raw Java which is required for an Android build?
You need to create a snaphot/util jar of the common project and include the jar in classpath of the dependent projects. This will fix your IDE problem.
During the deployment, make sure to include this new JAR in lib/classpath location of the deployable projects.