We Keep Coding

How to package all required libraries with .so file linux

I am attempting to port an application that was written with a combination of c++ for the back end, and java for the front end. This application relies on the library opencv 2.4.13, which is outdated, as well as multiple other libraries. The concern i have is that i do not want the end user to need to install these dependant programs, as they have been proving challenging to install on any but a select few linux distributions. I believe the term i am looking for is statically linking, but i'm a bit unfamiliar with c++ compilation at the moment, so i am unsure the steps i need to take to make these files portable. The java application requires these files to be libraries, and while i have managed to get them to compile on one machine, the problem seems to be getting them to run on a different one after compilation.

Don't bother - this might also give you licensing problems, depending on what libraries you need.
Instead, just figure out what platforms your application is supposed to run on and package the libraries for each platform with your jar - or download them at startup, or provide them as a separate package. The exact mechanics you choose depend on your use case, the point is you don't need to rely on system wide installs.

Java Applet allowed for Javac or other jar access?

I am involved in a project that will need to run via web and have access to java's compiler tools and/or javacc api. My team is thinking of using a java applet to make it web based. I'm wondering if there are certain limitations on what an applet can and cannot do in this case. I would assume that since access to the compiler would be done on the server, not the client's machine, that this wouldn't be a problem. Does an applet allow us to separate the two as described?

