Closure Templates through IKVM? - google-closure-compiler

Google Closure works GREAT without the Java Runtime Environment by using IKVM
In case that ever goes away, the simplified steps to convert it to an exe are:
Download and extract (but nothing to install) Closure Compiler and IKVM
Move compiler.jar to the IKVM bin folder
ikvmc -target:exe -fileversion:2012.09.17 .\compiler.jar (with the jar's release date). Note: I get a few warnings about ANT libraries.
Copy these dependencies from the ikvm bin directory to the closure directory:
IKVM.OpenJDK.Core.dll
IKVM.OpenJDK.Jdbc.dll
IKVM.OpenJDK.Misc.dll
IKVM.OpenJDK.SwingAWT.dll
IKVM.OpenJDK.Text.dll
IKVM.OpenJDK.Util.dll
XML.API.dll
IKVM.Runtime.dll
Then you can move the compiler.jar and new compiler.exe back to your closure directory. Fredrik recommends this powershell version of execution because of the ability to specify ascii encoding overriding unicode (half the bytes):
.\compiler.exe --js .\jquery-1.4.2.js --warning_level QUIET | out-file -encoding ascii .\jquery.min.js
==============================
However, I do not have the same luck with the Closure Templates's SoyToJsSrcCompiler.jar. I get warnings from ikvmc -target:exe -fileversion:2011.12.22 .\SoyToJsSrcCompiler.jar as with compiler.jar.
warning IKVMC0105: Unable to compile class "com.google.template.soy.jssrc.internal.GenerateSoyUtilsEscapingDirectiveCode"
(missing class "org.apache.tools.ant.Task")
warning IKVMC0100: Class "com.google.inject.internal.asm.util.$TraceClassVisitor" not found
warning IKVMC0111: Emitted java.lang.NoClassDefFoundError in "com.google.inject.internal.cglib.core.$DebuggingClassWriter$1.run()Ljava.lang.Object;"
("com.google.inject.internal.asm.util.$TraceClassVisitor")
warning IKVMC0100: Class "com.google.template.soy.jssrc.internal.GenerateSoyUtilsEscapingDirectiveCode" not found
The resulting SoyToJsSrcCompiler.exe with no command-line arguments works to show the help page, but supplying a .soy file gives:
Exception in thread "main" cli.System.MethodAccessException:
com.google.inject.assistedinject.FactoryProvider2.getBindingFromNewInjector(java.lang.reflect.Method, System.Object[], AssistData) at
com.google.inject.assistedinject.FactoryProvider2$$FastClassByGuice$$9dcdf6d7.invoke() at
com.google.inject.internal.cglib.reflect.$FastMethod.invoke(FastMethod.java:53) at
com.google.inject.internal.SingleMethodInjector$1.invoke(SingleMethodInjector.java:56) at
com.google.inject.internal.SingleMethodInjector.inject(SingleMethodInjector.java:90) at
com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:107) at
com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.java:76) at
com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.java:73) at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031) at
com.google.inject.internal.MembersInjectorImpl.injectAndNotify(MembersInjectorImpl.java:88) at
com.google.inject.internal.Initializer$InjectableReference.get(Initializer.java:150) at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) at
com.google.inject.internal.SingleFieldInjector.inject(SingleFieldInjector.java:53) at
com.google.inject.internal.InjectionRequestProcessor$StaticInjection$1.call(InjectionRequestProcessor.java:11 6) at
com.google.inject.internal.InjectionRequestProcessor$StaticInjection$1.call(InjectionRequestProcessor.java:11 0) at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024) at
com.google.inject.internal.InjectionRequestProcessor$StaticInjection.injectMembers(InjectionRequestProcessor. java:110) at
com.google.inject.internal.InjectionRequestProcessor.injectMembers(InjectionRequestProcessor.java:78) at
com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:171) at
com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:111) at
com.google.inject.Guice.createInjector(Guice.java:95) at
com.google.inject.Guice.createInjector(Guice.java:72) at
com.google.template.soy.MainClassUtils.createInjector(MainClassUtils.java:212) at
com.google.template.soy.SoyToJsSrcCompiler.execMain(SoyToJsSrcCompiler.java:223) at
com.google.template.soy.SoyToJsSrcCompiler.main(SoyToJsSrcCompiler.java:205)
Anyone know how to get this to work?

The exception can be an bug in IKVM. Which version do you use? Test the latest version.
warning IKVMC0100: Class "com.google.template.soy.jssrc.internal.GenerateSoyUtilsEscapingDirectiveCode" not found
Another problem can be that you have not compile all needed jar files for SoyToJsSrcCompiler.jar. In which jar file is this missing class file? Take a look in the wiki to see how you compile multiple jar files.
The next problem can be that there is the same package in different jar files. It there are only package visible for some mthods this will not work for .NET. You can test a sharedclassloader. See the wiki for details.

Related

command line compiling generates bigger file than the online version

