CODEWITHSUNDEEP
javajavascriptjquery
KJW
KJW

Reputation: 15251

how to bundle javascript files into Java application?

Javascript is executed by Java application. However, something like Jquery library is really too long to fit into a String variable. I am able to read jquery.js from a file but not sure how to package it inside the .jar file.

Upvotes: 2

Views: 2515

Answers (2)

Andy
Andy

Reputation: 5218

Loading the .js files is the same as loading any other resource from a jar file. Generally, this is what I do:

For files stored in the root of the jar file:

 SomeClass.getClass().getClassLoader.getResourceAsStream( "myFile.js" );

For files stored along side a .class file in the jar:

 SomeClass.getClass().getResourceAsStream( "myFile.js" )

Both techniques give you an InputStream. This can be turned into a String with code a little bit more work. See Read/convert an InputStream to a String.

This technique is for when your resource files are in the same jar as your java class files.

Upvotes: 2

Pointy
Pointy

Reputation: 413856

There are all sorts of places you can keep your JavaScript sources:

  • In the CLASSPATH. You fetch them with getResourceAsStream()
  • In the database. Yes, the database. You fetch them like you'd fetch any other CLOB.

Personally I've use both approaches for different purposes. You can keep your JavaScript files around in your build tree in a way that exactly parallels the way you keep .properties files. Personally I just keep them in with the .java files and then have a build rule to make sure they end up in the .war, but they can really live anywhere your build engine can find them.

The database is a nice place to keep scripts because it makes it much easier for your web application to support a "script portal" that allows dynamic updates. That's an extremely powerful facility to have, especially if you craft the web application so that Javascript modules control some of the more important business logic, because you can deploy updates more-or-less "live" without anything like a deployment operation.

One thing that helps a lot is to create some utility code to "wrap" whatever access path you're using to Javascript (that is, either the Sun "javax.script" stuff, or else the Rhino bindings; at this point in time, personally I'd go with straight Rhino because it really doesn't make much difference one way or the other anyway, and the Sun stuff is stuck with a fairly old and buggy Rhino version that in the current climate will probably not see an update for a while). With a utility wrapper, one of the most important things to do is make it possible for your JavaScript code (wherever it comes from) to import other JavaScript files from your server infrastructure. That way you can develop JavaScript tool libraries (or, of course, adapt open-source libraries) and have your business logic scripts import and use them.

Upvotes: 1

Related Questions