Luajava learning notes [2] using LUA to control Java objects

Luajava Study Notes

Using LUA to control Java objects

[Resource Preparation]

This time still use LuaJava1.1 as a tool, you can download here: http://luaforge.net/projects/luajava/. Don't forget to put the local library in the project directory. My working directory is like this:

For convenience, I use Maven for project dependency correlation, and you can also import Luajava jar packages into projects, both of which are equivalent. If you are using Linux for development, your local library name should be a so file that can be found on the link page.

[source file]

Testobject.java

Package Com.thrblock.lua.luatest;public class Testobject {/** normal method Test * */public void Saystr (String str) { System.out.println (str);} /** static methods Test * */public static void Sttest () {System.out.println ("static Method");} /** test with return value method * */public String GetInfo () {return ' Test Info ';} /** a delay function * */public void delay (int millsecond) {try {thread.sleep (millsecond);} catch (Interruptedexception e) {}}}

Main.java

Package Com.thrblock.lua.luatest;import Org.keplerproject.luajava.luastate;import Org.keplerproject.luajava.luastatefactory;public class Main {public static void Main (string[] args) {luastate L = Luastat Efactory.newluastate (); L.ldofile ("./scripts/main.lua");//Set script testobject m = new Testobject ();//Instantiate Test object L.getglobal ( "Doscript");//Set Method entry L.pushjavaobject (m);//Set parameter L.call (1, 0);//Call Method (Block) System.out.println ("Calling complete!");}}

Main.lua

function Doscript (obj) obj:saystr ("Delay 2 sleep ...") Obj:delay (+) obj:saystr ("done! And another sleep 2 ... ") Obj:delay (OBJ:SAYSTR) ("done!") Obj:sttest () End

[test results]

Delay 2 sleep ...

done! And another sleep 2 ...

done!

static method

Call complete!

[meaning]

In traditional programming, we develop each module, and finally use the appropriate operating context (such as the main thread) to call the modules of each method, the control of the call process relies on hard coding, the universality is not very high and maintenance cost is large.

In order to change the lack of hard coding, a lot of solutions and frameworks began to appear, a typical pattern is to use the interface between the module coupling isolation, and with the configuration file + reflection mechanism to control the interface corresponding to the implementation of loading, so we only need to change the configuration file to the overall operation of the program control. For example, the servlet for JSPs, the action in struts, activity in Android, spring Dependency injection, and entity beans configured in various JPA implementations should note that none of the above classes are new to us, They are properly loaded and instantiated by the container through an XML configuration file.

Even as there are many ways to reduce the cost of program changes, demand remains unmet. Some programs are not sensitive to the implementation of the module, but are sensitive to the call sequence of the module, at which point the scheme can play a very limited role, which is common in all kinds of games.

For example, a flight shooting game that contains a module that generates enemies:

Model.generateenemy (typetype,action anction,int x,int y);

Where type refers to the type of the enemy, the action is the enemy's motion mode, XY is the coordinate point produced on the screen. The gameplay of the entire game, then, relies heavily on the sequence of calls to the module, that is, when, where, what type of enemy is being produced, and what mobile strategy to use.

The different call sequences are generally reflected in various levels, mods, and even game DLC, so it makes sense to organize call sequences effectively. But the general configuration file is obviously not good at describing the structure of the call sequence, because different sequences vary enormously and may contain logical control structures (for example, to create different enemies based on the difficulty of the player's choice, the roles are different), so the script is the main force to solve such problems-no need to compile, low cost, Able to describe most of the control structures. In addition to these features, LUA's multi-platform support and ultra-high affinity with other languages make it popular with game developers. Imagine that when we developed DLC for the game, it was a pleasant thing to just update a few small LUA scripts.

[summary]

This article describes a way to control Java classes using LUA, and for incoming Java class objects, use LUA scripts to control their invocation sequences.

In the final part of the article, we discuss typical scenarios in software development to reduce maintenance costs and the role that scripts play in them.

Finally, we summarize the problem that the script is good at solving, which is that a program that is sensitive to the module invocation sequence can leave the calling procedure to the script control.

Luajava learning notes [2] using LUA to control Java objects