I am testing google closure compiler on command line.
I took the latest version :
java -jar closure-compiler.jar --version
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20190618
Built on: 2019-06-21 17:24
I am generating a compressed version of my javascript like this :
java -jar closure-compiler.jar my_script.js > out.js
The problem is that the generated code is bigger than the one I get when I use the online service at https://closure-compiler.appspot.com/home
I noticed that the command line version added, at the beginning, the following code :
var $jscomp=$jscomp||{};$jscomp.scope={};$jscomp.findInternal=function(a,c,b){a instanceof String&&(a=String(a));for(var d=a.length,e=0;e<d;e++){var f=a[e];if(c.call(b,f,e,a))return{i:e,v:f}}return{i:-1,v:void 0}};$jscomp.ASSUME_ES5=!1;$jscomp.ASSUME_NO_NATIVE_MAP=!1;$jscomp.ASSUME_NO_NATIVE_SET=!1;$jscomp.SIMPLE_FROUND_POLYFILL=!1;
$jscomp.defineProperty=$jscomp.ASSUME_ES5||"function"==typeof Object.defineProperties?Object.defineProperty:function(a,c,b){a!=Array.prototype&&a!=Object.prototype&&(a[c]=b.value)};$jscomp.getGlobal=function(a){return"undefined"!=typeof window&&window===a?a:"undefined"!=typeof global&&null!=global?global:a};$jscomp.global=$jscomp.getGlobal(this);
$jscomp.polyfill=function(a,c,b,d){if(c){b=$jscomp.global;a=a.split(".");for(d=0;d<a.length-1;d++){var e=a[d];e in b||(b[e]={});b=b[e]}a=a[a.length-1];d=b[a];c=c(d);c!=d&&null!=c&&$jscomp.defineProperty(b,a,{configurable:!0,writable:!0,value:c})}};$jscomp.polyfill("Array.prototype.find",function(a){return a?a:function(a,b){return $jscomp.findInternal(this,a,b).v}},"es6","es3");
I do not have such a code in my script: Where does it come from ?
how can I produce the same output as the online version ?
To get the compiler command line work as the web service, I just added an option :
--language_out=ECMASCRIPT_2015
This is likely a discrepancy between the settings on the web service and the ones you're using locally.
Have a look at a Closure Compiler: Flags and Options to see what settings you might prefer.
If you'd share your source, it'd be possible to try and help you narrow down the options.
As for the extra code, I believe it is at least partially a polyfill for Array.prototype.find (aka [].find), which I assume is in your code?
If so, that's Closure injecting code to improve your cross browser compatibility.

Fail to link to standard library of Ocaml-java (or Cafesterol)

I am a new user of Ocaml-java (or Cafesterol) which compiles primtive Ocaml program to executable jar that is allowed run on JVM. However when I try to compile a test program into executable jar I got error info as follow:
>java -jar ~/ocaml-project/ocamljava-bin-1.4/bin/ocamljava.jar -standalone regexdna.ml -o regexdna.jar
File "regexdna.ml", line 1, characters 0-1:
Error: No implementations provided for the following modules:
Str referenced from regexdna.cmj
Unix referenced from regexdna.cmj
It seems module Str and Unix is missing from Ocaml-java. However, str.jar and unix.jar do exist under ~/ocaml-project/ocamljava-bin-1.4/lib/others/ when I install Ocaml-java, and within these jars we do have Str.class and Unix.class. (I suppose this directory is on the path of the standard library of Ocaml-java, so it should be included in default search path)
Can any Ocaml-java user tell me how Ocaml-java search for dependency libraries?
Quoting Xavier Clerc on this :
Well it should work, but you have to pass explicitly the referenced
library (just as in vanilla OCaml). Leading in your case to:
$ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -jar ~/opt/ocamljava-2.0-early-access9/lib/ocamljava.jar str.cmja regexdna.ml
Note that I am using the latest ocamljava preview.

javacc testing Simple1.jj

