I am having the following problem:
I am using Catalina (10.15.7) on a MacBook and recently I downloaded a JAR executable file (called JKnobMan) but apparently it doesn't have access to the open and save operations, even though the program runs normally otherwise, and it even lets me export. But naturally, what I want is to be able to save my progress and open it later on.
The message I get when I click 'open' is: "The open file operation failed to connect to the open and save panel service". I don't get this message when I 'save' but the saved file contains none of the information it should have (I checked this by opening the saved file on the web version of the KnobMan program).
I tried going to the Security & Privacy settings to give this program all necessary access but for some reason the JAR file is not selectable when I browse the items.
I expect this to be an easy fix, but so far I have been unable to find a solution. Some people experience a similar problem with email services and they're usually easily solved, so this must be straightforward as well?
Any help appreciated.
EDIT: Note that I'm not asking for help with THIS particular program. I assume that I would have the same issue with any other JAR executable trying to open/save in a Catalina environment. So, knowledge of said program is probably not necessary to know the solution.
I recently made a simple Gui Library program, which can make new books and store them on shelves. When I ran the application from eclipse, it serialized the files and When I reopened the application, I was able to load old information off of it.
However, when I converted it into an .app and ran it, it functioned normally, but I was unable to save (serialize) data, and consequently not able to retrieve data when I opened it up again.
I tried searching my computer for that .ser file, but it seemed to not have been created.
I assume this has something to do with the JVM, but I'm not so familiar with the ins and outs of the JVM. It also may not. Do you know why my program wouldn't serialize properly and how I could fix it
Thanks
M.R.
I have a major problem that happened to me. I am writing a program that has taken me 3 months+ to make and today I accidentally deleted the source code.
I am working in NetBeans and I had just cleaned and built it, so I still have the working .jar file. The program was saved on a flash drive, not my computer, so the classes are not in the recycling bin.
Can anyone tell me about how I can go about getting my source code back?
Unless you explicitly packaged your source code in the JAR file, there's no way to get back the original source. You could try using a decompiler (like this) but that will hardly give you nice, readable code.
The best solution would be to stop using your computer right now. Then use a recovery tool to recover your deleted files. The more recently it was deleted, the higher the chance you'll get it back. There are lots of tools that can be used to do this (just Google it).
You can use a decompiler ( see How to decompile a whole Jar file? ) but you won't be getting "original" source back.
The app works perfectly fine on the simulator and on the device. After adding a new set of images, it started to show on every run, on the simulator and on the device, a class not found exception.
When trying to delete some images to find the cause, I get different classes not found when running. Compiling and packaging the application generates no warning or error. They even get signed. Some of the "classes not found exception" I get:
java.lang.stringbuilder
net.rim.device.api.ui.uiapplication
I am guessing it has something to do with the total image size. The size of each image ranges from 100KB to 300KB, and we are talking of only 25 to 30 images in total. Adding the image outside of the 'res' folder doesn't generate the error, but the image isn't added to the final files. Deleting the images, the ones just added resolved the issue, but I need those images...
Also, this application is not big, but when compiling, and packaging the app, it generates and signes 125 cod files. Is that normal?
I am using Eclipse 3.6(Helios), and BlackBerry Eclipse Plugin SDK 5.0.0.25 on Win 7
Any help will be appreciated. Thanks.
Each .cod file is limited to about 64K. If your 25-30 images average about 200K, the 125 cod files doesn't surprise me.
The error messages sound like rapc is getting very confused. After you add your images, try refreshing the project or even exiting and restarting Eclipse, then clean and build the project from scratch.
Including large amounts of media is generally not a good app design for the BB. There's a good discussion here about alternative ways to handle this.
It turns out this issue was caused because of the total size of my images, which in turn created more then 127 .cod files. Total number of siblings .cod files is 127, my app had that limit, and this is why some essential classes were not included. I still think the blackberry plugin should warn about this, because it showed no error when compiling, packaging and signing the application. Here is the link from the BlackBerry developer support forums where I got this information:
http://supportforums.blackberry.com/t5/Testing-and-Deployment/The-maximum-size-of-a-BlackBerry-smartphone-application/ta-p/502534
Since I am used to the iOS world, where I can add whatever I want to the app, and it has virtually no limit on the resources I can add, except to consider that the user would have to wait a good amount of time downloading the app, and the 2GB application size, which, really is a lot for 99% of the apps.
So for this app what I did was I added only the essential images as compiled resources in the app, and the rest of the images are downloaded automatically when the application launches the first time.
I am getting the warning
Warning: sendmailpm.jsp modified in the future.
What does this mean?
You aren't allowed to modify anything in the past if doing so might change the future. You might cause a temporal paradox, which could corrupt the time stream and cause our entire reality to cease to exist.
Please do not modify that file.
JSP files are compiled. Many servers also allow you to replace the files on a running server. It then compares the timestamp of the compiled source and the timestamp of the jsp file to determine if it needs to recompile.
If the file is dated in the future, the jsp file will always be newer than the class. This gives you a warning.
Check the timestamp on the file. Perhaps someone created it on a computer with an incorrect clock, and now it appears to be "created in the future". Or perhaps the server has the incorrect date (check timezone settings).
Are there remote file servers involved? Clock drift between a web server and a file server can cause this error too.
To diagnose this further, you'd have to give us some hints - what jsp server, what OS, what filesystem?
During an Ant build, this warning can be output during a task.
[copy] Warning: foo\bar.txt modified in the future.
Ant's <copy> task by default won't copy files if the destination files are newer than the source. This saves much time and disk I/O. However you can override this behavior with the option <copy overwrite="true">. This tells Ant that you know what you're doing; overwrite the destination files regardless of their modification date. This will also suppress the warning.
If your code is residing on a FAT/FAT32 partition or ZIP file, this can be caused by the lack of precision in the FAT/ZIP filesystem's timestamping, which is 2 seconds (afaik). This can cause compiler / build tool output to be saved with a time slightly in the future, so that when the next build/deployment step (can be internal to a JSP container) is executed, the file will appear to be from the future and the warning is produced. Try using a different file system, e.g. NTFS on DOS/Windows boxes.
I had the same warning message from Apache Ant when trying to do a Java build on a FAT32 TrueCrypt partition. After ruling out other causes (timezone difference, clock off etc), I eventually found a hint on this, changed to an NTFS TrueCrypt partition and the warning disappeared.
Someone probably modified the file, then changed the time on the server. Try checking to see what time your box is set to and make sure it's correct. If it is, you can probably ignore that warning without any side effects.
Check whether system time is correct or not. If not sync it with Standard time for your zone. Then run your build file.
JSPs are compiled on-the-fly to servlets. The servlet container compares the "last modified" dates of both to see if the JSP has been changed and the servlet needs to be updated. A "last modified" date in the future indicates that something is wrong with the system clock, which is relevant because it could disrupt the abovementioned mechanism, leading to servlets that are not updated.
This is because, The time of the system is not current on which you are running the build file
If the java file that you are compiling has a time stamp that is beyond the current time of the system on which you are compiling...you will see this warning.
I modified the file on one machine and put it on another and tried compiling and came across this issue.
I got the same issue. The solution was: I changed the date and time on the build machine, so that it was in sync with the date and time on machine which the files were copied to.
If you have a jar file that you are trying to install at remote server. It might happen that remote server timestamp is not matching with your time zone. If your timezone is couple of hour ahead than the remote server then you might get this issue.
I also tried out one more trick..
When you create a JAR file, then go to system time and set a date couple of months back and try installing the JAR, you get this error.
I had this error too, but after reading some answers above i realized that is was due to the change i've done in the computer to some days ahead because of the test of a functionality that requires date manipulation.
Here is what happened:
1 - To perform Unit Test of a new implemented functionality i had to set the computer date to 4 days in the future.
2 - When i performed the test the compiler compiled the class automatically, as expected.
3 - Therefore when i was trying to rebuild the project the IDE detected that the file was (ironically) created in the future. (LoL - that's why i love Java you can even code in the future.).
So +1 #jmanning2k.
I hope it can help somebody facing this issue.
That warning appear to me too, it was because a previously changed the time in my computer to fix it because it was like 20 minutes ahead of the actual time