I made up an applet to auto dial a contacts number via our phone system switchvox, as well as log the call information into our CRM, salesforce. The issue I am running into is that unless I use the separate JVM parameter things get screwy.
For example say they have multiple tabs open for multiple contacts, thus multiple applets running in the same jvm. Without the separate jvm parameter sometimes it will dial a number from another tab. I pass the number via the parameter tags and I have even tried passing the number by calling a JS method from the applet with still no luck.
Since our crm is cloud based people like to have multiple tabs open, but do not like seeing multiple java icons down below, go figure. Anybody have this issue before, and/or have a workaround without the separate jvms.
It is hard to say without looking at your applet's code.
But I would hazard a guess that your code is putting some of its mutable state in statics, and occasionally one instance of the applet is interfering with another via the statics.
If you have any shared mutable statics in your applet, ideally you should get rid of them. Or if the state really needs to be shared by multiple instances of the applet, make sure that all accesses are properly synchronized.
Statics are shared among the applets since they're all running in the same VM. You could try the classloader_cache="false" applet option and still share the VM. I am not sure whether this option applies only on applet startup, however, as I haven't had success with it working all the time.
The best bet is to get rid of statics or use separate_jvm.
Related
I have read this SO article, which tells us singletons are very very evil and should be avoided like an epidemic. It also tells us that singleton is just like a "global".
This makes me wonder if I really need something that acts like a program runtime state, would singleton be a bad idea?
For example I have a JavaFX application which can spawn many windows. Each of the windows have at least two stylesheets - one for controlling layout (like alignment etc), and another for theming.
The theme stylesheet can be switched out into another theme stylesheet at runtime, and it should globally affect all windows that are open at that instance. To me, it makes sense for me to make a singleton class that has a ObservableList of stylesheets, which all windows can bind their Scene's stylesheet property to.
Is this really a bad idea? If it affects testing, how exactly does it affect testing negatively? I understand each of the windows should be tested indepedently of each other, but the actual behavior is that all of them are supposed to look thematically the same. Furthermore, I don't think it should affect other areas which each window should really be independent of each other.
If this is really bad, what should be the approach to achieve the same result in the above example?
Actually you could get the same behavior using dependency injection.
In the main line of your application you'll instantiate a class like UIContext, and whenever you open a new window, you'll give that UIContext instance to its constructor.
All windows share the same UIContext instance, but it's not a singleton, it's just you've injected the whole UIContext into many other dependent classes.
That is, if you would need to implement tests, you could give a sample/fake UIContext to your windows with no hassle.
So I have a fairly complex applet structure from a couple years back, and I have a question about a global class that is in it. Basically, I have three applets on the same page and they interact with each other in different ways. The part I'm confused about is the fact that they all share global (static) variables from the same class. How exactly is this happening? I was under the impression that each applet would have its own little environment and would thus be unable to access the same static variables as the others? For example if I have this in applet A:
Globals.globalVar = 5;
And this in applet B:
int x = Globals.globalVar;
And I ensure that B starts AFTER A then x will become 5. I would like to know how exactly this is handled in the JVM, as it doesn't quite make any sense to me. Does this behaviour imply that if you have two separate java applications running at the same time they can access each others static variables? Thanks beforehand.
Because that's how it's defined, for backward-compatibility reasons. See http://download.oracle.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html#cache:
Normally, if two applets have the same codebase and archive
parameters, they will be loaded by the same class loader instance.
This behavior is required for backward compatibility, and is relied on
by several real-world applications. The result is that multiple
applets on the same web page may access each others' static variables
at the Java language level, effectively allowing the multiple applets
to be written as though they comprised a single application.
While this feature enables certain kinds of applications to be
conveniently written, it has certain drawbacks. It interferes with
termination of applets, in particular when multiple instances of the
same applet are active. It makes the programming model for applets
more complex, since it is under specified exactly when the static
fields of an applet will be re-initialized, and when they will be
maintained from run to run of the same applet. It causes imprecise
behavior of certain user interface operations within the Java Plug-in
due to the inability to identify exactly which applet initiated a
particular request.
For this reason, the new Java Plug-in provides a way to opt out of the
use of the classloader cache on an applet by applet basis.
All,
I'm working on the design of a cloud-based service that will provide the option to execute some "plugin" code submitted by clients. In order to make this work it is essential that the plugins can't threaten system integrity or have any ability to access the data of other clients.
Ideally I'd like it to be possible for clients to submit a simple jar file (containing a class conforming to some pre-defined interface) which would then be run within a sandbox.
The client code should be allowed to:
Take as much CPU time as it needs on a single thread
Perform any calculations using standard java classes (e.g. java.lang.Math, java.util.Random etc.)
Call any libraries bundled in the jar (but which must be subject to the same restrictions)
But I would specifically need to disallow the following:
Spawning new threads (so that server resource can be fairly managed!)
Any access to the file system / IO / network
Any access to native code
Any access to data in the JVM other than that passed to / created by the client code
Any access to reflection on classes other than those in the .jar sandbox
Any ability to call methods on objects outside the sandbox, other than the standard Java libraries
Is it be possible to achieve this with a custom ClassLoader / SecurityManager setup? Or will I need to start looking for a more sophisticated solution (e.g. launching multiple JVMs?)
Managing resource and limiting resources is not possible in java. You can prevent malicious code to access system resources (disk/network and so) or the JVM itself but:
...
Spawning new threads (so that server resource can be fairly managed!)
If i wanna be malicious I am gonna do all my code in the finalizer thread and just block the VM. Same doing protected void finalize(synchronized(Thread.class) {for(;;) LockSupport.park();}} bye-bye new threads.
Eating all the memory, eating all direct memory and so on.
Accessing zip files in my own jar, and expect 'em getting moved away, so the JVM crashes (due to bug(s) in zlib)
If one purposely wants to deny resources, it is just not a feasible task to try and catch the hacker. You'd need to know what to search for and dynamically check/enhance the classes on run-time to disallow the behavior.
Any ability to call methods on objects outside the sandbox, other than the standard Java libraries
What are the standard libraries? Do you know if/when they must possibly execute some code in a privileged method.
Each customer - separate VM w/ full restrictions, process affinity/priority, incl max memory/stack and so on.
I think everything you want to achieve can be done through a custom SecurityManager. In fact it's pretty simple, you just create a class that extends SecurityManager, implement the two checkPermission(..) methods and in the first iteration just throw an SecurityException for everything that comes in (and log what you just denied). Then you allow specific operations until you find yourself in the situation that it's possible to create useful plugins and let your clients play with it. They will complain. Then you have to judge whether to allow them to do whatever they requested or if you want to stick with your rules. Here the difficult part begins...
I have a java program that is quite large and we want to make it so the user can quit the app and login as another user. To do this we would like to shut down the app and restart it so it presents the login dialog to the user. The problem is that the application is quite large and is poorly written. It has a lot of static variables that hold some sort of state info. Ideally I would like to rewrite the app to handle a situation where these can all be cleared out, but in reality we need to provide this functionality asap.
What I was thinking would be the easiest would be to simply stop the app and start a new vm. However, it seems surprisingly difficult to stop and application and start the same app while shutting down the current one. Does anyone have experience doing this?
EDIT: we are pursuing using Runtime.exec to call the same app again, but exec() wants to block so we have to jump through hoops to get it to work on every platform (Windows, Mac, Linux). I would prefer a platform independent way of doing it.
If you can modify the code, maybe you can exit the program and use the Runtime class (java.lang.Runtime) to start the same program again (with the same arguments?) using the exec() method.
http://download.oracle.com/javase/6/docs/api/java/lang/Runtime.html
Edit: That is to say, you first run the new process, and then exit the program. The other way would of course be much more difficult or impossible(?). :)
If you truly want to stop the JVM and restart it, then you'll have to write some wrapper script (shell script or batch file, depending on your OS) that does it. You could use a special return code from System.exit() to indicate that the application should be restarted.
And that's probably the best way to do it. You could play some classloader tricks, in which your create a custom classloader that to load the application's classes. However, there are a lot of ways for this to go wrong: for example the application code might call System.exit() in some hidden place, or it might contain code that retains internal references in classes loaded by the bootstrap classloader.
Static members are associated with the classloader:classname. You can create your own classloader and instantiate your app via that. Then when you want to restart, throw away the classloader and create a new one. This is how app engines like JBoss are able to reload applications on the fly.
You can use Runtime or ProcessBuilder to relaunch your application but you probably have to modify your application a little bit as I'm pretty sure you don't have a way to retrieve the java executable full path from within the JVM.
I suggest you to implement a launcher (as an executable or a script) and use the java return code to know if you need to exit or if you need to exit or restart.
What are differences between Actions and Commands in the context of Eclipse RCP? I know that they both contribute to the menu entries, but which one is better? And why?
Of all the online resources I read, I could not get a firm understanding of the differences between both. I have not actually tried to use them, but just wanted to understand them to start with from higher level point of view.
Thanks
Did you read the eclipse wiki FAQ What is the difference between a command and an action?
You probably already understand that Actions and Commands basically do the same thing: They cause a certain piece of code to be executed. They are triggered, mainly, from artificats within the user interface
The main concern with Actions is that the manifestation and the code is all stored in the Action.
Although there is some separation in Action Delegates, they are still connected to the underlying action. Selection events are passed to Actions so that they can change their enabled state (programmatically) based on the current selection. This is not very elegant. Also to place an action on a certain workbench part you have to use several extension points.
Commands pretty much solve all these issues. The basic idea is that the Command is just the abstract idea of some code to be executed. The actual handling of the code is done by, well, handlers. Handlers are activated by a certain state of the workbench. This state is queried by the platform core expressions. This means that we only need one global Save command which behaves differently based on which handler is currently active.
This article details the differences
Actions:
The UI and handling are always tied. There is no way you can separate each other
While Actions can be contributed to different parts of the workbench (popup menu/tool bar), all of them were different extension points and so you end up duplicating the XML in multiple places. The worst of it is that not all the extension points expect the same configuration.
Specifying Actions in multiple places is a maintenance nightmare. If you have to change the icon of an action, you need to change in all the places.
Another issue with duplicating Actions in plugin.xml is that multiple instance of the same Actions will be created in the memory.
Commands involve more extension points, but:
Handler can be declared separately from a Command. This enables for multiple handler declarations for the same command.
The activeWhen for all the handlers are evaluated and the one that returns true for the most specific condition is selected. All these things are done without even loading your handler in the memory. Even without loading your plugin!
Defining the parameters is all about returning a map of display names & the ids. The name would be displayed in the key bindings page and the id would be used to invoke the command when the key sequence is pressed.
Define an IExecutionListener, which is merely an observer of the command execution so it can neither veto on it nor make any changes to the event
Just adding to VonC's excellent answer, commands might be a little overkill if your application is relatively small. They are relatively harder to setup, and they shine the most when you have multiple perspectives, editors and views.
For something simple, I would go with actions.
And remember that Action may be deprecated on later version of Eclipse. I'd suggest you to use Command from the beginning.