We Keep Coding

Is there more overhead in Java than in C# because of its crossplatform ability?

Someone told me there was more overhead for Java because you can essentially run it on most operating systems and that C# doesn't have that overhead so then it can execute at near C++ speeds.
So is there more overhead in Java, or does each OS has it's own overhead for it's JVM implementation?

C#, Java (and I'll toss it in there too - JavaScript) are languages. Languages are not fast or slow, they just are specifications for how we humans write things that are to eventually be handled by a computer.
The JVM is the Java Virtual Machine. But there are several different versions of it. There's HotSpot (the original), OpenJDK, And then one can look at JRockit from BEA, Apache Harmony and a bunch more.
For C# there is the CLR, but there's also Mono's runtime. There are also others that have been abandoned over time.
JavaScript (because I'm tossing that in there) has an entire army of runtimes. Some of those runtimes are faster than others.
It is the runtime that is faster or slower than another - even possibly for the same language. But that one is 'cross platform' and another is not is not enough of an indication to say that one is faster than the other. There are a great many other things at work and benchmarks can be constructed that show one combination being faster than another for each one.
Going even further, one can look at languages that span multiple runtimes. You've got Python with CPython as its default implementation - but there's Jython that runs in the JVM and IronPython that runs in the CLR. Similar examples can be found with Ruby, IronRuby, and JRuby or Clojure which can be compiled to JavaScript via ClojureScript and then run on one of the JavaScript runtimes rather than a JVM.
Again, its not the language that is fast or slow - but rather how its implemented in its runtime.

The Java language and the Java Virtual Machine (JVM) are completely separate entities. Oracle has done an excellent job of separating the two, so that other languages (like Scala or even Ruby) can run on the JVM.
The Java language itself is definitely written with the intent of targeting the JVM, but, so far as I know, there is no actual requirement that it must. So far as I know it's completely possible to write a Java compiler that generates native code, rather than Java bytecode. (This is all completely hypothetical. I've never heard of anyone actually doing that - there would be very little point. Current implementations of the JVM tend to be almost as fast as native code, and any benefit gained by this would be greatly outweighed by the loss of portability it would entail.)
The situation is further complicated by the fact that C# doesn't exactly have a VM, as discussed here. So the best comparison you can make is "does this implementation of the JVM run this Java code faster than that implementation of the .NET framework runs that C# code?"
In the end, unless there is a remarkable speed difference for very similar code, the comparison just isn't that compelling because there are too many variables. Use a different JVM, or a different Java compiler, or a different .NET implementation, or a different C# compiler, or run the same code on a different machine, and the numbers change.

Can c++ code read java .class files?

I have been working in java for a while now, and want to learn how c++ works when it comes to compilation and executed.
I was wondering if there is a way to convert compiled c++ class into .class files in java and vice versa. I am interested in a single format that can be used both by java code as well as c++ code that can be directly executed to see the results.

Almost everything can be done if you are ambitious and stubborn enough, however, the question lies usually in time and cost and features..
In its core, Java language is a subset of C++. There are some syntactic sugars added that may make you feel that there is "something more", like anonymous class implementation or hidden pointers to outer classes, but it is just a thin layer of syntax, which is irrelevant once the code gets compiled.
After compilation, C++ code is represented by machine code. Java's bytecode of course is translatable to machine code - simply by the fact that JVM executes it and that the jitter can recompile it on the fly into machine code..
So, roughly speaking, every Java code, compiled or not, is translatable to C++.
However, there are some code constructs in C++ that can be compiled into machine code, but that maybe are representable in Java's bytecode, but that cannot be represented back in the Java language. There are lots of it: from some easy to go around like passing parameters as references, to more complex ones like pointer (TheList->) arithmetics, to some really painful to translate like multiple inheritance, custom memory management (that is, overloaded operators new and delete), or some wicked types like unions.
So, clearly, C++ code is not translatable to Java. Clearly, C++ compiled code is even more not translatable, as C++ compilers often optimize the products thorougly, so that it is very hard to guess what was the 'classes' or 'functions' like..
However, if you limit the C++ language, and restrict yourself to not use any of those hard-to-translate constructs (see 'TheList'), then you can make the C++ code translatable. Again, code, but not binaries.
This is not all though. The 'translatability' is one thing, but the other is: will it run? The most distinctive runtime difference is the GarbageCollector. Let's say you actually managed to translate some Java code into C++, and you lined it up with C++ application. Your Java/C++ code executes and creates some objects. Who will clean them up? Typically, there's no GC in C++. Your Java code will therefore leak -- or you will have to provide/implement some kind of GC for the Java/C++ code.. Not pretty. Of course you can limit Java code to not create any objects, d'oh.
Do not get me wrong: even those hard-to-translate things like pointer arithmetics etc are translatable: you can generate tons of helper/wireup code that will replace them with 'proper things of the second platform'. It will, however, be ridiculously complex and slow. I don't think anyone sane will ever try.
So, the only thing that would seem to be left available is very-limited-C++-code <-> somewhat-limited-Java-code. If we cut down the question to this, then yes, that should be translatable. But..
What does it mean to translate code? How'd you do it? You have to read, process, analyze the source code, and then somehow produce the other code in the other language. Well, ok. Producing code is simple, it's just text. But, have you ever tried to analyze code? Long story short, let me just tell you that reading/parsing Java code is at least an order of magnitude easier that reading/parsing C++ code. Java was partly desined to be easily parsable by relatively simple algorithms. If you drop any attempts to optimize, writing a Java parser/compiler is relatively simple thing. On the other hand, C++ was not. Like Java, to parse C++ properly you'd have to effectively create a custom C++ compiler, but also a preprocessor. To some extent, you might also need to implement some parts of the linker. To make thins a little worse, C++ evolved from older languages and is literally packed with some once-in-your-lifetime-used features that make the syntax really difficult to accurately process (ie. have you ever used alternate token set? ..and this is only beginning:)). Do not get scared too much, though! I just want to give you a feeling what you try to touch. You probably would'nt need to write it. Such already tools exists, both for Java (really many, actually) and for C++ (few, and I bet the reasonable ones are not-fully-for-free.. or maybe you could use the GCC toolset probably..). They produce machine-processable representations of the sourcecode, and if you really want to do some translating job, I'd suggest you start there.
Of course my knowledge can be off by a few years, and maybe someone already has written some moreorless working translator - I'd love to see it!
If not, I think it is not worth it. Try embedding Java's runtime in your C++ app, or talk from Java to C++ DLLs via JNI. It is much simplier!

