As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have a Java server process that I normally run in either Windows batch file consoles or in Linux Bash script consoles. I manage these scripts independently of each other and I wish I had something that was cross platform, more powerful, and easier.
Besides running the java process itself, the scripts need to create files, configure files, read/write .xml config data, prepare databases, etc.
So, which scripting language would be the best for this that would allow the script to go cross platform?
Also, if you have heard of someone doing something similar to this, I would love a link to see the example.
Edit to actually phrase this as an answer:
Just use Java.
Is there a reason that you can't write that stuff in Java as well, and just have some different functions for the few things that aren't cross-platform?
Second edit is a counter-example. My company has a dev team that writes cross-platform Java code, but the scripts for running/upgrading it are written in .SH and .BAT, depending on if it will be Windows or Unix. So they write it twice, in the lowest-common-denominator for the two target platforms.
I think Groovy would be a great choice. It's syntax is very similar to Java, but it is much more concise (than Java), particularly for the kind of things you need to do in scripts. For example, here's a Groovy script that reads the content of a file:
String content = new File("/path/to/file.txt").text
That's it! There's no need to put it inside a class or even compile it. Just put the text above in a file named Script.groovy and invoke it from the command line using groovy Script.groovy.
Also, because Groovy runs on the JVM there should be no cross-platform issues, and you'll already have the necessary runtime installed on all the machines you need to run your scripts on.
Groovy comes with a console that you can use to quickly test out your scripts.
You also might want to consider putting the "script" stuff in a Jruby script and then having it invoke your Java apps and libraries when necessary. That would work fairly well. The downside is that you would need to maintain a Jruby runtime on all of your servers.
Correct me if I a mistaken, but isn't the point of things like Ant to have a build process in Java itself? I feel that if you had a standardized Java build process that did these things for you, your batch file, bash script, or the necessary derivatives could be much, much simpler. Then again, IANAJDNEC (I am not a Java developer, not even close).
We did similar thing by ensuring all machines have cygwin. The scripts becomes more portable. Now trying to replace the shell scripts with perl scripts.
We also moved most of the functionality into java code.
If this about managing an environment, I recommend jenkins farm. It has many builtin task, you may reduce your scripting effort. One of the main feature is to deploy jdk on all machines transparently and then start java tasks there.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
As I know a java developer, need to let their .java file to become .class, and the .class requires the JVM to convert to native code to execute. Why the Java design in this way? Why don't just as a scripting language, using a interpreter, to interpreter .java file? or why don't just convert it to executable like C? Why need to convert to bytecode? What is the design philosophy behind the java language?
It is for sake of speed and portability at the same time.
All of what I am going to say is to be adapted and moderated depending on the case, but roughly:
If you merely interpret the java file with an interpreter you
would have portability but not speed.
If you have to compile the code for a given processor
architecture you would have speed but not portability.
With the bytecode, you compile the code (into bytecode) for a common
machine that will execute it (the JVM) it is a compromise between
speed and portability.
Why the Java design in this way?
Write once, run everywhere - portability.
Why don't just as a scripting language, using a interpreter, to interpreter .java file?
Performance. Bytecode can be compiled to native code with some aggressive optimizations, not available for normal compilers.
or why don't just convert it to executable like C?
Because different platforms require different executable binaries. Java bytecode is (again) portable.
Why don't just as a scripting language, using a interpreter, to
interpreter .java file? or why don't just convert it to executable
like C? Why need to convert to bytecode?
I think the intention was to have
1) Compile time safety
2) Write once, run anywhere.
If you converted to an executable like C, you would lose #2. In a sense, the JVM is an interpreter, so Java bytecode in interpreted, while Java code code is compiled.
Why don't just as a scripting language, using a interpreter, to interpreter .java file?
Suit yourself.
or why don't just convert it to executable like C?
Because that won't work cross-platform. A Portable Executable (used on Windows) won't run on, say, Linux or iOS, at least not without tricks.
A simple comparison can be made by thinking of sockets and file access. How would you do that on different platforms, with one executable, without the JVM?
Interpreting (and compiling) byte code is faster than interpreting raw java.
Byte code is portable. You can compile on Windows, and run the byte code on Mac or Unix.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
To my experience, most of java applications on desktop platforms are less responsive than a similar application written in c++ or some other natively compiled language. Which is understandable considering that java only compiles to intermediate language.
And by responsiveness here I mean the general feel of how the application responds to mouse clicks and keyboard events, the little lags between the user clicking somewhere and the program actually redrawing all the needed things to represent the response to that click. Most often these lags are so small that you don't see them as lag, but you get a feeling that the whole aplication gets a little slow.
Examples of such java applications that I would see as less responsive are Azureus, java-based versions of Zend studio, Eclipse, and a couple of my own swing-based java projects.
Is this really the case? Can a java application ever be as responsive as a native application? Should it perhaps be compiled in some different way? (although you would think that if that was possible, big products such as Zend studio would do that already)
Application responsiveness in Java is frequently down to bad/inefficient programming. While a Java UI is heavier than one written in C/C++, on a recent computer (last few years or so) shouldn't struggle with a well coded application.
Most recent benchmarks show Java 1.6 to be of comparative speed to C/C++ (infact in the last cross language benchmarks I saw it sat snugly between the two in terms of performance).
I think a symptom of Java and the IDEs people use to write it is that it is a forgiving language that lets you do things the wrong way (read, less good way), without complaining too much while C++ would just fall over, forcing you to write better software.
As a personal note, I've seen Java applications where the devs attached a single listener to every element in the UI, then that listener had an enormous if...elseif...elseif... to check the tooltip string that was passed back from the event object.
javac compiles to an intermediate byte code. However the JVM compiles to native code based on how the code is used dynamically (something static compilers cannot do) For GUIs most of the real work is done in native code components so you shouldn't see a real difference.
Many real time trading systems are developed using Java and respond in less than 100 micro-seconds. i.e. 0.0001 seconds. If you have a responsiveness issue, its not the language at fault.
BTW: Eclipse uses SWT which is a native library.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
The JIT compiler has been around for some time. Occasionally it comes to my mind that, "hey, why not just compile Java source file directly to machine code?"
Along with compiled library, we can get rid of the cumbersome JVM.
The only barrier I can think of is the garbage collector. How's your thoughts?
PS: Oh, you say portability? WTH is that? Plus, I'm forced to install a JVM in the first place.
Well, my friend uses Ubuntu, and I use Windows XP, and my other friend uses OSX.
When I send them a jar that I compiled they can both run the file without any changes.
That is why you should not get rid of the JVM.
vm can do complex optimizations based on information only available at runtime. Static compile time optimization simply can't compete. Java is fast because it is running on the vm.
watch this
http://www.infoq.com/presentations/Towards-a-Universal-VM
On some platforms (mostly embedded ones), it's just as you say (or else the machines speak java natively). You can also download compilers that do what you are suggesting, but I imagine you lose a lot of the Java API in the process.
Back to your question, the main reason why is that the people who design the languge and specification want to have it. Plain and simple. It offers portability in the consideration that the "hard" part of making portable code supposedly only has to be done once per environment (another poster spoke of 3 different OS's running the JVM) rather than once per each environment per project. Have you ever tried to make even mostly-portable C++ code without the aid of frameworks like Qt or packages like Boost? It gets VERY difficult, and even then you must still re-compile for each architecture.
Beside portability another issue that comes to mind is dynamic classloading which is difficult to handle via machine code. How would servlet containers work in such a scenario? Maybe it works well for embedded Java, but I don't think for J2EE.
Would the .class form just be an intermediate binary that is converted to machine code before execution? Or would you directly compile from Java source to machine code?
Bytecode generation is necessary for platform independence of code.
JVM (JVM is different for all platforms) reads these bytecode and converts these into machine code depending upon which platform its running. This makes Java compiled code platform independent. JVM also does optimizations which makes Java fast.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is your preferred scripting language in java world (scripting language on JVM) and way? When do you prefer your scripting language over java (in what situations for example for prototyping)? Do you use it for large projects or for personal projects only?
For me, Clojure wins hands down. Being a Lisp, it's concise and dynamically typed, it has enormous expressive power so I can write a lot of functionality in a few lines. And its integration with Java is unsurpassed – I'm only partly joking when I say Clojure is more compatible to Java than Java itself. As a result, the entire breadth of Java libraries, both from the JDK and 3rd party, is fully useable.
Finally, with a little care Clojure code can be as fast as Java code, so I'm not even losing performance.
My favorite is Jython, and I use it by embedding a Jython interpreter in my Java application. It is being used in commercial projects, and it allows to easily customize the application according to the customers' needs without having to compile anything. Just send them the script, and that's it. Some customers might even customize their application themselves.
I've successfully used Groovy in a commercial project. I prefer scripting languages because of duck typing and closures:
def results = []
def min = 5
db.select(sql) { row ->
if (row.value > min)
results << row;
}
Translation: Run a SQL query against the database and add all rows where the column "value" is larger than "min" to "result". Note how easily you can pass data to the inner "loop" or get results out of it. And yes, I'm aware that I could achieve the same with SQL:
def results = []
def min = 5
db.select(sql, min) { row ->
results << row;
}
(just imagine that the String in "sql" has a "?" at the right place).
IMHO, using a DB with a language which doesn't offer rich list operations (sort, filter, transform) and closures just serves as an example how you should not do it.
I'd love to use Jython more but the work on Jython 2.5 has started only recently and Python 2.2 is just too old for my purposes.
I might prefer Scala, but I can't say, still learning. At the moment using Groovy to write small utility programs. Haven't tried even Groovy on Grails. Heard lots of good about Lift Framework for Scala as well.
JavaScript Rhino has a compelling advantage -- it is included with the JDK. That being said, later versions of Rhino than the one with Java 6 have nice features like generators, array comprehensions, and destructuring assignment.
I favor using it whenever the ceremony of handling Java exceptions clutters up the code for no real benefit. I also use it when I want to write a simple command-line script that takes advantage of Java libraries.
Java. Seriously. It's a powerful, easy-to-use (if a tad verbose) language that everybody knows. The integration with Java is great.
The company I work for embeds Groovy into a Java/Spring website, which is deployed on a number of sites. The scripts are stored externally of the compiled WAR file, and allow us to manipulate some of the site logic without having to roll out new WAR's to each site. So far, this approach has worked very elegantly for us.
A particularly nice feature of Groovy is that it can closely resemble Java code, which makes it very easy to port existing Java classes to it.
How about SISC (Second Intepreter of Scheme Code)?
REF: http://sisc-scheme.org/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The standard answer is that it's useful when you only need to write a few lines of code ...
I have both languages integrated inside of Eclipse. Because Eclipse handles the compiling, interpreting, running etc. both "run" exactly the same.
The Eclipse IDE for both is similar - instant "compilation", intellisense etc. Both allow the use of the Debug perspective.
If I want to test a few lines of Java, I don't have to create a whole new Java project - I just use the Scrapbook feature inside Eclipse which which allows me to "execute Java expressions without having to create a new Java program. This is a neat way to quickly test an existing class or evaluate a code snippet".
Jython allows the use of the Java libraries - but then so (by definition) does Java!
So what other benefits does Jython offer?
A quick example (from http://coreygoldberg.blogspot.com/2008/09/python-vs-java-http-get-request.html) :
You have a back end in Java, and you need to perform HTTP GET resquests.
Natively :
import java.net.*;
import java.io.*;
public class JGet {
public static void main (String[] args) throws IOException {
try {
URL url = new URL("http://www.google.com");
BufferedReader in =
new BufferedReader(new InputStreamReader(url.openStream()));
String str;
while ((str = in.readLine()) != null) {
System.out.println(str);
}
in.close();
}
catch (MalformedURLException e) {}
catch (IOException e) {}
}
}
In Python :
import urllib
print urllib.urlopen('http://www.google.com').read()
Jython allows you to use the java robustness and when needed, the Python clarity.
What else ? As Georges would say...
Python syntax (used by Jython) is considerably more concise and quicker to develop for many programmers.
In addition, you can use existing Python libraries in a Java application.
Analogy: Why drink coffee when you can instead drink hot tap water and chew on roasted bitter beans. :-)
For some tasks, Python just tastes better, works better, and is fast enough (takes time to brew?). If your programming or deployment environment is focused on the JVM, Jython lets you code Python but without changing your deployment and runtime enviroment.
I've just discovered Jython and, as a bit of a linguist, I think I'd say it's a bit like asking "why use Latin when you can use French" (forgetting about the fact that Latin came before French, of course).
Different human languages actually make you think in different ways. French is a great language, I've lived in France a long time and done a degree in it. But Latin's startling power and concision puts your mind into a different zone, where word order can be swapped around to produce all sorts of subtle effects, for example.
I think, from my cursory acquaintance with Jython, which has really fired up my enthusiasm by the way, that it's going to make me think in different ways. I was very sceptical about Python/Jython for some time, and have been a big fan of Java generics for example (which ironically reduce the amount of typing and therefore "latinise" the French if you like). I don't quite understand the full implications of "dynamically typed" languages like Jython, but I think the best thing is to go with the flow and see what Jython does to my mind!
It's funny how languages come and go. Another "Latin" might be considered to be Algol68 with its infinitely recursive syntax. But the need to develop massively recursive code, and the capacity to read it and think in it, has not (yet) made itself felt. Jython seems to be a very powerful and elegant fit with where we are now, with OO libraries, the power of Java swing, and everything wrapped up in a very elegant bundle. Maybe one day Jython will adopt infinitely recursive syntax too?
I use Jython for interactive testing of Java code. This is often much faster than writing Java test applications or even any scripting language. I can just play with the methods and see how it reacts. From there I can learn enough to go and write some real code or test cases.
Using Python is more than "syntactic sugar" unless you enjoy writing (or having your IDE generate) hundreds of lines of boiler plate code. There's the advantage of Rapid Development techniques when using dynamically typed languages, though the disadvantage is that it complicates your API and integration because you no longer have a homogeneous codebase. This can also affect maintenance because not everybody on your team loves Python as much as you and won't be as efficient with it. That can be a problem.
Some tasks are easier in some languages then others. If I had to parse some file, I'd choose Python over Java in a blink.
Python has some features of functional programming, such as lambdas. Java does not have such functionality, and some programs would be considerably easier to write if such support was available. Thus it is sometimes easier to write the code in Python and integrate it via Jython that to attempt to write the code in Java.
Python libraries ;) For example BeautifulSoup - an HTML parser that accepts incorrect markup. AFAIK there is no similar pure Java lib.
No need to compile. Maybe you want to get something rolling faster than using a compiled language, like a prototype.
...and you can embed the Jython interpreter into your apps. Nice feature, I can't say I've used it, but tis cool nonetheless.
Jython can also be used as an embedded scripting language within a Java program. You may find it useful at some point to write something with a built in extension language. If working with Java Jython is an option for this (Groovy is another).
I have mainly used Jython for exploratory programming on Java systems. I could import parts of the application and poke around the API to see what happened by invoking calls from an interactive Jython session.
Syntax sugar.
In your situation, it doesn't make much sense. But that doesn't mean it never does. For example, if you are developing a product that allows end users to create extensions or plugins, it might be nice for that to be scriptable.
Porting existing code to a new environment may be one reason. Some of your business logic and domain functionality may exist in Python, and the group that writes that code insists on using Python. But the group that deploys and maintains it may want the managability of a J2EE cluster for the scale. You can wrap the logic in Jython in a EAR/WAR and then the deployment group is just seeing another J2EE bundle to be managed like all the other J2EE bundles.
i.e. it is a means to deal with an impedance mismatch.