• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ProgrammingHobbit

Is Java compiled or interpreted?

31 posts in this topic

I am not much of a Java programmer (I prefer C++), but I am firmly of the opinion that Java is an interpreted language. However, other people disagree with that assesment saying it is compiled. Who is right? I hope this is the right forum for this. [edit] This thread probably should have gone in the Java Development Forum [/edit] ProgrammingHobbit [Edited by - ProgrammingHobbit on April 7, 2005 3:31:54 PM]
0

Share this post


Link to post
Share on other sites
Java is compiled to bytecode, which was then traditionally interpreted. I hear that Java is JITed to native code these days, but there is much conflicting information about modern methods of Java execution.
0

Share this post


Link to post
Share on other sites
AFAIK, the VM is written in the C, C++, and/or ASM (or even the OS' API). which would be compiled code. the java that is sent to the VM is interpreted code. that allows the write once, run anywhere effect. with JIT compilers though you can either bypass the interpreting the code and compile it in the cpu's machine code and run it. or the VM will take certain interpreted code parts and machine code compile them.

i'm pretty sure i'm wrong, but that's how i understand it.
0

Share this post


Link to post
Share on other sites
Considering that you have to use a program called the Java Compiler, so that you can compile your Java program, then the naive answer is that it's compiled.

Also, the definition I found on Wikipedia for "interpreted language" defines it as "a programming language whose programs may be executed from source form, by an interpreter". Since you cannot run Java programs from source form, it stands to reason that it's not an interpreted language.
0

Share this post


Link to post
Share on other sites
The question is really, are Java bytecodes compiled or interpreted?

The answer is typically both.

A modern JVM is capable of compiling (to native code) and interpreting bytecodes. How and where it does this is really up to the compiler.

Most of them are based on the "Hotspot" client or server VM. I'm not completely sure how these work, but I think it decides based on how often a method is run, whether it compiles or interprets it.

Compiling takes a significant amount of effort, so the VM doesn't just compile every method of every class by default - that would take too long (apparently). There are VMs however, which do compile every method of every class normally.

For example, with GJC you can compile every method of every class (it has an interpreter too though, but this is only used for code which hasn't been ahead-of-time compiled).

However, it seems that benchmarks have shown that GJC ahead-of-time compiled code performs considerably worse than hotspot just-in-time compiled code.

I don't know about commercial VMs though, they might be somewhat better than GJC.

Mark
0

Share this post


Link to post
Share on other sites
Java is compiled into Java bytecode, but how it executes on your system is dependant on the Java Virtual Machine installed on the machine.

Some Java VM's interpret the bytecode, others compile the bytecode to native code and execute the native code. Still others do what is called "hotspot" compilation, where it will occasionally recompile certain areas of the code to more efficient native code based on how often the code is executed and how expensive the method is.

I hope that answers your question.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by ProgrammingHobbit
So its compiled (though not to native executable), then interpreted?

Does that sound right?

ProgrammingHobbit


Actually yeah, that does sound right. I did more reading on Wikipedia and found this quote:

"Most so-called interpreted languages use an intermediate representation, which combines both compilation and interpretation. In this case, a compiler may output some form of bytecode, which is then executed by a bytecode interpreter. Examples include Python, Java, and Perl."
0

Share this post


Link to post
Share on other sites
java is compiled to a byte code that is platform neutral (based on a hypothetical stack based system) much like .net and then, when run, it is JIT compiled to native code for the host machine, with optimizations performed on the most active parts (the "hot spots").

the first JIT compiler for java came out in 1996. the current hotspot compiler came out 6 years ago in 1999. java's been a compiled language for a long time. try and run a similar program in an interpreted language and you'll see the difference.

the only real things holding back java performance-wise are array bounds checking, increased precision required for functions like sin, cos, sqrt, etc, and the lack on an easy assembly inliner. but you get built in bounds checking, increased precision and theres always JINI, so its all about trade-offs.
0

Share this post


Link to post
Share on other sites
You know, even "native" executables are "interpreted". After all, it is the CPU's job to translate opcodes into actual "operations" - that's interpretation, isn't it? Does it really matter what form the interpretation instructions come in?

Additionally, ocodes used in earlier architectures may be interpreted by the CPU as a sequence of "newer" opcodes (or 32-bit code on 64-bit systems). Then there is microcode. Is that hardware or software?

There are some hardware JVM. Is Java bytecode interpreted then?


Does the distinction matter?
0

Share this post


Link to post
Share on other sites
[quote]Original post by ProgrammingHobbit
So its compiled (though not to native executable), then interpreted?quote]Yes to first part, no to second (in general). Methods that aren't called much are interpreted, but methods that are called often are compiled (during run-time) to native executable code and the native version is used thereafter.
0

Share this post


Link to post
Share on other sites
I guess it all depends on how you define "interpreted" and "compiled". It seems like a semantics game to me.

ProgrammingHobbit
0

Share this post


Link to post
Share on other sites
I have to add your post to my list of dumbest things said on the internet, Hobbit. Thanks for expanding my list.

CPUs do not "interpret" machine code, they execute it. There's kinda a difference there. Please do yourself a favor and take some CS courses.
0

Share this post


Link to post
Share on other sites
Quote:
CPUs do not "interpret" machine code, they execute it. There's kinda a difference there.

Whats the difference between interpreting and executing? Take a transmeta CPU what does it do? A hardware JVM like the one at jopdesign.com?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by boebi
I have to add your post to my list of dumbest things said on the internet, Hobbit. Thanks for expanding my list.

CPUs do not "interpret" machine code, they execute it. There's kinda a difference there. Please do yourself a favor and take some CS courses.


What did I say?
I made no attempt to define "interpreted" or "compiled" for anyone alse. I believe Fruny stated something to the effect that CPUs interpret machine code (no offense Fruny).

Don't go starting flames boebi. You know nothing about my CS knowledge and experience.

ProgrammingHobbit
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Fruny
Does the distinction matter?
It does. By compiling you avoid one level of interpretation, and interpretation is costly. None of the interpretation happening in the lower levels matter, it's still one level *less* interpretation when the code is compiled. We could also have some term for by-passing two levels of interpretation, if that was ever practical. E.g. converting code directly to a new piece of hardware.
0

Share this post


Link to post
Share on other sites
Interpreted code is not directly executed by the hardware...it gets "converted" during execution one instruction at a time (usually) to machine code. That process is much slower than running compiled code.

If you take Java bytecode and run it on a really old JVM, the bytecode is being interpreted. If you run the same code on a hardware JVM, the bytecode "magically" becomes compiled cause it's executing directly on the CPU...no runtime conversion.
0

Share this post


Link to post
Share on other sites
Sorry Hobbit, that WAS Fruny....so thanks Fruny...you get added to my fun list ;) JK
0

