Hello All
I am writing some software that will allow users to create their own Java classes for a specific use in my software package. Obviously, my software will need to be able to invoke a Java compiler to compile the user-generated classes for use in my program. However, I do not want to require users to download and install the entire JDK just so they can have access to the javac Java compiler. I understand that in Jave 6 there is a new Java Compiler API but even then, users with just the JRE and not the JDK will get a null object when they try to instantiate the Java compiler tool.
So, what is the best way to enable my program to compile Java classes while requiring the end user to just have the JRE installed on their machines? If this is not possible, what is the minimal set of libraries/jar files I would need to install on the user machine?
I suppose another possibility might be to use JWS (javaws) to launch the app over the web. In this case, is it possible for my software to not require the JDK (mainly tools.jar I think)? Would I somehow have to bundle tools.jar with my software?
You can use standalone Java compiler from Eclipse. It doesn't need JDK installed, and it's single JAR file you can use in your project. This is the compiler that is used inside Eclipse itself, but it can be integrated into other programs too. You can find current latest stable version at http://download.eclipse.org/eclipse/downloads/drops/R-3.6.2-201102101200/index.php, look for Look for JDT Core Batch Compiler. Documentation is available at http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm
You can also use Janino, which can compile also smaller units than full Java classes: blocks, expressions. It's not full compiler though, it does not support all features of Java language that your users use (generics, annotations, enums, ...)
To use the java compiler, you need to include tools.jar into your application (e.g. it has to be reachable by the classloader who wants to load the compiler - most easily by the System class loader).
Maybe http://asm.ow2.org/ this will be usefull? To generate bytecode on fly?
It sounds like a better solution would be to use some scripting language that can run within the JVM without having to be compiled.
Possible the Java Scripting API would be of use to you. I'm sure there are other options as well.
Related
I'm creating a java/groovy application that also supports scripting via groovy. There is a lot of legacy java code and new parts written in Groovy. Beyond that, the app is also scriptable with groovy.
I can keep everything running under the VM and obfuscate symbols from the jars as I did in the past - no problem. BUT:
I'm evaluating using GraalVM to create a native binary, but the question is how will that be compatible with running external groovy scripts during runtime? Does graal retain symbolic information for classes and methods and how is the data exchange for method calls handled from script to native? I'm not sure if this will even work.
From past similar projects, I know that native compilation in most cases, strips the binary of any symbols. I also need this feature in place of obfuscation. The plan is to preserve symbols for some methods and objects that are allowed access by the external groovy scripts only.
Clarification: This relates to GroovyScriptEngine and CroovyClassLoader in particular. sections 1.3 and 1.4 here.
How is the memory model of GraalVM compiled groovy compared to the groovy VM?
If I load a class at runtime and pass it an object foo created from the native side, will the script work and be able to use the members as normal or even reflection on foo?
Thanks for the help.
#Boris is correct, groovy uses java classloaders internaly on all script runtime compilation. Without the JVM, the native/Substrate VM version of Graal is unable to run newly generated JVM butecode.
It seems to me that the Java Compiler API allows to compile at runtime a class, writing its output (the .class file) to the file system. However, in-memory compilation is not supported. Is this correct ? or is possible to use this API to compile a class in memory (from a String) and instantiating such class afterwards ?
(I know I can compile the class to the file system and load it afterwards with a custom class loader, but I am wondering if I can compile it in memory, without passing by the file system).
Is there another alternative mechanism to do such in memory compilation using the J2SE only?
BeanShell (I library that can do what I want) mentions in its web page that it may be included in the J2SE at "some point in the future", however, the status of its JSR is "Dormant" (whatever does it mean).
Update:
Ideally, I would like to know if this can be done with the J2SE only (or if there are any expected enhancements to J2SE that will allow me to do this in, for example, Java 8). However, tips about how to do that requirying the JDK to be installed are also appreciated (thanks Evgeniy).
It is possible if you have JDK, java complier is in tools.jar which comes with JDK only. See http://docs.oracle.com/javase/7/docs/api/javax/tools/package-summary.html
Java Compiler API .. in-memory compilation is not supported. Is this correct?
No. The STBC uses the JavaCompiler to do exactly that.
..and instantiating such class afterwards?
The STBC does not go as far as trying to load/run the class, but I believe it should be possible. I imagine it might require a custom 'in memory' class loader though.
..the JavaCompiler API can do that independently if the JDK is installed or not?
From the page..
System Requirements
STBC will run on any computer with a version 1.6+ Java Plug-In* JDK (AKA SDK).
* The API that STBC uses is merely a public interface to the compiler in the tools.jar that is distributed only with JDKs (though the 'public JRE' of the JDK also seems to acquire a tools.jar). ..
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
I have a client jar made-up using java 1.6 and used enum and other new features of java, my application is built on java 1.4.
I want to use that client jar in my application.
Is it feasible to do ?
Normally: no, you can't.
You could use a library/byte-code rewriter like Retroweaver to rewrite the library to be 1.4 compatible. There's also Retrotranslator which does the same thing and other tools. The last time I used Retroweaver was just after Java 5 was released, so I can't talk about it's current state.
But that will be a hack at best. Using an ancient Java version is a liability at best and you should upgrade to at the very least Java 5 as soon as possible.
Can't you upgrade to JDK1.6?
else you need to add rt.jar of JDK1.6 to your class path but that will cause conflicts for classes common to JDK1.4 and JDK1.6
Your client jar will need JRE 1.6. As for your application, ideally you should be able to run it on JRE 1.6 as Java is backward compatible.
So you need to port your application to JRE 6, recompile and then you should be able to use client jar.
However, upgrading and porting has it own complexity and consequences.
you could try making the jar available via a web service interface and run it as 1.6; should work, but I won't tell you it 'll be easy.
You obviously need JRE 1.6 or higher to run your library code. Due to backward compatibility the 1.4 part of your application should run on a that JRE as well. How you interact between your 1.6 lib and your 1.4 application is another question though.
Your application cannot use enums or other 1.5 features directly. If everything you directly access in your library is 1.4 compatible it should work, I think. E.g. if your application defines an interface and the library provides an implementation of that. (I.e. typical plugin pattern.) If your library's interface needs the application to use 1.5 features, e.g. pass an enum value as method parameter, that obviously won't work with your existing byte code.
I want to ship an open source Java project with its own JRE so that it doesn't depend on whether one is installed or not.I will have everything in one directory and my program will be the sole user of that jvm and class library.
As Java is now open source, I think I can now legally strip down the class library (rt.jar) to only classes I need. For example I don't use any SQL so I don't want to burden the download with classes in the java.SQL package.
This would be somewhat analogous to a linking step when an executable is built from libraries using only methods in the call tree that starts with the programs main().
Does anyone know what tools I might use to do that. Is it possible?
I think this is pretty much already done in Java 6 update 10.
It was planned for Java 7 but it shipped before.
It is the Java Kernel here are the details, I'm not quite sure if is what you need.
Here are the links:
http://tech.puredanger.com/java7/#kernel
http://weblogs.java.net/blog/chet/archive/2007/05/consumer_jre_le.html#JavaKernel
Here is other:
http://java.sun.com/javase/6/6u10faq.jsp#JKernel
There is a commercial tool that can legally strip down the Java class library.