Compiled C++ code is loaded by the OS. That is, the C++ linker generate OS dependent executable modules. Whereas Java .class is loaded by the JVM. JVM executes Java byte code.
If you want to make a Java byte code loader/runner, you could start from JVM source code.
=> link
If you are aimed to load/execute compiled C++ code in Java envirionment, following are required.
(Assuming 32bit Windows platform)
. PE parser/loader => link
. X86 CPU instruction parser(?) => link
. X86 instruction to Java byte code translator
In short, its almost impossible.
For simple C/C++ vs. Java interoperations, JNI will do. link

I think, JNI will be useful:
"The Java Native Interface (JNI) is a programming framework that enables Java code running in a Java Virtual Machine (JVM) to call, and to be called by, native applications (programs specific to a hardware and operating system platform) and libraries written in other languages such as C, C++ and assembly."
Here are good tips how to program a simple example of using the Java Native Interfac (write a Java application that calls a C function).

Converting already compiled C++ code to JVM bytecode is not an easy task, especially if you want to be able to use compiled C++ code from multiple platforms.
It will probably be easier to make a JVM-backend for clang instead. The drawback here is that people who wants this functionality must use your compiler.
In short, if you want to write code targeting the Java virtual machine, then use a language and compiler already made to do it. Like Java...

Why does Java code need to be compiled but JavaScript code does not

How come code written in Java needs to be compiled in byte-code that is interpreted by the JVM, but code written in a language like JavaScript does not need to be compiled and can run directly in a browser?
Is there an easy way to understand this?
What is the fundamental difference between the way these two languages are written, that may help to understand this behavior?
I am not a CS student, so please excuse the naivete of the question.

Historically, JavaScript was an interpreted language. Which means an interpreter accepts the source code and executes it all in one step. The advantage here is simplicity and flexibility, but interpreters are very slow. Compilers convert the high level language into a lower level language that either the native processor or a VM (in this case, the Java VM) can execute directly. This is much faster.
JavaScript in modern browsers is now compiled on the fly. So when the script is loaded, the first thing the JavaScript engine does is compile it into a bytecode and then execute it. The reason the entire compilation step is missing from the end user's perspective is because browser developers have (thankfully) maintained the requirement that JavaScript is not explicitly compiled.
Java was from the getgo a language that always had an explicit compile step. But in many cases that's not true anymore. IDE's like IntelliJ or Eclipse can compile Java on the fly and in many cases remove the explicit compilation step.

JavaScript and Java are not the same thing. They might share a similar name, but I refer you to the JS guru - Douglas Crockford to help clear up the fact that they are really not related at all.
The reality is that there is nothing stopping Java being an interpreted language, and there's equally nothing stopping JavaScript being a compiled language (Chrome's javascript engine does do compilation to improve speed, and does a very good job of it).
In the context of the browser, Java runs in the same way as Flash or Silverlight - a plugin is required and the browser acts as a host to that plugin; which hosts a Java runtime environment.
Javascript was designed to be a scripting language for the browser, and that's why the browser can understand it natively. How the browser actually achieves the running of that code, however, is entirely up to the browser. That is - it can operate purely at a script level, assuming zero-knowledge of the next line of code and running a purely software-based stack; or it can perform some JIT to get the code closer to the hardware and (hopefully) improve speed.

