On what point? That Java is a compiled language? I have shown you overwhelming support for this, and you have only made childish whining sounds. Was I wrong that Java could be optimized? Please show me. Also, explain why a google search for "Java compile-time optimization returns 276,000 results if such optimization is not possible.
Go get an education, and a couple of decades of experience, and you'll know the difference
I have participated in starting a software company, taking it from three starters to fifty employees grown organically and sold to a bigger company, all based on one of the very first commercial Java Enterprise applications ever. I have developed embedded software in C for companies like Sorrento Networks, Cisco, Alcatel and Lucent. I have made a living from software development and related activities since the '80s. For a few years I even worked for IBM. I have worked with Sun long enough to have lamented when they went from BSD to SysV. I have developed software for DEC, Mac and NExT. I am pretty sure I have a lot more varied experience than you. Heck I have even done hardware modifications for a PDP-11 once.
I would assume you are a developer that mostly have developed software for PCs. I might be wrong but only people with a REALLY narrow focus would be as clueless as you.
The JIT is a runtime, same as any other runtime. It INTERPRETS the code
You are astonishingly clueless, and apparently unable to use a search engine: Try this article. I assume you are actually too dumb to click links, here is a quote: "At the time the bytecode is run, the just-in-time compiler will compile some or all of it to native machine code for better performance" (my emphasis). Who is right, the entire world your your dumb ass?
There's a difference between optimizing for the runtime
Again, your SPECIFIC claim was that it was not possible to optimize away getter and setter functions since Java was an interpreted language. Given that Java is COMPILED to bytecode which makes any optimization possible and then again COMPILED to native code by the Just In Time COMPILER which makes it easy, please elaborate. You have so far been unable to do anything relating to your original claim other than denying that you actually made it.
Try this article to learn what a compiler IS. Again, it seems like you are COMPLETELY at odds with the rest of the world. Can you explain why you are right and the rest of the computing world is wrong? Here are some quotes: While the typical multi-pass compiler outputs machine code from its final pass, there are several other types
A "source-to-source compiler"
Stage compiler that compiles to assembly language of a theoretical machine
Just-in-time compiler, used by Smalltalk and Java systems (my emphasis)
Applications are delivered in bytecode, which is compiled to native machine code just prior to execution (my emphasis)
There is also a nice article on Wikipedia about Java compiler. Wonder what that might be... The most common form of output from a Java compiler are Java class files containing platform-neutral Java bytecode. There exist also compilers emitting optimized native machine code for a particular hardware/operating system combination
How about this one? which says: Java source code files (files with a.java extension) are compiled into a format called bytecode. Heck even the DUMBEST computer dictionary on the web gets it right. Even PC Mag gets it right.
There used to be a Java interpreter on the market. It was called Bean Shell, and it interpreted Java code. I have not checked to see if it still exists. Try Google for "Java interpreter".
Really? Here is about what transpired, just to jog your memory:
You: To force a function or method call behind the scenes call when a direct assignment to a variable would do DOES add both bloat and reduces performance.
Me: compilers will consequently inline the method, so once your code is compiled, it IS a direct assignment
You: AVA IS NOT A COMPILED LANGUAGE. It's an interpreted language, so your arguments about compiler optimization simply don't apply
But hey, it does explain a lot. Your massive Alzheimer's problem is making it difficult for you to remember anything after 1998.
he verifier is designed and written once - for the pcode that is being presented to the virtual machine
Correct, but that does not prevent the JIT from COMPILING the code into native code at load time. What this means is that you have shifted the code generation away from compile time to load time. This gives you a penalty at LOAD time since the JIT has to compile the pcode (or bytecode as Sun calls it) into native code as it is loading the pcode. Given the fact that the sun bytecode is highly optimized for fast compilation, the overhead in compiling the app at load time rather than at compile time is insignificant.
Again, you have only stated the blatantly obvious, and any time you state that Java is not compiled, and thus can not be optimized, you are making a fool out of your self. Particularly considering that Java in many cases will be faster than C or C++ code.
So you read nothing of what I said and you have not browsed single one of my suggestions? Fine. OK With me. Forget about it, you simply do not have the knowledge and you do not want to acquire it.
This leaves one question un-answered though. Why can one not optimize Java code as it is turned into bytecode? Why can one not optimize bytecode as it is turned into native CPU instructions? That was your original - and massively ignorant - statement.
Not necessarily true. It's possible to write a compiler that directly generates machine code.
I am sorry, but have you had your reading comprehension skills tested? They appear to be very low. I said: "that often the (final) output". You do understand that this means it doesn't happen always, right?
which is what Oracle is going to have to do
So you really do not know that there are products out there that turn out a native executable from Java code? The GNU tool set for example. Since it has been out there for YEARS, and what seems to be your primary problem with Java hasn't been valid since 2002, it seems you really need to read up on things a little.
Do you seriously think that not producing native code in the compile phase is a problem for Java, then you have no clue whatsoever. "Interpreted" bytecode can easily be faster, some times A LOT faster, than native compiled code. If you don't believe me you HAVE been out of the loop since at least 1996. Since most bytecode interpreters today compile the code to native code, they can (and do) perform run-time optimizations. IBMs and other JITs monitor the running of the Java program and then they do run-time optimizations by re-compiling the code in real time. These optimizations can take run-time information into consideration when doing optimizations, something that is impossible with statically compiled languages.
There are also things that dynamic languages like Java etc can do that are more or less impossible with statically compiled languages. This makes dynamic languages like Java FAR more suitable for large enterprise apps than C or C++ for example. I would love to see someone developing a C++ enterprise application that scales to multiple servers and also supports Dynamic Injection. I would love to see someone write a C++ enterprise application where parts of the application, parts that were running at the time, were replaced without bringing down the application.
Honestly, if you write large enterprise applications (not off-the-shelf stuff) today in C or C++ you are totally insane since your productivity will be less than 10% of teams that use more sensible approaches.
Java has many problems. The fact that it is not a statically compiled language is NOT one of them.
You need a Java virtual machine (jvm) to run your so-called "compiled code"
That depends on which Java tool set you use. If you use the Sun Java COMPILER, it does, as you say, COMPILE Java source into bytecode. What happens to that bytecode later again depends on what tools you are using. It is usually either interpreted or compiled into native code, or a combination thereof. On the other hand, if you use the GNU GCJ tool chain, the end result of the compile-asm-link stage is native code. So, as per usual, you are wrong and wrong. Doesn't it get a little embarrassing? Oh, and the ORIGINAL statement of yours was that Java could not be optimized since it was interpreted. Can you please elaborate on why a Java compiler is prevented from producing optimized bytecode?
pascal used pcode and a pcode interpreter
What makes you think I did not know? I once worked on a project that compiled LOGO into p-Code for a p-Machine. It wasn't a great idea for us at the time but it took a while to convince the manager dudes about it. We finally (thankfully) scrapped it.
Oh, and no, p-code wasn't new and the concept wasn't invented for Pascal, as funny enough the article you linked to stated (so your reading comprehension is not too good either) - BCPL was a kind of Basic.
The day you can run Java directly on your os w/o needing a runtime interpreter
Java is a programming language, just like C and Pascal. It can not run on anything. It needs to be TRANSLATED into something so that it can run. This translation process is done by something called a COMPILER. The process is therefore usually termed "to compile". As you say, most (but far from all) Java compilers compile to Sun bytecode, but there are exceptions. The Microsoft Java suite compiles to CIL, which is the MS equivalent. The GNU Java tools compiles to native executables (and therefore lose some Java functionality). All of these products are COMPILERS, the only difference between them is what the compiler outputs. Also, since all of these compilers fundamentally change the Java source code, they can all perform optimizations on the code, such as inlining code. Your moronic statement was that this was not possible.
java class files are just bytes to be interpreted by a jvm, not compiled code
You seem to hold "native code" as equivalent to "compiled code", which is absurd. Something that is compiled is something that has gone through a compiler. What that is really depends. It may be bytecode, it may be another language, it may be (and often is) ASM etc. In the vast majority of cases, what comes out of a compiler will have to be further processed prior to becoming a running program. Even C. ASM and LINK are two cool phases that people who developed for DOS and Windows got intimately familiar with. On Unix very often the output of a compile would be a.o entity. cc -c program.c => program.o (cc -c means "compile only"). Would you be so dumb as to say that cc -c is NOT compilation?
so java isn't a compiled language after all, is it
Yes it is, it is just you who have no clue what a compiler is. Read Louden or Wirth. Please. You are making a fool out of your self.
Compiled languages are executed directly by the cpu
Sigh. All software is executed directly by the CPU one way or another. Some software, most notably Java and.NET languages are COMPILED to an intermediary code that is then COMPILED again to native CPU code. During BOTH of those COMPILE rounds, the COMPILER can do any and all optimizations that it wants to. For example, as was discussed here, inline code. Your claim was that since Java was an interpreted language (it is not, but the bytecode MIGHT be) optimizations were not possible. That is meaningless drivel since the compiler, when compiling to bytecode, can easily do optimizations.
What do you think the JIT in the run-time does
Sigh. Yes, the JIT runs the bytecode. The bytecode that was COMPILED by the Java COMPILER from Java source code. You seem to be under the illusion that the only thing a compiler can produce is native code, which is of course a good indication of how amazingly ignorant you are of the fundamentals of computers. The first COMPILER I wrote was written in C, it was a pascal COMPILER that COMPILED Pascal code into C code. The fact that the output was C didn't make it less of a compiler.
Oh, and btw moron, I can GUARANTEE you that there is almost (or absolutely) NO compilers on the market today that produce native code, that is typically the task of other processes running AFTER the compiler. Almost ALL compilers written since the 1970s compiled into INTERMEDIARY code which was then somehow translated into native CPU instructions.
The only person here who have shown a clear lack of understanding of the basics of computers is YOU. You have, for example, show that you have NO CLUE what a "compiler" is. Wikipedia is usually a good source: A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language
We KNOW that most Java compilers compiles Java source into something else than native CPU instructions, even though there is at least one (the GNU compiler) where the end result is native CPU instructions. So, if you use the GNU Java compiler tool set it is even a compiled language in your perverted definition of "compiled". What the output of the Java compiler was was never the topic. The topic was whether Java could be optimized by the compiler, and since the output is bytecode, optimizing away setters and getters is trivial for a Java compiler. This is true whether the output is bytecode or native cpu instructions.
As for who knows most about computers? I have no idea. You for one is the only one here who have repeatedly shown that you have no clue what a COMPILER is. You have flaunted that ignorance as a virtue which makes you a moron.
If you want to learn the basics of Compiler Construction, I understand Loudens book on the topic "Compiler Construction: Principles and Practice" is good. In it you will, for example, learn what a compiler IS, something you clearly do not yet know.
Oh, and BTW, writing an Assembler from scratch is EASY. A CHILD can do it. If you want to brag about your accomplishments try to brag about something that is difficult. If you want to brag, say something like "I have solved P=NP?". That would be impressive. When writing cross-platform compilers way back when, doing ASM was the mundane and trivially boring things everybody dreaded, and some times we were lucky enough not to have to.
Oh, and if you wrote an assembler once, you would KNOW that often the (final) output of a COMPILER would be something that eventually got passed to ASM (and the linker) and that ASM was the entity that translated the compiler intermediary code into native CPU instructions. Since you apparently didn't know this, I seriously doubt the truthfulness in this statement.
Tape is a great medium for video. On the right formats, with the right video equipment. VCRs, which are all (unless you are in "the industry") all VHS or a derivative (S-VHS anyone?). It is crap. Crap. Crap. Crap. Its color rendition is worse than Polaroid anno 1983. Its picture quality stinks to high heaven. It stank in 1976. It stank it 1986 and 1996, and today it barely watchable.
As to your points - aside from Blu-Ray, what media is NOT cheap? I have all my video on hard drives. Minute for minute adding quality requirements, they are far cheaper than VHS. They are also a lot easier to copy and back up. There is no monthly fee. Media storage is infinite. I can watch a movie or a show in seconds, not even having to walk over to a player and put in a dumb tape, they are stored on my PC and served to my TV through my media center. The media is re-usable, and I can share them with friends without even leaving my couch.
I can't possibly fathom what would compel anyone to subject them selves to the torture that is bad picture quality and eternal tape-change routines that spells VHS. What if my kids wants to watch the movie in their room 10 minutes after I started watching it? Am I going to get a backup of the VHS tape? Of course not, they can watch the same movie on THEIR media center. Whenever they want. Even when I am watching it.
I have news for you, son. A lot of us nerds are pretty damned old
Don't know how old you are. Don't care. I'm old enough to having lived through the '80s and thought all of the "young kids" were fucking nuts. They were. It was the fucking '80s. The favorite car in my garage is from 1966, and I don't think it is that old, but my niece disagrees with me.
I don't think I ever implied that having the latest shiny toy is being a nerd either. On the other hand, writing about Depends is not what I expect from Slashdot, and quite frankly, fiddling with a crappy VHS player makes you older and far less cool than wearing Depends.
You totally fail because you miss one point - JAVA IS NOT A COMPILED LANGUAGE. It's an interpreted language, so your arguments about compiler optimization simply don't apply.
You just failed computer 101. Java is in fact a compiled language. It is compiled into an intermediate code called bytecode. This is done by the java compiler, command line is javac. Example javac MyClass.java. This compiler can do, and DOES do optimizations. So, your dreaded getter and setter is compiled into inline bytecode assignments, direct assignments if you wish, in bytecode.
What happens to the bytecode once it has been compiled depends on the runtime environment. Most Java runtime environments today utilize a JIT compiler. This stands for Just In Time. A JIT compiler takes the compiled bytecode and compiles it, on the fly, just in time, to native code.
And you assume, to your error, that I'm a n00b
I have no idea what kind of experience you have with various programming tasks. You proved in your posting that you have NO CLUE what Java is however. If you need to know my credentials in Java I delivered my companies first enterprise class Java application in 1998. That was before J2EE.
Sheesh. Kids nowadays.
Funny comment. I could also tell you about the work I have done in the telecom industry with embedded agents on million-dollar telecom equipment. Agents written in very, very tight quarters, mostly in C. It would be cruel though, particularly since it appears that you are still living in the age where the inline keyword was still important. When writing generic code for embedded stuff, using the inline keyword in C code was not appropriate however, since inline in C is only a suggestion to the compiler, it doesn't have to follow your suggestion. The only way to ensure inline was using macros.
But hey, you just showed the entire world that you have absolutely no clue what Java is - "interpreted language" - sheesh, clueless morons these days.
If you want to learn interesting things about JIT compilers, a technology that has the possibility of achieving FAR better optimizations than even static compilers can do, this list is a place to start: http://www.program-transformation.org/Transform/JavaDynamicCompilers. I suggest you read that, and A LOT more before you say REALLY stupid things like "JAVA IS NOT A COMPILED LANGUAGE". You are just flaunting your ignorance.
Oh, and just to be clear, a compiler can, if it wants to, inline ANY code, but that would obviously (to anyone who has a minimum amount of knowledge about software development) sacrifice size for speed. Where there is no sacrifice, as in the simple setter above, the compiler will inline.
To force a function or method call behind the scenes call when a direct assignment to a variable would do DOES add both bloat and reduces performance
Sigh. Until you know the basics of compilers and their construction, you really shouldn't utter any more of your nonsense. As you absolutely correctly state - a direct assignment is much faster than a method call. Everybody knows that, even compilers. If a setter method is nothing but an assignment ALL compilers will consequently inline the method, so once your code is compiled, it IS a direct assignment. All compilers will do this, even the ones from Microsoft.
There will be cases where the programmer puts an amount of logic into the setter - say validation for example - and in such cases the compiler may or may not inline the code, depending on what the logic does. In such cases the method may be slower, but that is no different from a situation where one didn't have properties, since a setter method would be required anyway.
That's basic knowledge that anyone who knew how programming languages work would "get" right away
That is a funny statement since you obviously didn't know that any compiler not written by a Computer 101 student will inline code like this:
String mySetter( String val ) {
myProperty = val;
}
Oh, I may inadvertently have used a term you do not understand here. Inlining is essentially the process of turning the code above into a direct assignment, essentially replacing the three lines with a direct assignment. I am simplifying a little for you since you clearly have very limited exposure to this computer stuff. Inlining like this is one of the absolutely easiest things to do for a compiler, and they all do. The smarter runtime environment for dynamic languages are even able to inline at runtime if they realize that even a more complex piece of code, perhaps with conditionals, will always be a direct assignment.
Now, if you think it is vital that you replace the code above with myProperty = val; just in case your particular compiler was not written to inline such code, you need to read your Knuth again and again and again. Look for the phrase "Premature Optimizations".
It also instills the value that you shouldn't read unless you're being paid to
Why do all of you insist on commenting on the article with only your own inane religious views rather than actually reading the article and commenting on the actual findings? Clearly someone should have paid you to read in school, since the article clearly states that for kinds being paid to read, the reading continued also after then payments stopped.
This is just like with dogs. You use rewards to promote a specific behavior. Once you have done that for an appropriate amount of time, the behavior continues even when the rewards stop. This is basic stuff and the information is ancient. Ever heard about Pavlov?
Important perhaps, but not a critical thing. It is far worse that Java wasn't properly OO from the get-go.
and making everything a class
You forgot the "not" in there. Not making everything a class in Java was a big mistake that is still tripping things up. It was "fixed" by adding compile-time auto-boxing, which made things WORSE, not better.
I don't know that there is anything in Java that has too long class or method names, but anyone can obviously do that when they develop code. I don't see how that has anything to do with the language. Should they have limited the number of characters to, say 16, for class and method names?
Properties - java needs properties. Why? Because properties can ONLY be changed using the getter and setter methods. Even from inside the class. That is a Good Thing (TM) and it removes the ability to write some rather common error-prone code. Like, when someone in a re-factoring situation decides to add some sensible logic to a getter or a setter, but other parts of the same class still accesses the property directly. Badness ensues.
Lambdas and friends...
Hmmmm, seems like I just described C# as the solution to Java's problems... that was unintentional.
I did realize that, so again, doing drugs or forgotten to take your medication? Since when did MS mandate any specific language for CLR development?
Same with Google. Obviously, with the vast number of mobile processors out there, suggesting one develops for a VM makes sense, the VM is the platform, but that doesn't mean that one mandates any particular language.
Just curious - and no I am no big fan of Adobe either - but how is Adobe doing a lock in? They do not own the OS, the developer tools in question are generally open source. What is the Adobe lock in?
Are you really that dumb or are you just pretending? Do you really think there is a way that Apple, or any other company, can prevent an app from allocating too much memory? Before I got my 3GS I had to reboot the iPhone every time I had played Monopoly from EA. Even after I quit Monopoly, memory would be so low that the phone became very troubled indeed. With the 3GS it is a little less of a problem, but I still have to reboot my iPhone about once a week or so, whether I play Monopoly or not. And that is when there is no multitasking apps running.
Stop sucking Jobs' dick. It isn't pretty with so many star-eyed fans queuing up just to have him sprinkle his semen on them every day.
Slashdot Mirror
Grow up. You were wrong and can't admit it
On what point? That Java is a compiled language? I have shown you overwhelming support for this, and you have only made childish whining sounds. Was I wrong that Java could be optimized? Please show me. Also, explain why a google search for "Java compile-time optimization returns 276,000 results if such optimization is not possible.
Go get an education, and a couple of decades of experience, and you'll know the difference
I have participated in starting a software company, taking it from three starters to fifty employees grown organically and sold to a bigger company, all based on one of the very first commercial Java Enterprise applications ever. I have developed embedded software in C for companies like Sorrento Networks, Cisco, Alcatel and Lucent. I have made a living from software development and related activities since the '80s. For a few years I even worked for IBM. I have worked with Sun long enough to have lamented when they went from BSD to SysV. I have developed software for DEC, Mac and NExT. I am pretty sure I have a lot more varied experience than you. Heck I have even done hardware modifications for a PDP-11 once.
I would assume you are a developer that mostly have developed software for PCs. I might be wrong but only people with a REALLY narrow focus would be as clueless as you.
The JIT is a runtime, same as any other runtime. It INTERPRETS the code
You are astonishingly clueless, and apparently unable to use a search engine: Try this article. I assume you are actually too dumb to click links, here is a quote: "At the time the bytecode is run, the just-in-time compiler will compile some or all of it to native machine code for better performance" (my emphasis). Who is right, the entire world your your dumb ass?
There's a difference between optimizing for the runtime
Again, your SPECIFIC claim was that it was not possible to optimize away getter and setter functions since Java was an interpreted language. Given that Java is COMPILED to bytecode which makes any optimization possible and then again COMPILED to native code by the Just In Time COMPILER which makes it easy, please elaborate. You have so far been unable to do anything relating to your original claim other than denying that you actually made it.
Try this article to learn what a compiler IS. Again, it seems like you are COMPLETELY at odds with the rest of the world. Can you explain why you are right and the rest of the computing world is wrong? Here are some quotes:
While the typical multi-pass compiler outputs machine code from its final pass, there are several other types
There is also a nice article on Wikipedia about Java compiler. Wonder what that might be... The most common form of output from a Java compiler are Java class files containing platform-neutral Java bytecode. There exist also compilers emitting optimized native machine code for a particular hardware/operating system combination
How about this one? which says: Java source code files (files with a .java extension) are compiled into a format called bytecode. Heck even the DUMBEST computer dictionary on the web gets it right. Even PC Mag gets it right.
There used to be a Java interpreter on the market. It was called Bean Shell, and it interpreted Java code. I have not checked to see if it still exists. Try Google for "Java interpreter".
I never said it couldn't be optimized.
Really? Here is about what transpired, just to jog your memory:
You: To force a function or method call behind the scenes call when a direct assignment to a variable would do DOES add both bloat and reduces performance.
Me: compilers will consequently inline the method, so once your code is compiled, it IS a direct assignment
You: AVA IS NOT A COMPILED LANGUAGE. It's an interpreted language, so your arguments about compiler optimization simply don't apply
But hey, it does explain a lot. Your massive Alzheimer's problem is making it difficult for you to remember anything after 1998.
he verifier is designed and written once - for the pcode that is being presented to the virtual machine
Correct, but that does not prevent the JIT from COMPILING the code into native code at load time. What this means is that you have shifted the code generation away from compile time to load time. This gives you a penalty at LOAD time since the JIT has to compile the pcode (or bytecode as Sun calls it) into native code as it is loading the pcode. Given the fact that the sun bytecode is highly optimized for fast compilation, the overhead in compiling the app at load time rather than at compile time is insignificant.
Again, you have only stated the blatantly obvious, and any time you state that Java is not compiled, and thus can not be optimized, you are making a fool out of your self. Particularly considering that Java in many cases will be faster than C or C++ code.
Sigh. So you are really saying that Just In Time COMPILATION is interpretation? Really?
If the end result is a Java class file
So you read nothing of what I said and you have not browsed single one of my suggestions? Fine. OK With me. Forget about it, you simply do not have the knowledge and you do not want to acquire it.
This leaves one question un-answered though. Why can one not optimize Java code as it is turned into bytecode? Why can one not optimize bytecode as it is turned into native CPU instructions? That was your original - and massively ignorant - statement.
Not necessarily true. It's possible to write a compiler that directly generates machine code.
I am sorry, but have you had your reading comprehension skills tested? They appear to be very low. I said: "that often the (final) output". You do understand that this means it doesn't happen always, right?
which is what Oracle is going to have to do
So you really do not know that there are products out there that turn out a native executable from Java code? The GNU tool set for example. Since it has been out there for YEARS, and what seems to be your primary problem with Java hasn't been valid since 2002, it seems you really need to read up on things a little.
Do you seriously think that not producing native code in the compile phase is a problem for Java, then you have no clue whatsoever. "Interpreted" bytecode can easily be faster, some times A LOT faster, than native compiled code. If you don't believe me you HAVE been out of the loop since at least 1996. Since most bytecode interpreters today compile the code to native code, they can (and do) perform run-time optimizations. IBMs and other JITs monitor the running of the Java program and then they do run-time optimizations by re-compiling the code in real time. These optimizations can take run-time information into consideration when doing optimizations, something that is impossible with statically compiled languages.
There are also things that dynamic languages like Java etc can do that are more or less impossible with statically compiled languages. This makes dynamic languages like Java FAR more suitable for large enterprise apps than C or C++ for example. I would love to see someone developing a C++ enterprise application that scales to multiple servers and also supports Dynamic Injection. I would love to see someone write a C++ enterprise application where parts of the application, parts that were running at the time, were replaced without bringing down the application.
Honestly, if you write large enterprise applications (not off-the-shelf stuff) today in C or C++ you are totally insane since your productivity will be less than 10% of teams that use more sensible approaches.
Java has many problems. The fact that it is not a statically compiled language is NOT one of them.
You need a Java virtual machine (jvm) to run your so-called "compiled code"
That depends on which Java tool set you use. If you use the Sun Java COMPILER, it does, as you say, COMPILE Java source into bytecode. What happens to that bytecode later again depends on what tools you are using. It is usually either interpreted or compiled into native code, or a combination thereof. On the other hand, if you use the GNU GCJ tool chain, the end result of the compile-asm-link stage is native code. So, as per usual, you are wrong and wrong. Doesn't it get a little embarrassing? Oh, and the ORIGINAL statement of yours was that Java could not be optimized since it was interpreted. Can you please elaborate on why a Java compiler is prevented from producing optimized bytecode?
pascal used pcode and a pcode interpreter
What makes you think I did not know? I once worked on a project that compiled LOGO into p-Code for a p-Machine. It wasn't a great idea for us at the time but it took a while to convince the manager dudes about it. We finally (thankfully) scrapped it.
Oh, and no, p-code wasn't new and the concept wasn't invented for Pascal, as funny enough the article you linked to stated (so your reading comprehension is not too good either) - BCPL was a kind of Basic.
The day you can run Java directly on your os w/o needing a runtime interpreter
Java is a programming language, just like C and Pascal. It can not run on anything. It needs to be TRANSLATED into something so that it can run. This translation process is done by something called a COMPILER. The process is therefore usually termed "to compile". As you say, most (but far from all) Java compilers compile to Sun bytecode, but there are exceptions. The Microsoft Java suite compiles to CIL, which is the MS equivalent. The GNU Java tools compiles to native executables (and therefore lose some Java functionality). All of these products are COMPILERS, the only difference between them is what the compiler outputs. Also, since all of these compilers fundamentally change the Java source code, they can all perform optimizations on the code, such as inlining code. Your moronic statement was that this was not possible.
java class files are just bytes to be interpreted by a jvm, not compiled code
You seem to hold "native code" as equivalent to "compiled code", which is absurd. Something that is compiled is something that has gone through a compiler. What that is really depends. It may be bytecode, it may be another language, it may be (and often is) ASM etc. In the vast majority of cases, what comes out of a compiler will have to be further processed prior to becoming a running program. Even C. ASM and LINK are two cool phases that people who developed for DOS and Windows got intimately familiar with. On Unix very often the output of a compile would be a .o entity. cc -c program.c => program.o (cc -c means "compile only"). Would you be so dumb as to say that cc -c is NOT compilation?
so java isn't a compiled language after all, is it
Yes it is, it is just you who have no clue what a compiler is. Read Louden or Wirth. Please. You are making a fool out of your self.
Compiled languages are executed directly by the cpu
Sigh. All software is executed directly by the CPU one way or another. Some software, most notably Java and .NET languages are COMPILED to an intermediary code that is then COMPILED again to native CPU code. During BOTH of those COMPILE rounds, the COMPILER can do any and all optimizations that it wants to. For example, as was discussed here, inline code. Your claim was that since Java was an interpreted language (it is not, but the bytecode MIGHT be) optimizations were not possible. That is meaningless drivel since the compiler, when compiling to bytecode, can easily do optimizations.
What do you think the JIT in the run-time does
Sigh. Yes, the JIT runs the bytecode. The bytecode that was COMPILED by the Java COMPILER from Java source code. You seem to be under the illusion that the only thing a compiler can produce is native code, which is of course a good indication of how amazingly ignorant you are of the fundamentals of computers. The first COMPILER I wrote was written in C, it was a pascal COMPILER that COMPILED Pascal code into C code. The fact that the output was C didn't make it less of a compiler.
Oh, and btw moron, I can GUARANTEE you that there is almost (or absolutely) NO compilers on the market today that produce native code, that is typically the task of other processes running AFTER the compiler. Almost ALL compilers written since the 1970s compiled into INTERMEDIARY code which was then somehow translated into native CPU instructions.
The only person here who have shown a clear lack of understanding of the basics of computers is YOU. You have, for example, show that you have NO CLUE what a "compiler" is. Wikipedia is usually a good source:
A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language
We KNOW that most Java compilers compiles Java source into something else than native CPU instructions, even though there is at least one (the GNU compiler) where the end result is native CPU instructions. So, if you use the GNU Java compiler tool set it is even a compiled language in your perverted definition of "compiled". What the output of the Java compiler was was never the topic. The topic was whether Java could be optimized by the compiler, and since the output is bytecode, optimizing away setters and getters is trivial for a Java compiler. This is true whether the output is bytecode or native cpu instructions.
As for who knows most about computers? I have no idea. You for one is the only one here who have repeatedly shown that you have no clue what a COMPILER is. You have flaunted that ignorance as a virtue which makes you a moron.
If you want to learn the basics of Compiler Construction, I understand Loudens book on the topic "Compiler Construction: Principles and Practice" is good. In it you will, for example, learn what a compiler IS, something you clearly do not yet know.
Oh, and BTW, writing an Assembler from scratch is EASY. A CHILD can do it. If you want to brag about your accomplishments try to brag about something that is difficult. If you want to brag, say something like "I have solved P=NP?". That would be impressive. When writing cross-platform compilers way back when, doing ASM was the mundane and trivially boring things everybody dreaded, and some times we were lucky enough not to have to.
Oh, and if you wrote an assembler once, you would KNOW that often the (final) output of a COMPILER would be something that eventually got passed to ASM (and the linker) and that ASM was the entity that translated the compiler intermediary code into native CPU instructions. Since you apparently didn't know this, I seriously doubt the truthfulness in this statement.
Tape is a great medium for video. On the right formats, with the right video equipment. VCRs, which are all (unless you are in "the industry") all VHS or a derivative (S-VHS anyone?). It is crap. Crap. Crap. Crap. Its color rendition is worse than Polaroid anno 1983. Its picture quality stinks to high heaven. It stank in 1976. It stank it 1986 and 1996, and today it barely watchable.
As to your points - aside from Blu-Ray, what media is NOT cheap? I have all my video on hard drives. Minute for minute adding quality requirements, they are far cheaper than VHS. They are also a lot easier to copy and back up. There is no monthly fee. Media storage is infinite. I can watch a movie or a show in seconds, not even having to walk over to a player and put in a dumb tape, they are stored on my PC and served to my TV through my media center. The media is re-usable, and I can share them with friends without even leaving my couch.
I can't possibly fathom what would compel anyone to subject them selves to the torture that is bad picture quality and eternal tape-change routines that spells VHS. What if my kids wants to watch the movie in their room 10 minutes after I started watching it? Am I going to get a backup of the VHS tape? Of course not, they can watch the same movie on THEIR media center. Whenever they want. Even when I am watching it.
I have news for you, son. A lot of us nerds are pretty damned old
Don't know how old you are. Don't care. I'm old enough to having lived through the '80s and thought all of the "young kids" were fucking nuts. They were. It was the fucking '80s. The favorite car in my garage is from 1966, and I don't think it is that old, but my niece disagrees with me.
I don't think I ever implied that having the latest shiny toy is being a nerd either. On the other hand, writing about Depends is not what I expect from Slashdot, and quite frankly, fiddling with a crappy VHS player makes you older and far less cool than wearing Depends.
You totally fail because you miss one point - JAVA IS NOT A COMPILED LANGUAGE. It's an interpreted language, so your arguments about compiler optimization simply don't apply.
You just failed computer 101. Java is in fact a compiled language. It is compiled into an intermediate code called bytecode. This is done by the java compiler, command line is javac. Example javac MyClass.java. This compiler can do, and DOES do optimizations. So, your dreaded getter and setter is compiled into inline bytecode assignments, direct assignments if you wish, in bytecode.
What happens to the bytecode once it has been compiled depends on the runtime environment. Most Java runtime environments today utilize a JIT compiler. This stands for Just In Time. A JIT compiler takes the compiled bytecode and compiles it, on the fly, just in time, to native code.
And you assume, to your error, that I'm a n00b
I have no idea what kind of experience you have with various programming tasks. You proved in your posting that you have NO CLUE what Java is however. If you need to know my credentials in Java I delivered my companies first enterprise class Java application in 1998. That was before J2EE.
Sheesh. Kids nowadays.
Funny comment. I could also tell you about the work I have done in the telecom industry with embedded agents on million-dollar telecom equipment. Agents written in very, very tight quarters, mostly in C. It would be cruel though, particularly since it appears that you are still living in the age where the inline keyword was still important. When writing generic code for embedded stuff, using the inline keyword in C code was not appropriate however, since inline in C is only a suggestion to the compiler, it doesn't have to follow your suggestion. The only way to ensure inline was using macros.
But hey, you just showed the entire world that you have absolutely no clue what Java is - "interpreted language" - sheesh, clueless morons these days.
If you want to learn interesting things about JIT compilers, a technology that has the possibility of achieving FAR better optimizations than even static compilers can do, this list is a place to start: http://www.program-transformation.org/Transform/JavaDynamicCompilers. I suggest you read that, and A LOT more before you say REALLY stupid things like "JAVA IS NOT A COMPILED LANGUAGE". You are just flaunting your ignorance.
Oh, and just to be clear, a compiler can, if it wants to, inline ANY code, but that would obviously (to anyone who has a minimum amount of knowledge about software development) sacrifice size for speed. Where there is no sacrifice, as in the simple setter above, the compiler will inline.
To force a function or method call behind the scenes call when a direct assignment to a variable would do DOES add both bloat and reduces performance
Sigh. Until you know the basics of compilers and their construction, you really shouldn't utter any more of your nonsense. As you absolutely correctly state - a direct assignment is much faster than a method call. Everybody knows that, even compilers. If a setter method is nothing but an assignment ALL compilers will consequently inline the method, so once your code is compiled, it IS a direct assignment. All compilers will do this, even the ones from Microsoft.
There will be cases where the programmer puts an amount of logic into the setter - say validation for example - and in such cases the compiler may or may not inline the code, depending on what the logic does. In such cases the method may be slower, but that is no different from a situation where one didn't have properties, since a setter method would be required anyway.
That's basic knowledge that anyone who knew how programming languages work would "get" right away
That is a funny statement since you obviously didn't know that any compiler not written by a Computer 101 student will inline code like this:
String mySetter( String val ) {
myProperty = val;
}
Oh, I may inadvertently have used a term you do not understand here. Inlining is essentially the process of turning the code above into a direct assignment, essentially replacing the three lines with a direct assignment. I am simplifying a little for you since you clearly have very limited exposure to this computer stuff. Inlining like this is one of the absolutely easiest things to do for a compiler, and they all do. The smarter runtime environment for dynamic languages are even able to inline at runtime if they realize that even a more complex piece of code, perhaps with conditionals, will always be a direct assignment.
Now, if you think it is vital that you replace the code above with myProperty = val; just in case your particular compiler was not written to inline such code, you need to read your Knuth again and again and again. Look for the phrase "Premature Optimizations".
This is a non-event for anyone who has moved past the stone age. News for nerds? This is News For Cave Men.
this isn't new, and it isn't from Microsoft
I don't think anyone ever said it was neither new nor from Microsoft. Does it add bloat? Not really. Does it make for crappy performance? Nope.
No need for using getters and setters even if everything is a class. Operator overloading and Properties takes care of it for you:
public class MyClass {
...
// Calls the setter // Uses getter and possibly overloaded ==
public class Property { get; set; }
}
MyClass mc = new MyClass();
mc.Property = Value;
if( mc.Property == AnotherValue ) {
}
Clean. Easy. Safe. Beautiful.
And I am again aghast at using such superlatives about a Microsoft improvement over Java, but an improvement it is. Language wise for sure.
It also instills the value that you shouldn't read unless you're being paid to
Why do all of you insist on commenting on the article with only your own inane religious views rather than actually reading the article and commenting on the actual findings? Clearly someone should have paid you to read in school, since the article clearly states that for kinds being paid to read, the reading continued also after then payments stopped.
This is just like with dogs. You use rewards to promote a specific behavior. Once you have done that for an appropriate amount of time, the behavior continues even when the rewards stop. This is basic stuff and the information is ancient. Ever heard about Pavlov?
Please refrain from commenting on something you haven't read and therefore have no way of understanding.
like the lack of a pre-processor
Important perhaps, but not a critical thing. It is far worse that Java wasn't properly OO from the get-go.
and making everything a class
You forgot the "not" in there. Not making everything a class in Java was a big mistake that is still tripping things up. It was "fixed" by adding compile-time auto-boxing, which made things WORSE, not better.
I don't know that there is anything in Java that has too long class or method names, but anyone can obviously do that when they develop code. I don't see how that has anything to do with the language. Should they have limited the number of characters to, say 16, for class and method names?
Properties - java needs properties. Why? Because properties can ONLY be changed using the getter and setter methods. Even from inside the class. That is a Good Thing (TM) and it removes the ability to write some rather common error-prone code. Like, when someone in a re-factoring situation decides to add some sensible logic to a getter or a setter, but other parts of the same class still accesses the property directly. Badness ensues.
Lambdas and friends...
Hmmmm, seems like I just described C# as the solution to Java's problems... that was unintentional.
With some of the intrinsic problems in Java ironed out. Properties anyone? How about the mess that is Java auto-boxing?
ahem. I mean Windows Mobile 7, not Windows
I did realize that, so again, doing drugs or forgotten to take your medication? Since when did MS mandate any specific language for CLR development?
Same with Google. Obviously, with the vast number of mobile processors out there, suggesting one develops for a VM makes sense, the VM is the platform, but that doesn't mean that one mandates any particular language.
Like MS demanding Win7 apps be written in a managed language (ie C#) or Android in Dalvik/Java
I wonder what the problem is here. Have you been taking drugs or have you stopped taking your medication?
Just curious - and no I am no big fan of Adobe either - but how is Adobe doing a lock in? They do not own the OS, the developer tools in question are generally open source. What is the Adobe lock in?
We are, that is why, every time your hear beats, you find it such a problem to draw a breath.
Are you really that dumb or are you just pretending? Do you really think there is a way that Apple, or any other company, can prevent an app from allocating too much memory? Before I got my 3GS I had to reboot the iPhone every time I had played Monopoly from EA. Even after I quit Monopoly, memory would be so low that the phone became very troubled indeed. With the 3GS it is a little less of a problem, but I still have to reboot my iPhone about once a week or so, whether I play Monopoly or not. And that is when there is no multitasking apps running.
Stop sucking Jobs' dick. It isn't pretty with so many star-eyed fans queuing up just to have him sprinkle his semen on them every day.