I'd like to compile Java to Javascript with LLVM like this:
*.java to *.class, via Oracle's javac
*.class to *.bc, via vmkit's vmjc
*.bc to *.html with JS, via emscripten's emcc
The created HTML/JS file (about 170KB large) prints ReferenceError: _StartJnjvmWithoutJIT is not defined in the browser console when opened. Trying to debug this I noticed that the *.bc file (LLVM IR) doesn't even seem to contain my code, i.e. the strings I'm printing are not inside.
What I did:
vmjc -disable-opt -main=MyTest MyTest.class
It prints out, no matter whether I use Java 6 or 7:
WARNING: Class file 'java/lang/VMString' requires Java version 1.7. This JVM only supports Java versions up to 1.6.
It creates a *.bc file anyway. When I convert that to non-binary (*.ll), I get a file where I would have expected my strings that I print to appear, but they don't. A string like MyTest_main does appear there, though:
llvm-dis MyTest.class.bc
So, is this approach viable at all? What does the warning about the Java version mean? Why doesn't my 'hello world' string appear in the *.ll code and is that a problem?
You could shorten the route by using GWT to compile Java directly to JavaScript.
Java and JavaScript are two different languages. Cross-compiling is tricky and mostly leads to clumsy code.
Personally I recommend a manual reimplementation of the core logic in Typescript, because it supports classical OO (object-oriented) development and type safety. Translating the code this way is time consuming, but relatively easy.
Alternatively, OO-style programming in native JavaScript is also possible. But since it lacks type savety, development this way is harder.
http://addyosmani.com/resources/essentialjsdesignpatterns/book/
Related
As in C/C++ the program is first given to the preprocessor to include files & perform macro expansions etc... then given to the compiler to convert the code into assembly format and the process goes on.But in Java I do not see the use of preprocessor.Why so and then who does all the task that normally the preprocessor handles?
The pre-processor is not a necessary step of the compilation process in Java.
In C/C++, functions stored in different files are "included" in other files, which essentially means they are copied and pasted in their entirety into the document. This was a pretty good idea at the time, given the hardware capabilities at the time, but nowadays more modern languages use something called "symbolic imports".
Symbolic imports involve looking for symbols in another file rather than using text directly. In Java, this can involve importing constants or classes. These imports act as references to code in other files. Thus, rather than having to go through the trouble of having the pre-processor copy and paste code around and eventually figuring out what code belongs to which file, Java allows doing these imports on a semantic level directly.
This makes a pre-processor unnecessary to the compilation process of the language, and has therefore, along with other reasons been left out.
I've been having terrible luck trying to get this to work, so I'm hopeful someone can help here.
In Java, I need to be able to take an HTML page with JavaScript within it and detect any JavaScript errors without, preferably without executing the JavaScript code.
I found this article:
Javascript parser for Java
And I've attempted to figure out how I'm supposed to use Caja to do this, but I'm having a difficult time finding any documentation with working examples of anything close to what I'm doing.
As a result I took a look at Nashorn also referenced in that article. I found a few examples which show how to execute JavaScript code from Java, but this doesn't process the whole HTML page. Even then, the execution doesn't seem to include the ability to validate common JavaScript functions (e.g. It hadn't heard of "alert").
Can anyone recommend something that might be able to do what I want, and point me in the right direction for their documentation or give me an example?
jshint as a standalone product seems to be a good fit for this:
it can run in java inside rhino (see https://github.com/jshint/jshint/)
a nodejs package exists (see https://www.npmjs.com/package/jshint)
it works with nashorn but it's quite tricky
I will only cover the technical difficulties around 3rd solution as I finally managed to make it work too...
Spoiler alert: "alert()" is not detected yet... Solution nb 2 will help there...
You first need to grab this specific release of jshint: https://github.com/jshint/jshint/releases/tag/2.4.4
Anything later than v2.7.0 will fail for now and I personally gave up patching intensively prototypes and namespaces... Releases from v2.4.4 until v2.6.3 work without modification but are limited in functionalities.
In the release notes, it's specifically written that "support for the Nashorn JavaScript engine" is working on this release. I'm using JDK8 nashorn 1.8.0_45 for this test.
Next step is to extract from this release this single file jshint-2.4.4/dist/jshint-rhino.js
Now you need to run nashorn/jjs in scripting mode and you need to be specific about the single file you wish to verify. In solution 2 (nodejs based) you can do multiple files or a complete hierarchy below a folder...
Create a simple file file.js:
function(){}
Now run the following command (please note the presence of -- ):
jjs -scripting jshint-rhino.js -- file.js
This will give you the following output:
Missing name in function declaration. (file.js:1:9)
> function(){}
So this covers the how to run jshint in a simple manner with nashorn... With the 3rd solution, at least you can find missing semicolons and several typical errors. But it's not a silver bullet and to me it's not a real alternative.
My personal preference would be to stick to solution 2 only. If you've the possibility to install either nodejs or iojs on your dev platform, go and grab https://www.npmjs.com/package/jshint. Not only will you be able to do more than the 3rd solution, you'll also be able to configure a jshintrc file as described at http://jshint.com/docs/
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Convert String to code in Java
Dynamic code execution on Java
I have a String containing : "for(int i=0 ; i<5 ; i++){System.out.println(\"*\");}"
Can I execute the code in this String in Java?
Since Java 6, you can compile and run a Java compilation unit defined as a String or a File using standard APIs in the SDK (a compilation unit is basically everything that goes inside a .java file - package, imports, classes/interfaces/enumerations), take a look at this example. You can't run an arbitrary Java snippet like the one in your question, though.
If at all possible, it'd be a better idea to embed a different scripting language that allows you to run snippets of code from a Java program - for example, JavaScript, Groovy, MVEL, BeanShell, etc.
If you turn it into a full-blown source file, you can feed it to the java compiler programmatically, but last time I checked that was only available if you had the java SDK installed on your machine; it was not available on machines with the client distribution of Java. Of course, this may have changed since then. Look at package com.sun.tools.javac and you will find the java compiler API there.
Maybe you can run this as Groovy:
http://groovy.codehaus.org/Embedding+Groovy
There isn't a Java Core API function for doing this, but you can call javac either by using Runtime.exec or using some "unsafe" classes from com.sun.tools.javac Here's an example:
http://juixe.com/techknow/index.php/2006/12/12/invoke-javac-at-runtime/
I don't think you can execute a String containing a java code.
But it is worth a try if you can save that as a java source file and try to use ProcessBuilder class to execute.
Never tried it and not sure if it is best way to do it. So use it with caution :)
Good Luck!
Also found a similar post: Runtime class in java
No, you can not execute this code in your program.
How can i do with Java. Here doc like string? Exaple:
String java = << \EOF
#This file is written via Java
#You are watching JavaHereDoc
; comments ;
value=abc
etc etc
EOF;
System.out.println(java); shows exactly like above. How can i do this?
Java (as of 7) doesn't support HERE docs (also known as multiline strings) unfortunately.
If you're trying to accomplish templating, there are a few options:
StringTemplate
Apache Velocity
These aren't exactly similar to HERE docs in Perl or PHP since the string that describes the template isn't directly in your code; it's usually in a separate file.
There was a proposal put forward by Stephen Colebourne as well as a proposal via Project Coin, neither of which made it into Java 7, which was a little disappointing. Languages like Groovy and Scala, which also run on the JVM do support multiline strings.
In the meantime if you find it useful here's a basic swing application I use to do this for SQL that's embedded into the classes. I find myself using it over and over again so why not share it?
https://github.com/danielbchapman/Swing-String-Escaping-Utility
(a small note, its throw away code since I put it together in a week where I needed to rapidly format queries, I might clean it up at some point)
I am working with a large Java web application from a commercial vendor. I've received a patch from the vendor in the form of a new .class file that is supposed to resolve an issue we're having with the software. In the past, applying patches from this vendor have caused new and completely unrelated problems to arise, so I want to understand the change being made even before applying it to a test instance.
I've got the two .class files side by side, the one extracted from the currently running version and the updated one from the vendor. JAD and JReversePro both decompile and disassemble (respectively) the two versions to the same output. However, the .class files are different sizes and I see differences in the output of od -x, so they're definitely not identical.
What other steps could I take to determine the difference between the two files?
Conclusion:
Thanks for the great responses. Since javap -c output is also identical for the two class files, I am going to conclude that Davr's right and the vendor sent me a placebo. While I'm accepting Davr's answer for that reason, it was Chris Marshall and John Meagher who turned me on to javap, so thanks to all three of you.
It's possible that they just compiled it with a new version of the java compiler, or with different optimization settings etc, so that the functionality is the same, and the code is the same, but the output bytecode is slightly different.
If you are looking for API level differences the javap tool can be a big help. It will output the method signatures and those can be output to a plain text files and compared using normal diff tools.
You could try using a diff tool (such as SourceGear's free DiffMerge tool) on the decompiled sources. That should pick up the file differences, although it will likely pick up "insignificant" differences, for example if variables have been named differently in the two versions.
http://www.sourcegear.com/diffmerge/
You can use javap (in $JDK_HOME/bin) to decompile java .class files. It will tell you (for example) the class file version among other things