There's nothing mysterious about it at all. You incur the run-time overheads necessary to identify the code worth optimising, to monitor the contexts in which that code is used, and then to generate the optimised code. Any optimisations you find there must then be more efficient than the statically-optimised equivalent, just to make up for the run-time overheads. Once you've reached that point, then you can start going faster.
You have just summarised Hotspot.
That's amazing! The state of the art in software-based profiling technology still incurs massive run-time overheads, yet Hotspot is able to identify highly-used code (and while running as an interpreter at first, too), gather the same sort of information about how it's being used as the profiler, and then perform more aggressive optimisations than a static code generator that's not constrained by how long it takes to run, all without significant overheads? They should file a load of patents, and then release the best C++ profiling tools in the world!
I'm assuming that they are going to. This is far easier with Java than C++ as it is a simpler language.
It's not obvious at all. You are assuming that there is sufficient scope in the extra optimisations you can identify based on run-time analysis to make up for and then exceed the time required to gather the necessary information and then perform those optimisations.
For a typical program the run time is hugely greater than the compilation time. A compiler can run as a low-priority background thread and still gather enough information to do a good job.
I'd love to, but I notice you haven't yet replied to the other post that asked you to cite any such benchmarks or evidence.
This is a lazy answer. I'm assuming people can use google. Just go to www.javasoft.com and look it up! All the information about Hotspot is there.
As for benchmarks, why not simply try code yourself? If you want evidence, the LinPack benmarks are freely available. Try them.
No, it's not. The theoretically impossible has not magically become possible because of a few more years of hype.
Yes it has, because the original post said that Java always needed to do bounds checking. Please don't label actual advances in IT 'hype'.
Consider the impact of instrumenting code for profiling. On most platforms, you don't get hardware support, and the run-time for an instrumented build can easily increase by a factor of 5-10x or more.
This is not the way Hotspot works. Please go and read about the technology before posting! It does NOT instrument the code this way.
Now, Java's Hotspot technology is basically profiling at run-time. Please read the above, and consider the overheads involved in gathering the information necessary to do the dynamic optimisation. Then consider the benefits gained by having better optimised code over just moderately optimised code. You would need a pretty favourable set of circumstances to gain much real advantage from using Hotspot, and you're risking making performance worse because of the monitoring overheads in all other cases.
You are putting a lot of your own assumptions here: firstly. that monitoring has significant overheads (it doesn't) secondly that optimising at run-time is in some mysterious way automatically inferior to optimising at compile time. The reverse is obviously correct, as run-time optimising is based on evidence of how the program is actually running, not some kind of prediction about how it might run.
I would, in return, please ask you to look at actual benchmarks and evidence rather than simply publishing your own opinions.
Actually, a LOT of that is marketing! Pascal's p-code predates the JVM by a mere 26 years. It was widely available in the late '70s in the form of UCSD Pascal.
I know. I used it. It had poor performance, and never became mainstream.
GC is also widely available. You can even do GC in C++ if you want.
Yes, but that was not designed in from the start.
Many languages are run anywhere and have libraries and VM that are truly freely distributable. (They WERE available when Java came out).
I know! I have used many, many languages that had VMs - Lisp, Smalltalk etc. They all failed when it came to performance.
The JVM is freely downloadable, but you are only allowed to tell the user where to get it, you may not just include it in your distribution.
No - there are open source VMs, and you are allowed to freely distribute Sun VMs along with any Java code you ship.
Given what I have seen from Java, the world might be a little better off without it. Not that it's in iteslf bad, but that the overhype causes it to eclipse better tools for many jobs.
Please name a single alternative that is (1) free, (2) runs on so many platforms and (3) has reasonable performance. I looked into this for many years, and Java was the only language had had all three.
Java is the most popular language for business development. Other languages had had decades to occupy this position. Java deserves its success.
Not even close. Java lacks support for efficient, user-defined, small datatypes (complex numbers, 2-vectors, 3-vectors, etc.). C, C++, and Fortran have them. They are essential for any numerical programming language. Despite 20 years of trying, people have not been able to compile that stuff efficiently automatically, and HotSpot isn't even close.
You are not arguing against the points I was making. I was saying that Java does good optimisation. Support for the datatypes you describe was not being discussed.
You statement about Hotspot is factually incorrect, as Java is already being used for numerical work and benchmarking faster than C.
Java is unsuitable for serious numerical work. C is barely suitable--it's painful, but at least you can get the work done at all.
This is self-contradicting statement, and has no factual basis. You can code exactly the same numerical algorithms in Java that you can in C, so if you are saying C is suitable, then Java is suitable. Please back this statement with evidence.
No, it does not work--just look at the dreck it has produced. It amounts to free labor for Sun. Of course, Sun gets largely what they pay for...
This is a comment without evidence. Please state what you mean. There have been some extremely high-quality JSRs produced by the JSR - the JINI stuff is an innovative Linda-based technology. The recently published JDO 2.0 is perhaps the best persistent specification ever produced.
Please, relieve me of my ignorance and post a (credible) link, a journal cite, or even an online poll with more than a few hundred votes.
Sure. Look at monster.com and it's international sites for current jobs. Or jobserve, or any of a hundred other job advert sides.
C and C++ are doing well - there is no sign of them dying out. However, Java dominates.
Well, I can certainly see the justification for that - Actually using a debugger takes skill and an understanding of the underlying architecture.
I don't agree. I have been using debuggers for close to 30 years. Debuggers deal with the way that languages represent data, not the underlying architecture.
I've never heard of a "null pointer" (pointers? oh, how crude! Everyone knows that pointers cause bugs, so languages like Java and the.NET family don't have them)
They do!
The point is that illegal use of pointers is actually trapped.
I spent years developing in C and C++ in the 80s, and it was a nightmare. I was working as part of a team developing a project. Buffer overflows would happen and the first sign you would have of this would either be random graphics, a total freeze of the PC, or a spectacular crash.
Changing the problem domain simply changes how people approach the problem. The "essence" of the code remains the same - Adding additional layers of abstraction makes it easier to grasp at a high level, but much harder to know exactly what occurs at the actual hardware level.
These days you never come anywhere close to dealing with the actual hardware level. Even what you deal with in a typical C program is virtualised and interpreted by microcode.
The best computer languages abstract the hardware level in the appropriate way to allow easy coding of algorithms.
Don't blame the hammer when the homeowner insists you finish the job in half the time and under budget, then the house falls down a few years later.
And if you believe the same (via different mechanisms) won't happen under Java, or Fortress, or any supposedly "safe" language - I have a bridge to sell you. Buffer overruns occur because of sloppy coding - In 90% of cases I've personally had to deal with, simply using snprintf() rather than sprintf() (or some comparable pair of "dumb" and "length specified" functions) would solve the problem. Do you really think that similar oversights won't affect Java in some way?
Of course you will get bugs in Java programs. But, unlike in C or C++ those bugs are actually trapped and you get traceable exception reports.
Any serious developer knows that people are fallible, and sloppy coding is a fact of life. It would great if there could be a simple announcement to all IT developers: 'stop sloppy coding now!'. All would be bliss. Unfortunately, that is never going to happen, which is why safe languages, like Java, Ada, Pascal, Modula etc. are so important, and why C/C++ can be so disastrous for general-purpose development.
Your source for that factoid? I communicate with quite a lot of real-world programmers, and although I wouldn't discount the number doing Java (mostly not by their choice), when it comes to getting actual work done, almost everyone chooses C or C++.
I don't base my understanding of the job market on nothing more than personal communication. I have spend years following the job markets and developer surveys, as I am expected to give professional advice based on facts, not opinion. By what statistical measure do you determine that most of the huge numbers of Java developers are not doing it by choice?
No, there is no speed disadvantage, there is, however, a programming disadvantage: in order to get speed in Java, you can't use any abstractions. Java is a less convenient language for numerical programming than C or Fortran 66.
This is a fair point, but it not so correct these days. The Hotspot technology in recent versions of the JVM do an amazing optimising job, removing much of the cost of inheritance and doing things like inlining.
I would say (from personal experience) that Java is vastly better than C for numerical work, as it removes the need for the memory management required in C - and mathematical coders should not have to worry about these things.
Worse, almost everything new that comes out of the JCP ends up effectively being owned by Sun. So, yes, you do have a bunch of dopes that are working for free for Sun and getting less out of it than even your typical corporate researcher; at least those still get paid.
I think it is extreme to call IBM, HP, Oracle and thousands of other members of the JCP 'dopes'.
People join the JCP because they get to change Java. This process works. (Of course there are many changes to Java outside the JCP as well, such as SWT).
Do we really, really have to go over this well-trodden ground again?
We obviously do, as the landscape has changed since last you walked it:
Sorry, JIT really helps and modern Java implementations do have some pretty good optimisations, but the design of Java fundamentally means that it will only ever approach the performance of elementary C or C++ as a limit, and there will always be a certain amount of overhead at some stage in the proceedings. You simply cannot avoid this, while still having the bounds checking, still missing value types, etc.
This is years out of date!
Optimised Java does not need to do bounds checking, and does not have this overhead. The Hotspot technology does run-time analysis so that the ranges of loops and potential value limits of variables are determined. This means that bounds checking can be removed in almost all cases.
The Hotspot optimiser does things that no C compiler can ever do - it can determine at run time the best order for machine code instructions for best use of pipelines in certain processors.
But forcing people who can actually code to use castrated languages just wastes time and resources.
Which is nothing compared to the disasters that have resulted from the use of C and C++ over 20 years. When do we NOT hear about another worm or virus resulting from a buffer overrun?
the same way Java supposedly did the same for C++, it will have marketing droids as its only fans.
I think you need to take a look at the real world, where Java is the most widely used language.
Strange. I was certain that LISP has exception handling too. As for bytecode validation, that seriously shouldn't even be necessary, and LISP makes up more than well for it with its actual structured. As for security managers, since when was security the job of the programming language rather than the operating system?
The reason for these is that Java is designed to be able to be run on minimal systems, and potentially insecure networks. Java code can be streamed across networks (e.g. as applets) and the integrity of that code can be verified. This is extremely useful for things like networked devices and embedded systems.
(1) So how is that better than emulating an x86?
The x86 architecture is not specifically designed for object-oriented languages.
(2) There were tons of interpreted languages before Java.
Yes, but none were mainstream, and widely used in almost all areas of IT.
As for portability of compiled programs rather than source code portability -- how is that better than JIT compiling or an ordinary LISP REPL? How is it better to use a binary format rather than an ASCII readable format (such as source code)?
It allows higher performance. You can have byte code that has already been put through various optimisation, so it can be started immediately and then background optimisation and translation to native code can occur. As for ASCII format - that would require compilation at the point of deployment. This takes time and takes a lot of memory - very bad for getting programs started quickly, and would rule out any serious use in embedded systems, such as mobile phones.
What, you mean the `synchronized' keyword? How is it better to use a new keyword instead of just a function?
Because they don't serve the same purpose syntactically. It is far more than just 'synchronised' - there is a lot of detail specified about how threads should behave and which actions are atomic etc. that all Java implementations must conform to.
I don't really see less choice being better.
I know this probably sounds cynical, but I do. After decades of development experience, I find that being forced to do things like exception handling had a major benefit in the quality of code; after all, we are all fallible.
Those words would carry a lot more weight if you had included an example of such a mistake. If you were thinking about C++, then I fully agree with you,
I was.
While I'm in this mood, let me crush another myth about Java vs. C, namely the "Java is more secure than C since you can't access arbitrary addresses and Java makes array bounds checks" myth. In this case, it is important to seperate the language and the architecture on which the programs run. It is not the Java language that does these things, but rather the JVM.
How can bounds checking be a 'myth' when it is happening as I write in millions of applications?
The point about Java is that it is actually possible to do bounds checking. It is not in C or C++, because of the way that arrays and pointers are defined as being equivalent.
Yet another one? Well, since you asked: The "Java is more portable and runs on all architectures" myth. In fact, Java is the least portable language I have ever seen. It only runs on one single architecture: The JVM.
This is very silly. There plenty of Java implementations (such as GCJ) that don't require a JVM at all. There have been Java-to-native compilers for years.
Java does have some extremely clever tricks, and I'm surprised that more beople don't use them.
You are right! I was thinking more of things like multiple inheritance and operator overloading, but reflection is very nice, and newer features like Proxy classes and bytecode manipulation libraries can be hugely powerful.
If you call slow and prone to crash "almost pefectly", then I agree with you.
This just isn't true at all. Java is far more robust and 'crash-proof' than C or C++ for example, and there is a lot less to go wrong - memory management is easier for example.
Perhaps what you call 'crashing' is Java throwing exceptions, revealing bugs that would have been silently ignored in languages such as C, potentially leading to data corruption.
It's becoming tiring to encounter what should be a full-fledged Windows or Mac program coded in Java because a software-maker was too stingy to develop a proper application. Remember -- programming is for users, not for developers, and if to users your program hampers productivity and feels wrong, then it is wrong.
Well that is why use I Java - because it gives me robust and high-performance server-side software that can be deployed on the OS of my choice with no changes.
I find no evidence that my websites backed by Java either 'hampers productivity' or 'feel wrong'.
(1) You give up speed for a marginal increase in features
No you don't. Recent Linpack benchmarks have shown Java can match C/C++ in terms of math performance in many benchmarks. There is no speed disadvantage for this kind of work.
(2) You give up source portability for binary portability. Almost every platform has an ansi-C compiler, yet only a handful support Java, especially if you use a recent library.
There are few platforms that now don't have Java; the statement 'only a handful' is nonsense. There are recent VMs for all major operating systems, and many minor ones. The number of platforms with GNU compilers on is enormous, which comes with GCJ.
There are more platforms that support OpenGL than Java3D, for example.
True, but I assumed we were discussing numerical language use, not games development.
(3) A company controls your language. The future of Java is at the whim of a single for-profit entity. Furthermore, this entity has displayed that it wants to control the Java language and the Java platform to the greatest extent possible.
On the contrary, almost everything about the development of Java has been handed over to the Java Community Process. Also, the VM spec and language spec are available for anyone to implement compatible languages (and many have).
It is also an open standard with MANY compilers for most platforms. Will Sun work on all of this? They didn't think it was important enough to do with Java.
On the contrary, they thought Java was so important they have battled to retain control of the language to prevent forking of the specification.
One of the major problems with Fortran is the large range of dialects, with many incompatibilities.
If Java was truly "designed for safety at the start", you just wouldn't need that kind of project
Sorry, that is false. that is a bug-finding tool, not a safety checker. Similar bug-finders are required for Ada, although they work with source code.
Java includes major safety features (like the SecurityManager) that Ada doesn't. Ada is relatively safe because it is a Pascal-like language with features, such as bounds checking and very strong type safety, that C etc. lack. Java has such bounds-checking features, but goes further than Ada, as it does not require manual memory management.
Given the phenomenal number of weird bugs that both C and Fortran developers produce because of the nature of those languages and their lack of memory management and safety, I'm sure a large number of Fortran developers would be very interested, even if you aren't.
I know java and use it where it's approiate but I can't understand why people think it's such an amazing language. I understand it's merits but it's still a normal programming language.
There are many reasons why Java is an important programming language. (1) It is probably the first really mainstream general-purpose widely-used language with garbage collection. (2) It was specifically designed for safety at the start, with things like exception handling, bytecode validation and security managers. (3) It is the first mainstream language to run mostly on a VM, so you get portability not just at the source code level, but at the level of compiled programs. (4) It was designed from the start to handle multiple threads safely.
Java is certainly not the most exciting language for developers to use, but that is not its point. Java is not a language of clever tricks and obscure code, like C++ can be. However, it is a very practical language that has learned from many of the mistakes of earlier designs.
If you have been developing for decades like me, switching to Java and finding the ability to write a program, compile it and then decide where it should be deployed (and have this work almost perfectly most of the time) is pretty amazing.
On Real-Time Systems, Java is still not a suitable candidate due to its indeterminstic garbage collection.
The nature of the garbage collection is an implementation detail, not a language feature. There have been real-time implementations of Java with deterministic garbage collection for years.
My advice is to not build huge applications in Office unless you have absolutely up-to-date versions.
My advice is not to build any huge applications in Pffice, as sooner or later your versions won't be up-to-date, and porting this kind of thing between different versions of Office has been a huge and messy exercise in the past, and there is no guarantee it won't be in the future. There is a place for large amounts of code, and it is not tied to Office-type calculations. It should be in libraries which can then be accessed by any application. This is why Windows allows COM/ActiveX development.
In modern high level languages, yes, we have more elegant syntaxes for branching. But in assembly, what is a JMP instruction anyway but a GOTO?
Which is fine if you want to program in assembler. The elegant syntaxes in high level languages are there for a reason - to help make code easier to maintain and develop.
Which is nice, but when it comes to serious mission critical software where faults can't be tolerated Ada has some advantages.
Call me when Java has anything equivalent to SPARK for validating code.
Work on this has started. Here is an example: https://www.hija.info/ "High Integrity Java".
Much of the technology for this is already in place. For example, the Hotspot optimiser for Java already does bounds prediction of some variables in order to eliminate the need for time-consuming range checks in code such as loops.
Slashdot Mirror
You could buy anything and start spinning it around, but I'm pretty sure that's not what you had in mind.
Interestingly.... no!
The electron 'spin' being discussed is a quantum mechanical property and is not the same as macroscopic rotation.
Well, one reason why many people avoid reflection in java is because it's slow. At least it was that way when I checked last time...
I find this a problem. So often on Slashdot I encounter people who comment on Java as it was 5 years ago!
Reflection is now fast in Java. It has been since Java 1.4.
There's nothing mysterious about it at all. You incur the run-time overheads necessary to identify the code worth optimising, to monitor the contexts in which that code is used, and then to generate the optimised code. Any optimisations you find there must then be more efficient than the statically-optimised equivalent, just to make up for the run-time overheads. Once you've reached that point, then you can start going faster.
You have just summarised Hotspot.
That's amazing! The state of the art in software-based profiling technology still incurs massive run-time overheads, yet Hotspot is able to identify highly-used code (and while running as an interpreter at first, too), gather the same sort of information about how it's being used as the profiler, and then perform more aggressive optimisations than a static code generator that's not constrained by how long it takes to run, all without significant overheads? They should file a load of patents, and then release the best C++ profiling tools in the world!
I'm assuming that they are going to. This is far easier with Java than C++ as it is a simpler language.
It's not obvious at all. You are assuming that there is sufficient scope in the extra optimisations you can identify based on run-time analysis to make up for and then exceed the time required to gather the necessary information and then perform those optimisations.
For a typical program the run time is hugely greater than the compilation time. A compiler can run as a low-priority background thread and still gather enough information to do a good job.
I'd love to, but I notice you haven't yet replied to the other post that asked you to cite any such benchmarks or evidence.
This is a lazy answer. I'm assuming people can use google. Just go to www.javasoft.com and look it up! All the information about Hotspot is there.
As for benchmarks, why not simply try code yourself? If you want evidence, the LinPack benmarks are freely available. Try them.
No, it's not. The theoretically impossible has not magically become possible because of a few more years of hype.
Yes it has, because the original post said that Java always needed to do bounds checking. Please don't label actual advances in IT 'hype'.
Consider the impact of instrumenting code for profiling. On most platforms, you don't get hardware support, and the run-time for an instrumented build can easily increase by a factor of 5-10x or more.
This is not the way Hotspot works. Please go and read about the technology before posting! It does NOT instrument the code this way.
Now, Java's Hotspot technology is basically profiling at run-time. Please read the above, and consider the overheads involved in gathering the information necessary to do the dynamic optimisation. Then consider the benefits gained by having better optimised code over just moderately optimised code. You would need a pretty favourable set of circumstances to gain much real advantage from using Hotspot, and you're risking making performance worse because of the monitoring overheads in all other cases.
You are putting a lot of your own assumptions here: firstly. that monitoring has significant overheads (it doesn't) secondly that optimising at run-time is in some mysterious way automatically inferior to optimising at compile time. The reverse is obviously correct, as run-time optimising is based on evidence of how the program is actually running, not some kind of prediction about how it might run.
I would, in return, please ask you to look at actual benchmarks and evidence rather than simply publishing your own opinions.
Actually, a LOT of that is marketing! Pascal's p-code predates the JVM by a mere 26 years. It was widely available in the late '70s in the form of UCSD Pascal.
I know. I used it. It had poor performance, and never became mainstream.
GC is also widely available. You can even do GC in C++ if you want.
Yes, but that was not designed in from the start.
Many languages are run anywhere and have libraries and VM that are truly freely distributable. (They WERE available when Java came out).
I know! I have used many, many languages that had VMs - Lisp, Smalltalk etc. They all failed when it came to performance.
The JVM is freely downloadable, but you are only allowed to tell the user where to get it, you may not just include it in your distribution.
No - there are open source VMs, and you are allowed to freely distribute Sun VMs along with any Java code you ship.
Given what I have seen from Java, the world might be a little better off without it. Not that it's in iteslf bad, but that the overhype causes it to eclipse better tools for many jobs.
Please name a single alternative that is (1) free, (2) runs on so many platforms and (3) has reasonable performance. I looked into this for many years, and Java was the only language had had all three.
Java is the most popular language for business development. Other languages had had decades to occupy this position. Java deserves its success.
Not even close. Java lacks support for efficient, user-defined, small datatypes (complex numbers, 2-vectors, 3-vectors, etc.). C, C++, and Fortran have them. They are essential for any numerical programming language. Despite 20 years of trying, people have not been able to compile that stuff efficiently automatically, and HotSpot isn't even close.
You are not arguing against the points I was making. I was saying that Java does good optimisation. Support for the datatypes you describe was not being discussed.
You statement about Hotspot is factually incorrect, as Java is already being used for numerical work and benchmarking faster than C.
Java is unsuitable for serious numerical work. C is barely suitable--it's painful, but at least you can get the work done at all.
This is self-contradicting statement, and has no factual basis. You can code exactly the same numerical algorithms in Java that you can in C, so if you are saying C is suitable, then Java is suitable. Please back this statement with evidence.
No, it does not work--just look at the dreck it has produced. It amounts to free labor for Sun. Of course, Sun gets largely what they pay for...
This is a comment without evidence. Please state what you mean. There have been some extremely high-quality JSRs produced by the JSR - the JINI stuff is an innovative Linda-based technology. The recently published JDO 2.0 is perhaps the best persistent specification ever produced.
Please, relieve me of my ignorance and post a (credible) link, a journal cite, or even an online poll with more than a few hundred votes.
.NET family don't have them)
Sure. Look at monster.com and it's international sites for current jobs. Or jobserve, or any of a hundred other job advert sides.
C and C++ are doing well - there is no sign of them dying out. However, Java dominates.
Well, I can certainly see the justification for that - Actually using a debugger takes skill and an understanding of the underlying architecture.
I don't agree. I have been using debuggers for close to 30 years. Debuggers deal with the way that languages represent data, not the underlying architecture.
I've never heard of a "null pointer" (pointers? oh, how crude! Everyone knows that pointers cause bugs, so languages like Java and the
They do!
The point is that illegal use of pointers is actually trapped.
I spent years developing in C and C++ in the 80s, and it was a nightmare. I was working as part of a team developing a project. Buffer overflows would happen and the first sign you would have of this would either be random graphics, a total freeze of the PC, or a spectacular crash.
Changing the problem domain simply changes how people approach the problem. The "essence" of the code remains the same - Adding additional layers of abstraction makes it easier to grasp at a high level, but much harder to know exactly what occurs at the actual hardware level.
These days you never come anywhere close to dealing with the actual hardware level. Even what you deal with in a typical C program is virtualised and interpreted by microcode.
The best computer languages abstract the hardware level in the appropriate way to allow easy coding of algorithms.
Don't blame the hammer when the homeowner insists you finish the job in half the time and under budget, then the house falls down a few years later.
And if you believe the same (via different mechanisms) won't happen under Java, or Fortress, or any supposedly "safe" language - I have a bridge to sell you. Buffer overruns occur because of sloppy coding - In 90% of cases I've personally had to deal with, simply using snprintf() rather than sprintf() (or some comparable pair of "dumb" and "length specified" functions) would solve the problem. Do you really think that similar oversights won't affect Java in some way?
Of course you will get bugs in Java programs. But, unlike in C or C++ those bugs are actually trapped and you get traceable exception reports.
Any serious developer knows that people are fallible, and sloppy coding is a fact of life. It would great if there could be a simple announcement to all IT developers: 'stop sloppy coding now!'. All would be bliss. Unfortunately, that is never going to happen, which is why safe languages, like Java, Ada, Pascal, Modula etc. are so important, and why C/C++ can be so disastrous for general-purpose development.
Your source for that factoid? I communicate with quite a lot of real-world programmers, and although I wouldn't discount the number doing Java (mostly not by their choice), when it comes to getting actual work done, almost everyone chooses C or C++.
I don't base my understanding of the job market on nothing more than personal communication. I have spend years following the job markets and developer surveys, as I am expected to give professional advice based on facts, not opinion. By what statistical measure do you determine that most of the huge numbers of Java developers are not doing it by choice?
No, there is no speed disadvantage, there is, however, a programming disadvantage: in order to get speed in Java, you can't use any abstractions. Java is a less convenient language for numerical programming than C or Fortran 66.
This is a fair point, but it not so correct these days. The Hotspot technology in recent versions of the JVM do an amazing optimising job, removing much of the cost of inheritance and doing things like inlining.
I would say (from personal experience) that Java is vastly better than C for numerical work, as it removes the need for the memory management required in C - and mathematical coders should not have to worry about these things.
Worse, almost everything new that comes out of the JCP ends up effectively being owned by Sun. So, yes, you do have a bunch of dopes that are working for free for Sun and getting less out of it than even your typical corporate researcher; at least those still get paid.
I think it is extreme to call IBM, HP, Oracle and thousands of other members of the JCP 'dopes'.
People join the JCP because they get to change Java. This process works. (Of course there are many changes to Java outside the JCP as well, such as SWT).
Do we really, really have to go over this well-trodden ground again?
We obviously do, as the landscape has changed since last you walked it:
Sorry, JIT really helps and modern Java implementations do have some pretty good optimisations, but the design of Java fundamentally means that it will only ever approach the performance of elementary C or C++ as a limit, and there will always be a certain amount of overhead at some stage in the proceedings. You simply cannot avoid this, while still having the bounds checking, still missing value types, etc.
This is years out of date!
Optimised Java does not need to do bounds checking, and does not have this overhead. The Hotspot technology does run-time analysis so that the ranges of loops and potential value limits of variables are determined. This means that bounds checking can be removed in almost all cases.
The Hotspot optimiser does things that no C compiler can ever do - it can determine at run time the best order for machine code instructions for best use of pipelines in certain processors.
But forcing people who can actually code to use castrated languages just wastes time and resources.
Which is nothing compared to the disasters that have resulted from the use of C and C++ over 20 years. When do we NOT hear about another worm or virus resulting from a buffer overrun?
the same way Java supposedly did the same for C++, it will have marketing droids as its only fans.
I think you need to take a look at the real world, where Java is the most widely used language.
(1) Lisp
You do understand the meaning of the word 'mainstream?'
(2) Ha ha, no.
Er, yes.
(3) Also Lisp.
See answer to (1)
Strange. I was certain that LISP has exception handling too. As for bytecode validation, that seriously shouldn't even be necessary, and LISP makes up more than well for it with its actual structured. As for security managers, since when was security the job of the programming language rather than the operating system?
The reason for these is that Java is designed to be able to be run on minimal systems, and potentially insecure networks. Java code can be streamed across networks (e.g. as applets) and the integrity of that code can be verified. This is extremely useful for things like networked devices and embedded systems.
(1) So how is that better than emulating an x86?
The x86 architecture is not specifically designed for object-oriented languages.
(2) There were tons of interpreted languages before Java.
Yes, but none were mainstream, and widely used in almost all areas of IT.
As for portability of compiled programs rather than source code portability -- how is that better than JIT compiling or an ordinary LISP REPL? How is it better to use a binary format rather than an ASCII readable format (such as source code)?
It allows higher performance. You can have byte code that has already been put through various optimisation, so it can be started immediately and then background optimisation and translation to native code can occur. As for ASCII format - that would require compilation at the point of deployment. This takes time and takes a lot of memory - very bad for getting programs started quickly, and would rule out any serious use in embedded systems, such as mobile phones.
What, you mean the `synchronized' keyword? How is it better to use a new keyword instead of just a function?
Because they don't serve the same purpose syntactically. It is far more than just 'synchronised' - there is a lot of detail specified about how threads should behave and which actions are atomic etc. that all Java implementations must conform to.
I don't really see less choice being better.
I know this probably sounds cynical, but I do. After decades of development experience, I find that being forced to do things like exception handling had a major benefit in the quality of code; after all, we are all fallible.
Those words would carry a lot more weight if you had included an example of such a mistake. If you were thinking about C++, then I fully agree with you,
I was.
While I'm in this mood, let me crush another myth about Java vs. C, namely the "Java is more secure than C since you can't access arbitrary addresses and Java makes array bounds checks" myth. In this case, it is important to seperate the language and the architecture on which the programs run. It is not the Java language that does these things, but rather the JVM.
How can bounds checking be a 'myth' when it is happening as I write in millions of applications?
The point about Java is that it is actually possible to do bounds checking. It is not in C or C++, because of the way that arrays and pointers are defined as being equivalent.
Yet another one? Well, since you asked: The "Java is more portable and runs on all architectures" myth. In fact, Java is the least portable language I have ever seen. It only runs on one single architecture: The JVM.
This is very silly. There plenty of Java implementations (such as GCJ) that don't require a JVM at all. There have been Java-to-native compilers for years.
I am not talking about webserver apps.
If you are talking about Java, that is where it is overwhelmingly used.
Java does have some extremely clever tricks, and I'm surprised that more beople don't use them.
You are right! I was thinking more of things like multiple inheritance and operator overloading, but reflection is very nice, and newer features like Proxy classes and bytecode manipulation libraries can be hugely powerful.
If you call slow and prone to crash "almost pefectly", then I agree with you.
This just isn't true at all. Java is far more robust and 'crash-proof' than C or C++ for example, and there is a lot less to go wrong - memory management is easier for example.
Perhaps what you call 'crashing' is Java throwing exceptions, revealing bugs that would have been silently ignored in languages such as C, potentially leading to data corruption.
It's becoming tiring to encounter what should be a full-fledged Windows or Mac program coded in Java because a software-maker was too stingy to develop a proper application. Remember -- programming is for users, not for developers, and if to users your program hampers productivity and feels wrong, then it is wrong.
Well that is why use I Java - because it gives me robust and high-performance server-side software that can be deployed on the OS of my choice with no changes.
I find no evidence that my websites backed by Java either 'hampers productivity' or 'feel wrong'.
(1) You give up speed for a marginal increase in features
No you don't. Recent Linpack benchmarks have shown Java can match C/C++ in terms of math performance in many benchmarks. There is no speed disadvantage for this kind of work.
(2) You give up source portability for binary portability. Almost every platform has an ansi-C compiler, yet only a handful support Java, especially if you use a recent library.
There are few platforms that now don't have Java; the statement 'only a handful' is nonsense. There are recent VMs for all major operating systems, and many minor ones. The number of platforms with GNU compilers on is enormous, which comes with GCJ.
There are more platforms that support OpenGL than Java3D, for example.
True, but I assumed we were discussing numerical language use, not games development.
(3) A company controls your language. The future of Java is at the whim of a single for-profit entity. Furthermore, this entity has displayed that it wants to control the Java language and the Java platform to the greatest extent possible.
On the contrary, almost everything about the development of Java has been handed over to the Java Community Process. Also, the VM spec and language spec are available for anyone to implement compatible languages (and many have).
It is also an open standard with MANY compilers for most platforms. Will Sun work on all of this? They didn't think it was important enough to do with Java.
On the contrary, they thought Java was so important they have battled to retain control of the language to prevent forking of the specification.
One of the major problems with Fortran is the large range of dialects, with many incompatibilities.
Safety?
My ass, try ADA for that one
If Java was truly "designed for safety at the start", you just wouldn't need that kind of project
Sorry, that is false. that is a bug-finding tool, not a safety checker. Similar bug-finders are required for Ada, although they work with source code.
Java includes major safety features (like the SecurityManager) that Ada doesn't. Ada is relatively safe because it is a Pascal-like language with features, such as bounds checking and very strong type safety, that C etc. lack. Java has such bounds-checking features, but goes further than Ada, as it does not require manual memory management.
I don't think I want to learn this language...
Given the phenomenal number of weird bugs that both C and Fortran developers produce because of the nature of those languages and their lack of memory management and safety, I'm sure a large number of Fortran developers would be very interested, even if you aren't.
I know java and use it where it's approiate but I can't understand why people think it's such an amazing language. I understand it's merits but it's still a normal programming language.
There are many reasons why Java is an important programming language. (1) It is probably the first really mainstream general-purpose widely-used language with garbage collection. (2) It was specifically designed for safety at the start, with things like exception handling, bytecode validation and security managers. (3) It is the first mainstream language to run mostly on a VM, so you get portability not just at the source code level, but at the level of compiled programs. (4) It was designed from the start to handle multiple threads safely.
Java is certainly not the most exciting language for developers to use, but that is not its point. Java is not a language of clever tricks and obscure code, like C++ can be. However, it is a very practical language that has learned from many of the mistakes of earlier designs.
If you have been developing for decades like me, switching to Java and finding the ability to write a program, compile it and then decide where it should be deployed (and have this work almost perfectly most of the time) is pretty amazing.
On Real-Time Systems, Java is still not a suitable candidate due to its indeterminstic garbage collection.
The nature of the garbage collection is an implementation detail, not a language feature. There have been real-time implementations of Java with deterministic garbage collection for years.
My advice is to not build huge applications in Office unless you have absolutely up-to-date versions.
My advice is not to build any huge applications in Pffice, as sooner or later your versions won't be up-to-date, and porting this kind of thing between different versions of Office has been a huge and messy exercise in the past, and there is no guarantee it won't be in the future. There is a place for large amounts of code, and it is not tied to Office-type calculations. It should be in libraries which can then be accessed by any application. This is why Windows allows COM/ActiveX development.
In modern high level languages, yes, we have more elegant syntaxes for branching. But in assembly, what is a JMP instruction anyway but a GOTO?
Which is fine if you want to program in assembler. The elegant syntaxes in high level languages are there for a reason - to help make code easier to maintain and develop.
Which is nice, but when it comes to serious mission critical software where faults can't be tolerated Ada has some advantages.
Call me when Java has anything equivalent to SPARK for validating code.
Work on this has started. Here is an example:
https://www.hija.info/
"High Integrity Java".
Much of the technology for this is already in place. For example, the Hotspot optimiser for Java already does bounds prediction of some variables in order to eliminate the need for time-consuming range checks in code such as loops.