Other than the Java language itself, you have to learn the java framework. Similiar to how you have to learn the .net framework in addition to the language (C#/VB).
How important is it to know unix? Or rather, what unix areas should one focus on?
Seeing as many people run java based applications (desktop/web) on unix boxes, what sort of unix skills do you need? Are we just talking basic directory traversing, creating files, etc or is there much more to it?
The answer as read from Sun marketing material is that Java is cross platform, so you don't.
The practical answer is that you need to know enough to get your own application up and running on the platform where you plan to use it. Getting to know Apache or Tomcat configuration helps if you're working with web development, and so does knowing how to use the basic network analysis tools - the ifconfig, netstat and traceroute commands are all useful. File permission tools are also a must for getting a system working - look into chmod and chown and how those commands work.
Desktop systems have it easier, since most windowing systems are very good at working cross platform, but you still need to know a little bit about how the file system and permissions are structured.
Really, you don't need unix skills directly for writing java-based applications. However, if you want to develop java-based applications on unix boxes and deploy there, you want a good working understanding of how to operate and administer a unix box.
But for the areas you mention (directory traversing, creating files), you'll be using Java APIs that only occasionally touch on Unix-specific ("\n" vs "\r\n", directories rooted at "/", etc.) information. When they do touch, it's not something you need to know in a programming sort of way, it's something you need to know in a user/administrator sort of way.
Not important for the language it self.
You can learn java very well and never have touched a unix box at all.
If you want to deploy on a unix server however you should know just the basics.
File paths, new lines, permissions, etc. but the knowledge needed can be acquired after a few hours in the typing in the terminal.
Most of the os specifics are abstracted into the language from the beginning. Those that cannot be abstracted ( such as cron for instance ) are left behind.
You don't really need Unix skills to use Java, but if you do you'll have a good toolbox relevant for any kind of development. I certainly appreciate the ability to grep my entire source tree for files, use Perl for code generation and so forth. Even a simple matter of counting all lines of source code can be hard to do in a GUI only world. Knowing the basic Unix command line tools will make you a better developer imo.
I think your metaphor means you should learn Java library in addition to the language itself.
Certainly knowing UNIX will help a bit as it increases your general knowledge, but I don't think it's really directly related to Java at all.
As well as knowing how to traverse directories, you need to be able to edit and grep files. You need to know how do do some basic process management also. But the level of detail you need depends on what you want to do on a unix system. Eg. web development requires that you run a web container such as tomcat. You will probably want to learn the package manager of your system of choice.
It depends on your OS. You can do Java development on Windows in which case no Unix/Linux knowledge is required. That said, even on Windows GNU/Cygwin utilities can be helpful.
I assume that you are talking about learning and not developing a full scale project.
Because of the JVM, which by vision should provide a uniform API towards the programmers, regardless of the underlaying system, Java programs are meant to be written in a way that is not specific to the underlaying system (up to the point of using JNI etc').
That means that as a writer of small programs for learning,
your knowledge of the underlaying system should be minimal.
If you are not using IDE, you should at least know how to run 'javac', 'java' from the command line, and to test your program.
If you are Using an IDE like Eclipse, from the point that the IDE is running, you should expect an experience that is almost isolated from the system underneath.
However keep in mind that this is the vision, and it is always advised to know at least a bit about what's going on on your own system.
You don't need to know *NIX to develop a Java application, maybe if you're going to run it on a *NIX machine or if it uses something very attached to *NIX it'll be good if you know the basis about file names and permissions, for example.
The need of knowing *NIX comes with the need of deploying the app on a *NIX server. If this is the case it'll be good if you know something about system variables (set the JAVA_HOME, for example), the tipicall directory structure of a *NIX machine, and basic use (creating files, directories, deleting, symlinks...).
I think it's very good to know some scripting (bash, csh, sh). Depending of the complexity of the deployment this can give you extra points at the look of your boss for example.
Related
Recently I've been exploring the world of smalltalk dialects and am very impressed (from here on in understand that when I write 'smalltalk' I'm referencing any of the modern smalltalk dialects - squeak/pharo/etc). I like the small footprint of the VM and the language itself.
As grad student and often need to write tools that support my research. Typically I use Java because I can easily deploy a tool to my colleagues without worrying too much about what their computer setup is or how tech savvy they are. It's pretty easy to whip up a GUI interface and all the end user has to do is double click on an executable JAR and they are gtg. The problem is that Java has all sorts of security issues and doesn't always run in the same way on every platform. Smalltalk, therefore, is starting to look pretty attractive.
I know that it's possible to create a smalltalk program that fires up with one double click of an icon. What I'm wondering about is whether or not I can create a sandboxed smalltalk world such that the only thing the user sees and is able to interact with is my application. I don't want them to see any aspect of the smalltalk world. This way, users can't accidentally muck things up or get confused because they have access to a plethora of options that aren't directly relevant to use of the program. Is this possible, and if so, how do I do it?
Apologies - I should've done a better job of RTFM prior to posting this question. It is apparently possible to do this via Lockdown:
http://map.squeak.org/sm/packagebyname/lockdown
Also helpful:
http://wiki.squeak.org/squeak/3563
In Pharo, you can send openWorldWithSpec to your UI so that it is full screen. An example of this is the Pharo Launcher: https://ci.inria.fr/pharo-contribution/job/PharoLauncher. When you launch this image, you can't access the rest of Pharo (at least, not easily).
Suppose i want to search some text in a file. I want to know when we should use system utilities/programs like grep and when we should use Java API's like reading a line, and then search the text in that line or use java Scanner class.
I want to understand the trade-offs between the two approaches. I mean, suppose if we use grep, then will there be communication overhead between JVM and the grep process? Is creation of a new OS process for grep an overhead?
Does grep performs better than normal java file search?
Please help...
Yes, there will be an overhead. Starting an external process and communicating with it is costly. And moreover, many systems don't have a grep command. If you want to make your Java code portable, don't rely on OS-specific commands.
Another problem is that OS commands will be able to search (for example) in files, but not in your in-memory data structures.
You're basically trading off system independence for the perceived gain of the tool, in some cases this can't be avoid.
Not every system will have the tools you want installed, in the locations you think they should be or the version you need.
Even if you can deploy the tools with your application, you will need to provide an implementation for each of your targeted platforms.
Sure, it's easy to say "it will never be run on X", but can never come around real quick ;)
There is also the added over head of executing and managing the IO of the external applications, while not difficult, it's much more complex that a well written Java API.
As I said, sometimes, you simply don't have a choice (I have some media inspection tools that I use on Windows and Mac that I'm not about to try and implement in Java, not because it can't be, but because it's complex and time consuming and somebody has already done it (with a native program)).
You need to balance the choice over what the benefits are of the external command weight against the issues of using it. You should also investigate if a API has already begin developed that might solve the problem at hand.
IMHO
Is Java completely Platform Independent ?
if not then, what care needs to be taken to see that your code written in Java can run on Multi Platforms. Basically it should work on Targeted Platforms like Windows (Various versions), Linux (all flavors), Mac and Solaris.
While in practice, most compiled byte code is platform independent, my experience in my 12 years of developing on the Java platform has taught me that there are still idiosyncrasies from platform to platform.
For example, while developing a Java 1.4 Swing application for PC and MacOSX the behavior of dialogs was different if the parent frame is null.
Another example might be with working with the file system and files in general. The Java API has methods to help shield the developer from differences in path separators (/ vs \). When writing to a file, it important to use the FileWriter API as intended so that return characters and such are generated properly for the platform that it is being written on.
So while the motto is "write once, run anywhere" my experience has been for production envs it is write once, test, everywhere.
As a result, having strong unit and integration tests can help with this, as you can execute those tests on the various platforms you want to distribute your software.
Despite some minor issues here and there, it is cool to see your code running on Linux, Unix, Windows and MacOSX (BSD Unix) using the same JARs.
As djacobson pointed out, the answer is a qualified "yes". For the most part, Java developers don't have to worry about platform dependencies. However, you may run into problems when you're dealing with APIs that handle traditional OS and platform functions.
When dealing with File I/O, for example, it's easy to make your code platform dependent by ignoring the differences between file/path separators across platforms (i.e. using '\' rather than File.separator).
For the most part, yes. Because Java compiles to bytecode that's executed by its virtual machine, it can generally be expected to behave the same way regardless of the system sitting under the virtual machine.
However. Not even virtual machines are immune to bugs. A quick Google search turns up the following, for example:
http://www.ibm.com/developerworks/java/library/j-diag0521.html
Differences in behavior can vary from JVM to JVM. Hopefully you won't end up with code that depends on any of these cases... but careful research is worthwhile to know what the limitations of your infrastructure are.
You problem will not be executing your code, but more likely the assumptions you have to make about file paths, available external commands (if you need them), necessary file permissions and other external factors that don't really fall under the "Java" problem domain. Unless you're planning on using native code (via JNI) extensively, Java will not be your problem, your environment will.
Which brings us back to the old adage: "write once, test everywhere".
Threading priorities is one thing to consider. Other OS like Solaris for example has more thread priorities than windows. So if you are working heavily on multi-threading, OS is something that may affect the program's behavior.
The main thing to be concerned with is UI code, to make sure that it is represented properly on all the platforms you will be running on.
Another source of possible issues is deploying to different app servers. There might be incompatibility issues between them.
Java other than that is platform independent, This is also one of its weaknesses, since you are coding to a common denominator and many features of each individual OS are not available.
There are very few and they should be pretty obvious. like System.getProperty("os.name") is clearly OS dependant or it wouldn't work. The most common one is System.exec() as it calls another application which is on your system, again you should know if the application you are calling works the same on every system or not (unlikely).
Along with the above concerns, the main problem I had was actually building on different platforms, which may not be what your asking, but may be something to watch out for.
OS X is especially guilty of this when using the Apple Distribution of Java (why anyone would want to put out their own packaging of Java I don't know but that is a separate argument, and on OSX i dont think you have a choice but to use their java). The Libraries that you may or may not be relying on are in completely different directories, eg libraries instead of lib if my memory serves me correctly. And the IBM java I think packages Classes in different Jars in some cases. Ridiculous!!
Hope that helps.
I'm trying to make an java application to manage Linux servers from a web interface.
It is a bad idea to perform each task by calling bash shell ?
Are there any other options other than those to use C, Perl or another language?
It's not necessarily a bad idea to use bash to do the actual work. It would help if you gave us more of an idea what exactly the web interface was changing.
Java in particular does not provide much system-specific controls, because it was designed as a cross-platform language, so putting specific platform tools in would go against it's purpose.
You could certainly do it that way. Ideally you'd open up a port and accept specially crafted, specific actions which perform only the intended actions (an interface server) through a socket library.
I should think that the disadvantage(s) of calling Bash scripts for your commands is all related to error handling and return values. Each of your Bash scripts will need to return sensible, useful information to the Java app in the case of failures (or even successes). And you'll probably want a common interface for that such that each Bash script, no matter its function, returns the same types so that the Java can interpret it easily.
So, in that sense, making the changes from your Java program reduces the complexity of handing the information back and forth. On the other hand, if Bash is easier for you, you may find it more fast and flexible.
Opening up a single bash shell and sending commands (and properly parsing results) shouldn't be bad. It does tie your program to a single OS and even a single shell, but that's the nature of what you are trying to do.
What I wouldn't do is open a shell for each command and close it after each result. It seems to me that would cause unnecessary thrashing when many commands were executed in a row.
Security concerns jump at me. If you have a form like "type command" then someone clever could exploit some things. For example "configure network" is fine but "configure network; install rootkit" can be typed because a semi-colon allows commands to be chained.
All in all, this is not tight integration. If this is a personal project, go for it. It's a good learning project to turn a procedural script into a java program. If this is a serious effort to recreate the many various webapp admin tools there are, I'd seriously suggest skipping this. The VPanel/CPanel things I've seen I hate. There used to be a php based linux admin thing that looked ok but I just find them easily to learn, easy to outgrow because the net and community is full of command line knowledge.
If you are trying to automate a large deployment, look at the ruby-based puppet. It looks really neat.
I have a socket server were I perform different operations (using ifconfig by calling shell for example) and I plan to integrate an client in a JSF application.Because I'm not experienced ant I intend to make it my graduation project, but I'm not so sure if calling bash from java to configure a linux box is a good solution.
Java does have some Linux-configuring classes (well, at least, OpenJDK does). Check OperatingSystemMXBean or something like that.
You're beter to write your own server configuration utility in the language you prefer, sanitize it, make it secure and then call it via bash from your java app.
There are two questions here:
Should you try to do the configuration work in Java, or should you externalize it?
Assuming that you have externalized it, should you use bash scripts.
In this case, the answer to question 1) depends. This kind of thing can be difficult to implement in pure Java. This leaves two choices; externalize the task using a Process, or try to do it in a native code library via JNI or JPA. The latter approach is complicated and gives you JVM crashes if you make a mistake, so I would rule that out.
On the other hand, if you can find a good standard or 3rd party Java API that does what you need (without infesting your JVM with flakey JNI, etc), you should use that.
The answer to 2) is that bash scripts will work as well as any other scripting language. I think that using scripts gives you a bit more flexibility. For example, if you need to do things to compensate for differences in the different flavours of Linux, UNIX or maybe even Windows (!) you can put this into the externalized scripts. (A corollary is that the scripts need to be configurable, so don't embed them in your source code!)
Another alternative might be to run the commands (e.g. ifconfig) directly, using a fully qualified command name and supplying the arguments as an array of strings, etc. But unless your app is going to run the external command 100s of times a minute, it is probably not worth the (Java) coding effort and the loss of flexibility / configurability.
A lot of the response would depend on why you're doing this and why other more obvious solutions aren't possible. Knowing why you would choose to roll your own as opposed to installing Webmin would be good, or why you're choosing to use Web UI at all as opposed to VNC to control the box. There are some obvious responses to the later (firewall issues for instance), but there's no immediately obvious reason for the former. Without knowing more about the requirements, answering questions about implementation details like bash scripts versus perl or C is meaningless.
I wanted to ask if there are any other Write Once, run anywhere languages like Java or AIR. I have mostly been a Java developer up till now, and a bit of Python and recently AIR has peaked my interest as I just found out about it.
Also I wanted to know if there are any unrar libraries for AIR or someway to read RAR archives with AIR, kind of like how you can with FZip and zip files. Kinda want a solution better than including binaries for Win/Lin/OSX with my program and using those based on the system.
Also I don't mind a compiled language as long as I can write 1 set of code, and it can be compiled to all the platforms with minimal to no changes. Kinda want to not use any OS Specific code or APIs, its why I asked for runtime languages like AIR or Java. Well Python is too, but it requires a bit of OS specific coding for file management.
Perl is also write once run everywhere.
I can recommend Lua. It is very similar to Python, lightweight and very portable.
YMMV depending on what you want to do with the language. If you're looking for a language with lots of bells and whistles you're probably better off with Python. That said, there are a lot of bindings for popular libraries available at LuaForge
I may suggest this Java API to un-rar file