Any language can be compiled and interpreted. In both cases, a piece of software has to read the source code, split it up, parse it, etc. to check certain requirements and then assign a meaning to every part of the program. The only difference is that the compiler then proceeds to generate code with (almost) the same meaning in another language (JVM bytecode, or JavaScript, or machine code, or something entirely else) while the interpreter carries out the meaning of the program immediately.
Now, in practice it's both simpler and more complicated. It's simpler in many languages lend themselves better to one of the two - Java is statically-typed and there is relatively little dynamic about the meaning of a program, so you can compile it and thus do some work which would otherwise need to be done at runtime. JavaScript is dynamically-typed and you can't decide a lot of things (such as whether + is addition or concatenation) until runtime, so compilation does not afford you much performance. However, a mix of compiler and interpreter (compile to simplified intermediate representation, then interpret and/or compile that) is increasingly popular among dynamic language implementations. And then there's the fact that modern JavaScript implementations do compile, and in fact V8 never interprets anything.

Because of the being complexity of compiling level between Java and Javascript, there are some limitations in Javascript. Since bytecode is executed on JVM platform which is written for specific OS and Hardware bytecode execution has more advantages to access system resources. Even C code can be embedded into Java bytecode aswell. On the other hand Since Javascript is only run on browser there is less to do with it.
there are two main part at Java platform. Java programming Language and JVM. It makes each part focus only their own area. That is why JVM doesnot dedal with Java programming syntax. It is similar to that when running C code linking does not deal with C code but assembly.
Bytecode in JVM platform is likely an assembly in C.
Eventually all representations are converted into binary representation and then the electirical signals somehow. It proves that we need programming levels.

What kind of things can be done with Java but not Python?

I would to pick up a new programming language - Java, having been using Python for some time. But it seems most things that can be done with Java can be done with Python. So I would like to know
What kind of things can be done with Java but not Python?
mobile programming (Android).
POSIX Threads Programming.
Conversely, What kind of things can be done with Python but not Java if any?
clarification:
I hope to get an answer from a practical point of view but not a theoretical point of view and it should be about the current status, not future. So theoretically all programming languages can perform any task, practically each is limited in some way.

Both languages are Turing complete, both have vast libraries, and both support extensions written in C so that you can access low level code if needed. The main difference is where they are currently supported. Java in general has wider support than Python.
Your example of Android is one place where Java is the standard choice, although Python also has some support in the form of Android Scripting Environment. Java is already installed on most home computers. You can write Java applets and expect them to work in most browsers.
One thing you can't easily do in Java is quickly write short scripts that perform useful tasks. Python is more suitable for scripting than Java (although there are of course other alternatives too).

I guess using Jython, you can do anything with Python that you can do in Java.
Conversely, Python has the PyPy compiler, which is pretty cool - a virtual machine with multiple backeds (Java Runtime, LLVM, .net, and Python IIRC), multiple garbage collectors, multiple implementations (Stackless), etc. I know Java has a big choice of virtual machines, but the growth of PyPy is amazing, due to it being written in RPython - a fairly productive language.
Also, can a Java do this, in 1 file and less that 20 lines, with no library imports? Obviously both languages have libraries that can do this, but I'm just talking about the flexibility of the languages.
class Logger(object): # boilerplate code
def log(self,level,msg,*args,**kwargs): # *args, **kwargs = flexible arguments
self._log(level,msg,*args,**kwargs) # call with flexible argments
def _log(self,level,msg,*args,**kwargs):
# override me at runtime :)
# I think Java people call this Dependency Runtime Injection
if level>1:
print msg,args,kwargs
logger = Logger() # boilerplate code
def logged(level): # what pattern do you call this?
def logged_decorator(function): # and this?
def func(*args,**kwars):
name = func.__name__ # look ma, reflective metaprogramming!
logger.log(level,name,*args,**kwargs)
return func(*args,**kwargs)
return func # boilerplate code
return logged_decorator # boilerplate code
Example use:
#logged
def my_func(arg1,arg2):
# your code here
pass

You would surely love reading the comparisons made below between these 2 languages.
Check them :
Java is Dead ! Long live Python
Python-Java : A side-by-side comparison
Python is NOT java

