I am working on a project, which will introduce programmable computers to Minecraft, similar to ComputerCraft, except using Python as opposed to lua.
I am aware of Jython, so thought it would be suitable to check if I could use that for my project, however couldn't find enough information (on their website and with a few searches) to be certain.
I am aware of the topic discussing using Java from within Jython, however this is not how I want my project to work. Those that have used Computercraft, know that you have only the libraries that Computercraft provides you, whereas the topic linked above has full access to.. well everything. In my use case, everything isn't possible. I also don't want from pycomputers.api import Colors, I want the 'colors' api to be used like colors.red.
Hopefully the above is possible, within Jython, if not I would love to know another Python interpreter (that can be used from Java), to make my project with.
According to the docs if you want to embed the Jython into a java application then you have to invoke it with the PythonInterpreter class. It's pretty strait forward from there, just note that the overloads that provide a filename argument are for the name of the main executable file (this information is normally available through the sys module in regular old CPython).
Now in order to expose bindings in java to python (say to control the minecraft world), we need to add the jar files to sys.path as is described here, and if you want to control the sys.path value from within java then use
PythonInterpreter pi = new PythonInterpreter();
pi.getSystemState().path.append(new PyString("path/to/java/modules.jar"));
Note that the packages inside the jar files cannot be organized in the reverse url style. Instead, follow the instructions on package naming. Particularly make note of Naming Python Modules and Packages and if you follow the guidelines in Proper Python Naming then you will get the results you desire.
Finally we execute the code with
String source = ...;
pi.execute(pi.compile(source));
Related
I'm trying to read a .qm translation files with Java.
.qm files are binary files. I don't have access to the .ts files.
And I don't find much info on these .qm files.
How are they structured ?
Regards,
There's no documentation that I know of, but if you look at QTranslator::load you should be able to follow the format of the QM file.
You will probably need to reimplement QTranslator in Java, as you need not only the ability to load the files, but also to extract and apply translations in Qt fashion.
As per request of OP:
You could use those files by using the Qt libraries and JNI. By using the translator in a c++ dll you can translate strings easily. However, you cannot extract the files or list the contained translations. But if all you need is the actual translation, this solution should work.
I cannot give a real example, because I only now how it works in theory, I haven't tried it, because it's not trivial. But if you are eager to try it out, the general idea would be:
Create a C++ dll and build it against QtCore. The easiest way is to download Qt from their website qt.io. You can for example create a default library project with QtCreator. Note: Besides Qt5Core.dll, Qt requires other libraries to correctly run. They are all included in the installation, but once you deploy your application, those of course have to be includes as well.
Include JNI to the C++ project and link against it. if you're new to this, here is a nice tutorial: Java Programming Tutorial
Create your wrapper methods. Methods in cpp you can call from java that take java strings, convert them to QString, translate them with QTranslator and convert them back.
Load the library in Java and execute those methods
Important:
First, I don't know how java handles dll dependencies. If you encounter errors while loading the dll, it's probably because dependencies of your dll are not present. Second, Qt typically requires a QCoreApplication running in the main thread for most of it's operations. I tested the translator without such an app, and it worked. So apparently for translations only the app is not required. However, depending on what you do in your dll, I think this is important to know.
If you need more details, feel free to ask.
I've been working on a Maven project consisting entirely of Java, and lately started to mix Scala code into it.
I'm amazed by the great expressiveness Scala offers, the easy use of scala-maven-plugin, and especially the incredible interoperability between Java and Scala.
However, I hit one inconvenience; according to the Maven's convention, Java's source code goes into src/main/java, whereas Scala's into src/main/scala. I found it quite cumbersome because I have to frequently go back and forth Java and Scala source files and every time I have to traverse the deep hierarchy of package directories (I often close tabs to keep my editor from cluttered).
So the question is: Is it recommended to maintain separate directories src/main/java and src/main/scala? If so, why?
To add more background, I've been working on the web application framework Wicket, whose convention is to put the HTML files alongside with their corresponding Java files. If we keep the directories separated, naturally the HTML files are separated as well (I don't think putting Scala files and corresponding HTML files in different directories makes sense). And then it goes "why I can't find Foo.html? Oh, I was looking for the wrong directory."
The source files themselves are very easy to distinguish both by humans and by machines by inspecting their extensions. I configured pom.xml to handle both Java and Scala put together in src/main/java and it worked (compiles and runs). On the other hand, separating directories poses a risk of defining conflicting classes in Java and in Scala, a careless mistake.
Well, I don't want to name a directory java if it contained not only Java's but also Scala's. But this is the only point I can come up with for separating directories.
(Edit: I've come up with a workaround-interpretation; let us think java stands for Java Virtual Machine. In this way, having src/main/c doesn't contradict if we ever decided to use JNI because C doesn't run on JVM.)
Oh, and one more point; my project is not intended as an open-source project; development convenience is preferred than trying hard to follow conventions.
This question is inspired by this answer.
I'd say yes, re-use code as much as possible. Maybe in future you can use this Java piece somewhere else...
As you probably know, you can use Java in Scala projects but not Scala in Java projects. So in this specific example it will help you with (future?) Java projects. If you want to re-use a piece of your Java code you can do that in either Java projects as well as Scala projects.
So i.m.h.o. it doesn't stop at the src/main/... but you should really put them even in different components.
Btw, little side note: if I'm correct, Wicket allows you to put the html somewhere else too, even in a different project... I saw it being handy (only) once, where we had to create different frontend for different clients of us. The java code stayed the same, the wicket-id's as well, but the html changed everywhere. Though it did give us some problems as well using the Qwicky plugin, as it could not find the html files in our IDE anymore.
In Android applications, resources are specified in xml documents, which automatically are built into the R class, readily accessible within the source code as strongly typed.
Is there any way I could use a similar approach for a regular Java desktop application?
What I'd like to accomplish, is both the removal of strings from the code (as a separation of "layers", more or less) and to make it easy to add support for localization, by simply telling the program to choose the xml file corresponding to the desired language.
I've googled around a bit, but the things I'm looking for seem to be drowning in results about parsing or outputting xml, rather than tools utilizing xml to generate code.
Eclipse's message bundle implementation (used by plugins for example) integrates with the Externalize Strings feature and generates both a static class and a resource properties file for your strings:
http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bundles.html
For this integration to work Eclipse needs to see org.eclipse.osgi.util.NLS on the class path. From memory, the dependencies of the libraries it was available in were a little tricky for the project I used this approach in, so I just got the source and have it as a stand-alone class in my core module (see the comments for more on that).
It provides the type safety you're looking for and the IDE features save a lot of time. I've found no downsides to the approach so far.
Edit: this is actually what ghostbust555 mentioned in the comments, but not clear in that article that this isn't limited to Eclipse plugins and you refer to your resources via static members of a messages class.
I haven't seen any mention of others using this approach with their own applications, but to me it makes complete sense given the IDE integration and type safety.
I'm not sure if this is what you mean but check out internationalization- http://netbeans.org/kb/docs/java/gui-automatic-i18n.html
Are you looking for something that parses XML files and generates Java instances of similar "struct-like" objects, like JAXP, and JAXB?
I came across ResGen which, given resource bundle XML files generates Java files that can be used to access the resources in a type-safe way.
http://eigenbase.sourceforge.net/resgen/
I'm a java programmer. I use bash scripts a lot for text processing.
Utilities like grep,sed,awk,tr,wc,find, along with piping between commands gives such a powerful combination.
However bash programming lacks portability, testability and the more elegant programming constructs that exist in Java. It also makes it harder to integrate into our other Java products.
I was wondering if anyone knows of any Java text processing libraries out there which might offer what I'm looking for.
It would be so cool to be able to write:
Text.createFromFile("blah.txt).grep("-v","ERROR.*").sed("s/ERROR/blah/g").awk("print $1").writeTo("output.txt")
This might be pie-in-in-the-sky stuff. But thought I'd put the question out there anyway.
Unix4j implements some basic unix commands, mainly focussing on text-processing (with support for piping between commands): http://www.unix4j.org
Example (Ben's example, but without awk as this is not currently supported):
Unix4j.fromStrings("1:here is no error", "2:ERRORS everywhere", "3:another ERROR", "4:nothing").toFile("blah.txt");
Unix4j.fromFile("blah.txt").grep(Grep.Options.v, "ERROR.*").sed("s/ERROR/blah/g").toFile("output.txt");
Unix4j.fromFile("output.txt").toStdOut();
>>>
1:here is no error
4:nothing
Note:
the author of the question is involved in the unix4j project
Believe it or not, but I used embedded Ant for many of those tasks.
Update
Ant has Java api's that allow it to be called from Java projects. This is embedded mode. This is a reference to And Api 1.6.1. Distribution should include docs as well.
To use it, you would create new task object, set appropriate parameters and execute it just as you would in build.xml but via Java Api. Than you can run your task.
Something like
ReplaceRegExp regexp = new ReplaceRegExp();
regexp.setMatch("bla");
regexp.setFile(new File("inputFile"));
regexp.execute();
You may need to set up some other stuff as well.
Not sure if it solves your problem, but Ant has a lot of code to do things. Just search through docs.
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.
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.
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.