If you see my other question, you will now better my goals. Take a look at: https://stackoverflow.com/questions/19510039/from-regex-to-parser-generators .
As I'm trying to be a good boy, I'm reading the README (see https://java.net/projects/javacc/sources/svn/show/tags/release_60/examples/SimpleExamples?rev=555 ).
Run javacc on the grammar input file to generate a bunch of Java files that implement the parser and lexical analyzer (or token
manager):
javacc Simple1.jj
Now compile the resulting Java programs:
javac *.java
The parser is now ready to use. To run the parser, type:
java Simple1
My try:
D:\tests\javacc\simple1>javacc ..\Simple1.jj
Java Compiler Compiler Version 6.0_beta (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file ..\Simple1.jj . . .
File "TokenMgrError.java" does not exist. Will create one.
File "ParseException.java" does not exist. Will create one.
File "Token.java" does not exist. Will create one.
File "SimpleCharStream.java" does not exist. Will create one.
Parser generated successfully.
D:\tests\javacc\simple1>javac *.java
SimpleCharStream.java:474: error: non-static variable this cannot be referenced from a static context
static void setTrackLineColumn(boolean trackLineColumn) { this.trackLineColumn = trackLineColumn; }
^
1 error
My java version:
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) Client VM (build 24.45-b08, mixed mode, sharing)
I'm sure that "these" guys known what they are doing, I'm sure I did something wrong, but what? Getting a simple error like that in the first test with javacc?
How can I fix that and continue my lecture?
I suggest using version 5.0 for now. There are a lot of changes in version 6 and these came along with some bugs. There should be an update to version 6 soon. https://java.net/projects/javacc/downloads
Will you put the code to look it or your complete call. I think, that it´s a code error or that you call a bad .java archive. For example:
I have: Mytokens.jj and javaCode.java ok? Good, you need said:
javacc Mytokens.jj
javac javaCode.java
java javaCode <test1.txt>
I give you my *.bat for the test. You create a new txt and write it:
CALL javacc nameJJ.jj
#pause
CALL javac NameJava.java
#pause
java NameJava <prueba1> salida.txt
type salida.txt
#pause
This do the test for you when you do a double-click on it if you have a copy in your javacc/bin and your practice directories.

Documentum NPE when running as jar

I'm writing a simple application to create a Documentum folder structure from a directory structure on disk. When I run the application through SpringSource Tool Suite, it works fine. When I package it as a jar, with all dependencies, and run it, I receive the following error:
java.lang.NullPointerException
at com.documentum.fc.common.impl.preferences.PreferencesManager.locateMainPersistentStore(PreferencesManager.java:372)
at com.documentum.fc.common.impl.preferences.PreferencesManager.readPersistentProperties(PreferencesManager.java:333)
at com.documentum.fc.common.impl.preferences.PreferencesManager.<init>(PreferencesManager.java:41)
at com.documentum.fc.common.DfPreferences.initialize(DfPreferences.java:64)
at com.documentum.fc.common.DfPreferences.getInstance(DfPreferences.java:43)
at com.documentum.fc.client.DfSimpleDbor.getDefaultDbor(DfSimpleDbor.java:78)
at com.documentum.fc.client.DfSimpleDbor.<init>(DfSimpleDbor.java:66)
at com.documentum.fc.client.DfClient$ClientImpl.<init>(DfClient.java:344)
at com.documentum.fc.client.DfClient.<clinit>(DfClient.java:754)
Here is the line in my code where this error occurs:
IDfClient client = DfClient.getLocalClient();
The jar includes the dfc.properties file, which I specify on the command line using
-Ddfc.properties.file=dfc.properties.dev
For the record, the full command line looks like this (slightly anonymized):
java -Ddfc.properties.file=dfc.properties.dev -jar MyTest-jar-with-dependencies.jar baseDirectory baseDocumentumFolder
Thanks much for your time!

Compc (Actionscript Library Compiler) Doesn't Fail Unless I Delete the File First?

Here's the scenario: I run compc on a source directory to recompile an already existing library after some changes, which completes successfully. Then I remove the library (the .swc file) and re-compile, which causes many errors to be thrown.
Nothing changed in the interim - clearly this should have either succeeded both times or failed both times.
libs/pv3ddebug $ compc -library-path+=.. -source-path=./src -compiler.optimize -include-sources+=./src -output ../pv3ddebug.swc
Loading configuration file /Users/bill/flex_sdk_3/frameworks/flex-config.xml
/Users/bill/lg/vision/libs/pv3ddebug.swc (152944 bytes)
/libs/pv3ddebug $ rm ../pv3ddebug.swc
/libs/pv3ddebug $ compc -library-path+=.. -source-path=./src -compiler.optimize -include-sources+=./src -output ../pv3ddebug.swc
Loading configuration file /Users/bill/flex_sdk_3/frameworks/flex-config.xml
/Users/bill/lg/vision/libs/pv3ddebug/src/com/phenomblue/pv3ddebug/PV3DDebug.as(45): col: 34 Error: Type was not found or was not a compile-time constant: AdvancedView.
public function PV3DDebug(view:AdvancedView)
^
... more errors follow
I think I've found out why the errors are happening, and can correct them, but I'm disturbed that the first compile didn't fail.
I have a theory:
Library A, which pv3ddebug depends on, was correct
pv3ddebug was compiled successfully (and it correctly)
Library A was brought into a state that would fail to compile with pv3ddebug
pv3ddebug was compiled successfully, incorrectly, because compc didn't notice that A was updated to a failing state
deleting pv3ddebug and then recompiling caused compc to try and compile with the new A, and so the compilation failed.
My questions to you: is step 4 a bug? Is this caching behavior I should have expected, or can change with a compiler switch? Is there something going on that my theory doesn't explain?
You could try -incremental=false. This is supposed to be the default for the command line compiler, but what you're describing sounds like it's enabled.

Resources