Share this post


Link to post
Share on other sites
I believe Fruny said it all.

Basically, the java language is compiled to bytecode, and everyone seems to agree on this.

Then, every portion of bytecode is:
- Interpreted
- Compiled and interpreted
- Compiled and executed
- Executed

Depending on the VM implementation and the processor. It is interpreted on older VMs, executed on hardware VMs, compiled-executed on older machines and compiled-interpreted on current machines (where the processor interprets x86 machine code into its own set of instructions).

Also note that many recent CPUs do not execute x86 instructions: they actually execute their own internal set of instructions, and interpret (or compile) x86 code into these instructions on-the-fly.
0

Share this post


Link to post
Share on other sites
@boebi:
If i run a windows app on an apple-computer using some emulation software c++ becomes an interpreted language?

I don't think compiled/interpreted is a useful distinction between programming languages. If the compiler for a language creates executables that contain an interpreter and some kind of bytecode is it a compiled or interpreted language?

Just say it creates slow/fast programs. That is way simpler and tells you everything that is important to you.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by pinacolada
Considering that you have to use a program called the Java Compiler, so that you can compile your Java program, then the naive answer is that it's compiled.

Also, the definition I found on Wikipedia for "interpreted language" defines it as "a programming language whose programs may be executed from source form, by an interpreter". Since you cannot run Java programs from source form, it stands to reason that it's not an interpreted language.


I was going to launch into a long rant about bullshit, but I don't think I'll waste my time. Instead I'll just summarize:

-The above is false

-The above is an example of how you can reach a false conclusion(s) by making leaps in logic based solely on poor semantic reasoning.
0

Share this post


Link to post
Share on other sites
Quote:
However, it seems that benchmarks have shown that GJC ahead-of-time compiled code performs considerably worse than hotspot just-in-time compiled code.


Very true since the hotspot VM can perform optimisations for very specific hardware configurations which even standard compilation can not perform, or so the theory goes...

This reminds me of HP's 'Dynamo' research project, a translator which translated PA-8000 code into PA-8000 code. No thats not a typo - the goal of the project was to investigate the dynamic translation of binary machine code. In this case translated code was up to 20% faster than native code.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by boebi
Interpreted code is not directly executed by the hardware...it gets "converted" during execution one instruction at a time (usually) to machine code. That process is much slower than running compiled code.


An interpreter does not convert the instruction into machine code, JIT-compilers do. An interpreter performs an pre-programmed action or another depending on the instruction it is fed. Which is also precisely what CPUs do. There are no magical differences, except at for how those operations are implemented - in software (yes, an extra layer of indirection) or in silicon (and even, as we already said, there are no guarantee that the machine code is the last layer of interpretation).

Quote:
Please do yourself a favor and take some CS courses.


*chuckles* [rolleyes]

Quote:
Original post by Trap
If i run a windows app on an apple-computer using some emulation software c++ becomes an interpreted language?


Excellent point.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by boebi
I have to add your post to my list of dumbest things said on the internet, Hobbit. Thanks for expanding my list.

CPUs do not "interpret" machine code, they execute it. There's kinda a difference there. Please do yourself a favor and take some CS courses.


Congrats, dude. Not only do you insult the wrong poster, but you also make a false assertion. Next time, engage brain before mouth.

I'd never heard anything about JOP before, that's really cool. How long before a NOP?
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0