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.
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 9 years ago.
I have been working on some Android apps recently and am slightly frustrated that my apps can be reverse engineered. I do obsfucate my code but that can only go so far, a talented developer can easily get around the obsfucation.
Anyway, my question is this, why can Java app's be decompiled ? What part of Java's design allows its app's to be decompiled?
My understanding is that Java apps deploy JIT compilation, so they are only compiled before they are used for efficiency purposes, is this correct ? I would love to know the reason,
thanks!
Anyway, my question is this, why can Java app's be decompiled ?
Any app, in any language, can be decompiled. That should be obvious to anyone with a smattering of programming experience in a compiled programming language.
A compiler takes bytes and creates a different set of bytes that represents the same set of instructions. A decompiler takes bytes and creates a different set of bytes that represents the same set of instructions. The difference is merely in what those bytes are. A compiler takes bytes that are (relatively) human readable and creates bytes that are (relatively) machine readable. A decompiler does the reverse.
How well a given decompiler can do its job, though, depends on the programming language and the implementation of the decompiler itself.
In the case of a language like C, the compiler generates machine instructions for a CPU. Those can be readily decompiled into assembly language, as assembler instructions map fairly closely 1:1 to machine instructions. A sufficiently sophisticated decompiler can emit C as output, though probably not C that would be natural to write. More importantly, the decompiled output will largely use decompiler-generated names for functions and variables, unless the compiled C code has debug symbols, in which case the decompiler might be able to use those.
A language like Java is not significantly different in concept. While Java or Dalvik bytecode is for a VM rather than a CPU, the basic approach is the same. Obfuscation helps to ensure that the minimum number of human-readable symbols exist in the resulting bytecode, to reduce the legibility of any decompiled results. Also, the mapping of VM bytecode to language statements tends to be far closer than the mapping of machine code to C statements, which makes it easier to write a decompiler that gives you closer to Java syntax back (e.g., smali/baksmali).
It is the degree of difficulty in interpreting decompiled machine code that results in recommendations to move license management logic into native code via the NDK, for example. However, that is not to say that the results of a C compiler cannot be decompiled at all.
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.
Java is designed to run in a “Sandboxed” environment in contrast to C which is not constrained. Discuss the implications of this from a security point of view.
I have done a bit of research in regards to the concept. What I found was if it's sandboxed where Java runs on, it goes through a more controlled door to retrieve information from different parts of memory. However, in C, it doesn't where it is uncontrolled.
Can someone please explain if there is anything else that I can add?
Edit:
This is what I have added:
Java programming language is an object-oriented language specifically designed to have as few implementation dependencies as possible. Java is write once deploy many times model. It is superficially like C/C++/C# but have different underlying object model. There are many versions of Java such as Java Standard Edition (Java SE), Java Mobile Edition (Java ME), Java Enterprise Edition (Java EE) etc.
The applications written in java are compiled to Java byte code which is an intermediate language independent of any platform. Thus, compiler can work multi platform.
The Virtual Machine model of compilation and execution works by running the compiled code (Java byte code) on Java Virtual Machine (JVM). Java Virtual Machine interprets java byte code and provides an environment in which Java byte code can be executed. The use of the same byte code for all JVMs on all platforms allow Java to be described as a “write once, run anywhere”.
This is better model than the compiler that generates native code due to following reasons:
Mobile devices come in various shape and sizes and with varying processor speed and architecture. Therefore, the virtual machine model of compilation and execution allows all java apps to run on various different mobile platforms once JVM is implemented on a device.
The virtual machine mode of compilation provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system, and allows a program to execute in the same way on any platform.
Performance comparable to compiled programming languages is achieved by the use of just-in-time compilation (a method to improve the runtime performance of computer program).
Compilation from byte code to machine code is much faster than compiling from source.
The deployed byte code is portable, unlike native code.
Since the runtime has control over the compilation, like interpreted byte code, it can run in a secure sandbox. Compilers from byte code to machine code are easier to write, because the portable byte code compiler has already done much of the work.
Don't mix languages and virtualisation.
Google's Native Client (NaCL) is a sandboxed environment for C/C++ (and everything else) programs, for example.
Here is a 'quick sampling' of the most common security challenges for sand-boxed code, off the top of my head.
In a sand-boxed app. restrictions will be added in the areas of:
Printing.
Cross-domain resource access.
Copy/Paste.
Import/export of resources from/to the local file system.
Applet calling System.exit(n).
Call applet methods from JavaScript..
Warnings attached to free floating elements. Which can even apply to tool-tips of apps. using 3rd party PLAFs.
Access to a variety of properties (e.g. user.*, any number of java.* props)
Load and use natives (that should be obvious).
Start processes.
Redirect output or error streams.
Record sound or video.
Access to the Robot.
..
If this question is about 'security', you have a lot of research to do. ;)
Java is inherently "sandboxable", whereas C++ et al are not. In Java there is no way to get outside of an object -- you can't freely cast an object pointer to char*, for instance, and you can't address beyond the end of an array.
Access to system facilities is limited by in several ways (some of which I forget just now). But basically one can run a Java program that loads secure class loaders and the like, and then any application that is loaded in that environment is "corralled" and cannot do anything that you don't wish to let it do.
(In fact, the "classic" JVM on IBM iSeries made use of these features to prevent even the "main" Java program from running amok. Java code ran in the same address space as the OS, but still the OS was protected by Java's inherent security.)
In C++ et al, in order to accomplish the same thing, you either have to make use of storage protection hardware or else have a compiler that compiles in checks of every access.
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.
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 10 years ago.
I always hear that programmers try to pick the right tool for the job. I've never programmed in Java, so I was wondering What are its benefits? Why is it so popular? What should I use it for?
I just program recreationally. Is there anything about it that makes it particularly fun??
I think after 12 years or so, the "write once, run anywhere" mantra is almost true. Writing Java code pretty much isolates you from the platform dependent aspects of the systems on which you deploy it.
Portability
Incredible breadth of libraries
Bottom-up security
Performance
Robustness
Massive communities, the amount of help, libraries, IDE's, is huge (and thats a good thing).
For a casual programmer Java can teach a lot about object-oriented programming, and encourage good programming habits in general, without the need to worry about as many of the "messy" details (pointers, memory management) as, say, C++.
It's also a bit easier to debug "catastrophic" errors.
Java is really good at integration - there are specifications and implementations for integrating with many kinds of systems that you're likely to run into in an "enterprise" environment.
It's not really a "fun" language relative to popular high-level languages.
This seems to be getting healthy answers, but you might also want to look at "Why do people use Java?"
Java is a good language, but that is secondary to the importance of the standard library that comes with it. The jdk may not be the most elegant kit ever built, but it is extensive, powerful and reliable. Programming in Java the language is simple. Programming with appropriate reuse of the jdk is what it is all about.
Cross platform is in my opinion the most relevant benefit.
The main goal of Java was to create a programming language that could run anywhere. The target was GUI apps. This however never happen because the environment was too slow at the beginning ( now it has been improved ) but it prove true in the server side where the cost of development reduced a lot because the product development can be done in PCs and the deployment in very expensive hardware.
It brought easy of development also, because it was designed to have C++ like syntax but running on a virtual platform to avoid platform specific code. At first the penalty was the execution speed, because it was interpreted, but release after release the interpreters became more and more faster that even MS model its next generation of development after java and call it .net
Additionally You can have a read of the Java design goals here
I want to add one point: Java keeps a good compatibility to earlier versions. That means, your Java-projects are compile and run in most cases without any problem on newer versions. That seems to be a little point, but this stability in API's and language helps to build a big community around Java, including good tool-support.
Others already mentioned other important points:
good portability
lot's of libraries for nearly anything
easy debugging and easy to catch problems
There are only two reasons to use Java:
The Java Virtual Machine (Hotspot).
The huge amount of available libraries and tools.
There are other languages that run on the JVM and make better use of Java libraries than Java does, however.
After using Java for some time, I've come to the conclusion that it's fun to write in, limited in some very irritating ways, and it's performance is good though it seems that many programs are crippled by poor design.
I'm not sure if the latter is a function of Java, or an effect of Java.
In either case, in addition to all of the above stated benefits it's very useful for doing "net" related things. Treating resources with a simplified interface regardless of "where" the particular resource is, etc...
It is by no means a universal hammer.
oop provides like encypsilation ,inheritance,polymorphism not available in traditional programing .oop is closer to real life presentation of the programming
1. Relation ships can be representation using inheritance
2. Programme developement become easy due to increased modularity