What Python Can do Java Can't -
Nothing.
What Java Can do but Python Can't -
Java is a multithreading boss. So if you are trying to write a web server, where multiple requests come at the same time, java can just spawn multiple threads and CPU swaps them. That's why almost all big companies (Expedia, LinkedIn, Goldman, Amazon, Netflix, CITY, JPMC, VISA almost all) uses the JVM Web server for their main application.
CPython has something called GIL, which prevents itself from using OS-level thread efficiently. How Python Application servers (Gunicorn, Django ..) work then? Well, they fork new Processes instead of threads. Threads are lightweight, so forking new processes instead of threads still work till a threshold, but not a very scalable solution.
Sheer Execution speed - When you take var a = 1. and then do a = 10.07, you just stored float value in a variable that previously-stored an integer. When variables are assigned a new value then internally, Python creates a new object to store the value. This pointer is then assigned to the variable, this is called dynamic binding. Dynamic Binding(Python) is slower than Static Binding(Java) - as it requires object creation. And Java or C/C++ primitive types are an order of magnitude faster because of static binding.
Space used (RAM usage) - The default space python uses to store a variable is huge.
>>> import math, sys
>>> a=0
>>> sys.getsizeof(a)
24
But in Java, you can take a Byte size variable, which will take just a byte. So nobody writes an application in Python if asked to write memory-efficient software(Think about you are asked to create a DataBase like Cassandra, maybe design a compute engine like Spark).
Packaging - In Java, you can create something like a Jar. Which can run on any machine where JVM is installed. and that JAR contains all the dependencies. In python you can't just ship something like a JAR, you will have to write a script to install dependencies in every machine you want to run your code on.
Think about if Android was a Python application, before installing an App from the play store, you had to install the dependencies of that app separately.
Performance . Performance . Performance -
Java’s efficiency largely comes from its Just-In-Time (JIT) compiler and support for concurrency. The JIT compiler is a part of the Java Runtime Environment. It improves performance of Java programs by compiling bytecodes into native machine code “just in time” to run. Java Virtual Machine (JVM) calls the compiled code directly. Since the code is not interpreted, compiling does not require processor time and memory usage. Theoretically, this can make a Java program as fast as a native application.
While Java programs are compiled directly, Python is interpreted which slows down Python programs during runtime. Determining the variable type which occurs during runtime increases the workload of the interpreter. Also, remembering the object type of objects retrieved from container objects contributes to memory usage.
We can go on and on ...
People use python because python is easy to learn, easy to use. A lot of libraries for ML / DataScience etc . that saves you coding. But if you are asked to write a performant, scalable, durable, long term application, People who understand comp sci, will always choose Java or C/C++

CPython has a lot of libraries with bindings to native libraries--not so Java.

Python vs. Java performance (runtime speed) [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
is python slower than java/C#?
Ignoring all the characteristics of each languages and focusing SOLELY on speed, which language is better performance-wise?
You'd think this would be a rather simple question to answer, but I haven't found a decent one.
I'm aware that some types of operations may be faster with python, and vice-versa, but I cannot find any detailed information on this. Can anyone shed some light on the performance differences?

Java is faster than Python. Easily.
Python is favorable for many things; speed isn't necessarily one of them.
References
python.org/Language Comparisons
C++ vs Java vs Python vs Ruby : a first impression
A subjective analysis of two high-level, object-oriented languages: Comparing Python to Java

If you ignore the characteristics of both languages, how do you define "SPEED"? Which features should be in your benchmark and which do you want to omit?
For example:
Does it count when Java executes an empty loop faster than Python?
Or is Python faster when it notices that the loop body is empty, the loop header has no side effects and it optimizes the whole loop away?
Or is that "a language characteristic"?
Do you want to know how many bytecodes each language can execute per second?
Which ones? Only the fast ones or all of them?
How do you count the Java VM JIT compiler which turns bytecode into CPU-specific assembler code at runtime?
Do you include code compilation times (which are extra in Java but always included in Python)?
Conclusion: Your question has no answer because it isn't defined what you want. Even if you made it more clear, the question will probably become academic since you will measure something that doesn't count in real life. For all of my projects, both Java and Python have always been fast enough. Of course, I would prefer one language over the other for a specific problem in a certain context.

There is no good answer as Python and Java are both specifications for which there are many different implementations. For example, CPython, IronPython, Jython, and PyPy are just a handful of Python implementations out there. For Java, there is the HotSpot VM, the Mac OS X Java VM, OpenJRE, etc. Jython generates Java bytecode, and so it would be using more-or-less the same underlying Java. CPython implements quite a handful of things directly in C, so it is very fast, but then again Java VMs also implement many functions in C. You would probably have to measure on a function-by-function basis and across a variety of interpreters and VMs in order to make any reasonable statement.

Different languages do different things with different levels of efficiency.
The Benchmarks Game has a whole load of different programming problems implemented in a lot of different languages.