I've been using "Wiki on a Stick" for several years and have a few wikis that are full of info (and would be a pain to try to move onto something else). A year or two ago the editing features stopped working on all browsers aside from IE, apparently due to how those browsers handle Java or something.
However, I really hate using IE, so I was trying again to see if I could get it to work on Chrome. When I try it on Chrome, the error message reads: "The TiddlySaver Java applet was not available. Please check that the TiddlySaver.jar is in the same directory as this WoaS and that you have enabled Java permissions for it."
It IS in the same directory, so it sounds like all I need to do is "enable Java permissions for it"... but HOW do I do that?
Thanks.
I am afraid I have some bad news for you. Chrome (and practically all other non-legacy browsers) do no longer support the NPAPI, the technology behind Java "applets". So the applet will never run again. Especially not in Chrome.
The most recent activity in WoaS was more than five years ago, the board and mailing list died, so I doubt there will be an updated version anytime soon.
But I have learnt from the documentation, that the wiki's content is stored in a well-formated XHTML-File; so the parsing/extraction of your content shouldn't be that hard. But this is just from an outside perspective, I did not look into the product any further.
My advice would be to migrate you data as fast as possible, java applet technologie is a dead end.
Related
I originally posted this question on GameDev stackexchange however I'll also ask the question here to try and get more outreach, especially since I wasn't sure my problem was specific to game development since it's a problem with a Java native call.
For the past months I've been working on creating my own game engine for personal use in LWJGL using pieces here and there, especially from developer ThinMatrix's rightfully credited code, to learn as much as I can while building it. Only recently there has been strange behavior happening when I launch the engine from IntelliJ for testing:
After about 6-10 individual times I click run, all subsequent runs suddenly take about 60 seconds for the window to appear.
Whenever I restart my PC this hanging resets and I have another 6-10 runs before it hangs everytime again.
I located the issue to glfwInit, more specifically at the call to the native method:
#NativeType("int")
public static boolean glfwInit() {
long __functionAddress = Functions.Init;
return invokeI(__functionAddress) != 0; // Right here
}
I also noticed that this issue only started when I attempted to implement text support in my engine using the STBTrueType library. It was perfectly fine before that. I tried removing the TrueType code but it didn't fix it.
Here's a list of things I've tried:
Clearing my temp folder in case a buggy or corrupted file was present.
Recompiling and rebuilding the entire LWJGL jars twice.
Building glfw.dll from the GLFW sources and replacing the glfw.dll in the native jars with the former.
Reinstalling Java and actually upgrading JDK versions (from 13.0.2 to 14.0.2)
Switching IDEs even if I suspected it wouldn't work.
Updating my NVIDIA drivers, and reinstalling them.
I'm quite confused as to what it could be, and I'd be more than happy to share code, thread dumps, or debug info if you deem it necessary. Here is the Github repository with the latest, "faulty" code (fault in quotes because I'm not too sure the code is the problem.)
Thank you very much for any guidance.
P.S: Please tell me if this is better asked in StackOverflow instead of here.
So I fixed the issue, it turns out it wasn't even related to anything to do with programming, or STBTrueType, or the library itself. The problem was as pointed out in this StackOverflow post, where this hanging behavior was due to a faulty driver or, in my case, my keyboard USB being plugged in the "wrong" USB port. I moved my computer at the same time I started working on text in my engine, hence why I wrongly linked the issue with the TrueType library. If you're having the same issue, look at the aforementioned post or if that doesn't work, look for a peripheral that might cause interference.
I am working on an Android app that stores log on a client's Google Drive. We push static HTML/Javascript files to said Drive in order for the user to be able to read their logs in an user friendly way via their browser. This feature worked relatively well until now (notwithstanding some glitches due to server updates in the last few months).
2 weeks ago (.e. from the beginning of October 2014) we saw that the newer user interface of Google Drive has dropped the web host link capability altogether. For legacy accounts this feature is still there, but not for newer created accounts from the aforementioned date.
Does that mean that Google is planning to ultimately drop this feature, or is it going to be available for the foreseeable future, even if only accessible programmatically via SDK?
Note that we tested to see if programmatic access is affected, and it seems to work fine. We used java SDK function getWebViewLink() (class File) in order to get the link programmatically, and it still works no 1 for now. But the change in UI from Google does worry us that this feature will be dropped, like Dropbox dropped theirs recently. Is that the case? If so, what is the expected timeline of feature deprecation and eventual disappearance?
It looks like they moved/changed it but didn't remove it altogether. The instructions from Google on how to host webpages with Drive worked for me using an account I created after the UI change (after you posted this question).
Since their latest blog post on deprecating APIs does not say anything about getting rid of the web host feature, you are probably fine.
If so, what is the expected timeline of feature deprecation and eventual disappearance?
If the APIs they're deprecating are anything to go by, even if they do get rid of web hosting it will be a couple of years between the time they announce it and it actually being unavailable. It's not a perfect comparison since those are entire APIs and this is just a feature but it doesn't seem like they make a habit of making something unavailable at the drop of a hat.
We have recently added a Silverlight based plugin (Plupload) that works great except for one issue:
If you try to use it in Chrome your browser will popup with the message "Silverlight was blocked because it is out of date".
I appreciate Google trying to force users to update (which they otherwise never ever do) but this has single handedly tripled our customer support load. Does anybody know of a way to force it to run in Chrome via Javascript/Html code?
We have seen the same issue with many sites using Java applets. As Oracle constantly has minor updates it seems near impossible to stay "up to date" so effectively you asked to upgrade 9/10 times.
Is there any script or code that solves this problem?
Simply I have an image player in my web site which does not work in IE9. I know there is a solution (Java Applet Not Working (Blank) in IE9) which remove the problem, but if a user have not sufficient knowledge of how Windows works, or the web site is just play on outdoor screens, it need to be fixed with code by developer. Here is my website: http://www.interactivity.com.au/
Do you know any solution on Windows?
Since in a nutshell, the reason they're not working is that they're being blocked by a security feature, by definition there's no way for your applet to get around it. If there was, then it'd be a bug in the filter, and if such a way was found, you'd expect the filter to then be fixed to prevent it.
Add a link on your site to a set of instructions on how to fix the problem.
Recently two of our clients have reported problems with our applets. Looking at the java plugin console it is full of ClassNotFoundException so none of our code is executed.
I've been able to reproduce the stack trace using a virtual pc image with 0 free space on disk, but the problem goes away as I restore some disk space, and the users tell me that their disk is not full; they are able to create new files.
Our applet requires java 6, and the problem has appeared with updates 1, 10 and 14 of the jre. We have also tried different browsers (IE and Firefox), clearing the browser and java caches, ...
How can I debug or trace what is the jvm doing to load our applet?
I suppose that the problem lies on some security directive on windows so I'm using Sysinternal's Process Monitor to log the activity but I don't really know where to look at.
The Java cache is most likely messed up. Open Java in the Control Panel and get rid of all temporary files to see if it goes away.
Logging in the Java Console for loading applets can be enabled which helps quite alot (even if the plugin is extremely cryptic). See http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/tracing_logging.html
I've been looking at the plugin source from the JDK and I've found that there is additional debug info available in the logs setting the environment variable JPI_PLUGIN2_DEBUG.
Unfortunately I still only see ClassNotFound exceptions.
I've found a piece of the plugin code that swallows all exceptions, so maybe my users problem is there...
had similar problems a while ago. In our case, the problem seems to be how the applet tag is set up on the web page. If it is in a wrong order or contains the codebase attribute, it fails with 6u10+. This works for us:
<applet name="DMGANTT" archive="DMGantt.zip" code="dm.applet.DMGanttApplet"
width='100%' height='100%' mayscript="mayscript">
We had a similar problem with one of our clients. We discovered that it was a strange bug in some versions of Java related to proxy configuration on the client. See this article for the details
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6723715
Also, our applet failed with new versions for a different reason.
Now, in similar cases I ask them to check javatester.org, so that I can see if applets (in general) load OK in their browser. If that page loads OK, its a problem on our applet (or page). Else it's a problem in their configuration. I help them anyway but it's easier to debug.