An applet (and even a JavaFX applet) can work in this situation if the applet is signed. There are numerous subtle pitfalls with applets, so I would advise prototyping before committing to that technology. Follow the JavaFX deployment guide to see how to deploy a JavaFX based applet.
I had thought that to compile Java, you needed to have the full Java Development Kit installed (which would be tricky to ensure in an applet deployment situation). But it seems that the compile API is included in the javax.tools API included with the standard Java Runtime Environment. So this likely means that you could develop your solution, including client based deployment and compilation of Java code, without requiring the user install the full Java Development Kit.
You may alternately wish to consider a client/server solution where the compilation can be performed on the server. An example of such an approach (with a Java WebStart based solution) is the TopCoder Algorithm Competition Application. Here is a jnlp file (http://apps.topcoder.com/wiki/display/tc/The+Algorithm+Competition+Arena) to run this application. I suggest you register an ID at TopCoder using the application and try out writing and compiling some code using it. The TopCoder implementation uses plain Swing as it was written before JavaFX existed, but you could equally use JavaFX for your implementation if you preferred.
If you additionally need an editor (with syntax aware text styling) for the code you will be compiling, you could use something like this CodeMirror based editor embedded in JavaFX. The CodeMirror based solution wraps the editor in html based WebView control. For JavaFX 8 you will probably be able to make use of the new TextFlow control for a syntax highlighting text editor, but that API is not part of a supported public release yet.
Update
I got this work using the strategy outlined in this answer.
The image is an html page allowing access as an applet or a webstart application to the client code editor. The top area of the image is the code editing area which is based on a WebEngine with an embedded syntax highlighting CodeMirror JavaScript editor that supports Java editing. The bottom area of the image is the output of compiling the code in the editor locally on the client machine and subsequently running it. The output constists of any compilation errors, any program output to sysout, as well as any runtime exceptions printed to syserr. The tricky parts of the solution were:
Working out how to capture sysout and syserr and redirect them to a JavaFX control.
Finding the Java compiler.
The default Oracle Java Runtime Environment Provider merely provides a generic interface to a Java Compiler implementation, but it provides no java compiler implementation itself - that implementation is only included in the tools.jar included with the jdk. So when I packaged my applet, I included the tools.jar in the packaging for the applet. I had some difficulty getting the service provider interface to get me an instance of the javac compiler, so in the end, I just instantiated it using the following line:
JavaCompiler compiler = new com.sun.tools.javac.api.JavacTool();
The above is somewhat brittle as sun may change their private com.sun classes at any time - but at least it worked in this instance.
Another thing to be aware of is that if you ship a tools.jar with a javac compiler which is earlier than the runtime environment that you have available for your system, then you might get some warnings such as below:
warning: C:\Program Files\Java\jre8\lib\rt.jar(java/lang/Object.class): major version 52 is newer than 51, the highest major version supported by this compiler.
It is recommended that the compiler be upgraded.
The above warning occurred because I shipped the applet with a java 7 tools.jar and ran the applet with a java 8 runtime (note that the applet worked fine regardless of those warnings).
Update
I put the code for this solution in a github repository (project name conception). The updated solution uses the Eclipse Compiler for Java rather than the Oracle Java Compiler. Mostly because, for the Eclipse Compiler, it is a separate jar (only 1.8meg rather than the 14meg tool jar of the oracle distribution) and the licensing is a bit clearer. Because the Java compiler interface is pluggable, the Oracle compiler can still be used if tools.jar is placed on the classpath.

Yeah applets can access them and can be a good choice. But it has very limited/ dull look and feell. Go for JavaFx in this you can define your own StyleSheet so it will give you a very good look and feel and yeah definitely it will separate the two layers too.
JavaFx Oracle Documentation

Dynamically load and run Java code from within Java application

I am thinking about writing a Java application where the user can write some modules in Java and add them to a library in this application. The modules will be some calculations that use data from the main app. Maybe a bit like VBA in Office.
I would appreciate if someone would give me some hints where to start as I couldn't find something useful on the net.
Thanks in advance!

You can try to develop a module framework from scratch, if you wish.
However, if you are developing anything serious you should consider using OSGi.

Theoretically it is possible. You can allow user to write java classes, then you can compile the class using java compiler, generate .class files. you can load them using your custom class loader (probably URLClassLoader or its subclass, etc.
BUT
It is very serious application. Actually it is a kind of IDE. So, of you really want this check out a possibility to create Eclipse based application, i.e. implement several eclipse plugins.
Other approach may be to allow user wring code in one of popular scripting languages. For example groovy that has java-like syntax but can be run without compilation and does not require creating classes etc. Javascript is an option too. Javascript interpreter is a part of JDK, so you even do not need external dependencies.

you might be better off incorporating some form of jvm scripting language. Something like groovy, jruby or jython. Those don't need actual compilation and can be stored in your system as source. Plus they can be quite nice to write code in too. Groovy has the advantage of being a superset of java. (For the most part) you could just degrade to java code, and run it in the groovy interpreter.

Is there a legitimate, automated, method for deploying Java applications on iOS4?

I'm wondering if there is a standard method for deploying applications originally written in Java, to iOS4 devices.
I assume that the application in original format cannot be deployed - is there perhaps an emulation layer that I can use, or a stable compiler that compiles Java to ObjectiveC?

Option 1:
Use one of several cross compilers, compiling Java to ObjectiveC:
http://www.xmlvm.org/overview/
http://www.flexycore.com/ispectrum-overview.html
Option 2:
Package custom JVM with java application, with restrictions that meet the latest agreement (including no byte-code download capability and no JIT compilation). No JVM specifically designed for the iPhone is currently (Oct 2010) available, though the IKVM might run on top of Monotouch, and Oracle may build a version of the Java SE for the iPhone eventually.
Option 3:
Cross compile Java to one of the existing interpreters that are already accepted on the iPhone (eg, cross compile Java to C# and run the app on monotouch)

With the new current iOS SDK agreement and App store rules, it may be possible for you to embed a Java applet with your own JVM interpreter and runtime engine (but no byte-code download capability and no JIT compilation allowed).

Another seldom mentioned possibility for deploying any non media or graphic intensive networked app, such as many typical Java applets, is to run a customized RDP or VNC viewer on the iPhone and and view a Java app that is being hosted and run remotely.

Mechanically translating some of your code will likely work pending finding a cross compiler / translator. Trying to run a Java based GUI on iPhone is just plain stupid in my opinion. So the smart thing would be to port the GUI by hand.
The problem of course is if the app is mostly GUI you might as well write the whole thing over. Likewise if the app uses APIs that there is not a simple translation for you again might as well rewrite the entire app.
In a nut shell I think Steve J. Was right here, the route you are comtemplating just leads to poor user experiences. It actually makes me wonder why you would even think that a Java based app would be successful on iPhone.

Deploying Application with JVM

Our customer wants us to ship his application with an embedded JVM. We tried to convince him otherwise but had no luck.
Now, here is the way we are contemplating taking. We want to take the Apache Harmony VM and libraries. We would then strip everything we don't need and ship the application with the bare minimum in terms of libraries.
My questions are thus:
1) Where can I find detailled explanations about the functionality provided by the different libraries (natives and classes) coming with a JVM?
2) How can i know if a JVM library file is needed or not?
I know the questions are a bit convoluted, but i hope somebody out there have done something similar.
Regards,
Gregoire.

It looks like you can also distribute the Sun JDK if you do not modify anything (I would consult a lawyer to be sure).
Whichever way you go I would not prune anything, that would make it more complicated if and when you needed to upgrade the client's software.

The problem is not the license of Sun/Oracle, they allow redistribution of the Java Runtime Environment, so developers can embed it into their application installation packages.
However, the problem is export regulations. By law, you may not export parts of the JRE to certain countries, so you would have to check whether your customers are in the allowed list of countries before they can download your application package which includes the JRE. This for example applies to such things as the Java Cryptography.

Use a Sun JVM embedded within your application and start it with the invocation API. That way you could save some more diskspace :) IBM has an example source code how to start the JVM.
Try launch4j to bundle the JVM with your application and save some work.