I like getters/setters in Java because in practice, the JVM compiles everything down to native code and aggressively inlines. So typical getters/setters cost nothing and are direct accesses to member variables. But it gives you the flexibility to later make the getter/setter do something else without affecting other code.
Suppose you were to change the getter/setter and then dynamically re-load the class at runtime in a running system. The JVM will immediately de-optimize (go back to interpreted bytecode) for all methods that now have stale inlined code (from the old version of the class). Dynamic profiling may then quickly reveal that the de-optimized code is (still, as it was before) an actual CPU hot spot, causing it to get re-compiled again, and if appropriate, to have those getters/setters inlined, or not.
The JVM compiler is like having a global -O 5 optimizer that can optimize globally across the actual code running on the machine, and the code generator of the compiler is tailored to your actual hardware and whatever instruction set extensions it might have.
The JVM as a runtime platform will probably outlast the Java language.
Your never going too get you're weigh on this.
Their are just two many people out they're using there words wrong too get to upset.
Sew don't loose you're cool about it.
You can sea mini common examples that exist of incorrect usage.
People pick the write words two use according too there porpoises.
But you'd have two be a fool to begin or end a sentence with the word "but".
And only an idiot would begin or end a sentence with "and".
And a preposition is a very bad word too end a sentence with.
Hey, it's always easier to blame the programming language for things done by stupid developers, stupid practices, stupid managers, stupid organizations, stupid vendors, stupid requirements, and stupid teachers.
But your list of the bashing comment types is right on the money as evidence in these comments.
While operator overloading can be used for good, it is far more often used to create huge messes. It makes the simplest expressions impossible to understand locally because now, everywhere there is an operator, you cannot be sure what is actually going on. IMO, operator overloading is evil, despite the good intentions.
I hear you about type erasure for generics.
Lambda statements in Java are a recent addition. But I hear you about first class functions. There are a lot of other languages that run on the JVM platform and are interoperable with Java. And many of these have first class functions. JavaScript (Nashorn), Clojure (a modern lisp with concurrency and immutable structures), Groovy, Scala and many others. And the interoperability is very real -- because they all pass around the very same underlying types and objects from the underlying runtime system.
I hear you about lack of properties and the annoyance of getters/setters. IDEs help, but its not the same thing. (like kissing your boyfriend through a veil)
Please don't assume that bad developers and practices are intrinsically tied to a language or platform. As I said in this same thread, that kind of stupidity transcends languages.:-)
You forgot: . . . and not check the licensing conditions of all those 3rd party packages.
I have not switched to Maven . . . so far.
But your 'three line loop' example is NOT a Java problem. That same kind of stupidity transcends languages, platforms and tools, and often opens up career paths into management.
Don't blame Java for that. It is the fault of many managers. They want cheap, interchangeable droids to build their applications. Run them hard, burn them out, throw them away like a used spark plug. They're cheap to replace. So those managers want a language all these droids understand. So not only do you get experts, but hoards of below average drones who's main skill is interviewing and taking certification exams. (aka 'certified idiots')
Any programming language could have stumbled into that phenomena. It just happened to be Java. That doesn't make Java itself bad. If anything, the huge community of wealthy enterprise Java users has benefited the Java ecosystem tremendously.
The platform itself has its major strengths. For just one example, in 2012, Twitter switched from Ruby to Java because Java could scale. You need major scalability when you handle a billion tweets per day and must route each of them to many destinations and platforms. It doesn't matter how much cpu / memory the platform uses, it matters that you can scale it linearly by just adding more boxes. Java already has a lot of ecosystem and infrastructure that enables that kind of scalability. You can google for twitter's 2012 switch from Ruby to Java, and they also have (last time I looked a year or so ago) a lengthy YouTube video presentation discussing the benefits of the change after the fact.
In ways that affect most programmers, for most everyday purposes, Java is an advance over Pascal just as Pascal was an advance over earlier languages. Just as Pascal gave you new powerful tools (structured programming without GOTO, data structures, strong typing, recursion, etc), Java gives you more new tools (objects, inheritance, polymorphism, garbage collection, a very large standard library, object code portability across platforms), later on the JVM brought portable source level debugging, dynamic profiling and hotspot compilation, better and more sophisticated garbage collection, and more.
Ultimately it depends on what your goals are. If you are writing high performance video codecs, or signal processing, for example, then you would probably not use Java.
But for many everyday things, Java is great. That is probably why it is so widely used to build huge enterprise software projects that should run for decades;.
> you could in theory make an Enterprise class application in GWBASIC.
In theory you could make Enterprise applications in assembly language. Or write the direct machine instructions in Hex. An IDE might help. But the language you use also plays a large part. Perhaps larger than the IDE. The IDE is a lever that helps leverage the power of the language that you start with. If the language you start with (GWBASIC or machine code) isn't that high level, abstract or powerful, then the IDE can only help you leverage what you have, which isn't much.
You seriously have no clue what Java is used for nor how huge its ecosystem is. For years and to this very day Java is always shifting between the number one and number two spots of most widely used programming languages. The amount of enterprise software written in Java is so large that Java may never go away. There are certain things that Java is very good at, which is why it is used. It's not perfect for everything. If there were one perfect language, everyone would already be using it.
Yes, it is a function of the IDE. But the language itself has something to do with why this was easy enough to implement for Java that it was done long ago and not just recently. I'm sure that even for the Java language it is not easy to implement. But the language is statically typed. You cannot reference members via strings (like in JavaScript). The meaning of an identifier does not depend on anything that happened at runtime prior to that identifier being used. It is possible to statically analyze the code easily without so much research into what might affect the meaning of the code you're looking at. No operator overloading (that also affects readability, or ability to abuse things).
The read() function (and writeln()) are not even functions. They are built ins in the compiler. Sure, they compile to calls in the pascal runtime library. But you cannot control where read/write go to except through implementation specific tricks, if at all. In Java there is no behind the scenes magic.
Every part of the operation, the I/O, the parsing, the byte to character conversion (using what char encoding?) is explicit. And all these small pieces can be wired together in infinite ways. You get access to all the small nuts and bolts. In Pascal you don't get access to what ever integer parser that was used by read().
I'm not saying there is anything wrong with Pascal. I loved it for a dozen years covering the 1980's and into the 1990's.
In Java you can in just two or three lines of code make your own simple to use read() function using the basic parts.
I think you are not understanding the insight behind the maintenance remark.
Tools that work on the Java source code can be exact in what they do. No ambiguity exists. A method call foo() is understood by the compiler to be exactly one certain method. It doesn't matter how many other foo() declarations there are, or that there may also be variables and classes named 'foo'. The tooling makes maintenance tasks like refactoring very easy.
If I am reading some dynamic languages, I might have to do some searching or research to determine exactly what is being called by this foo() function call. Java tools can tell you exactly, prior to compile time, what method is being called -- and that it is declared, and where it is. The tooling doesn't get confused no matter how badly the code might be structured.
Maintenance becomes a big factor on a huge code base. The cost of maintenance can truly dwarf the cost of initial development.
Java has not stagnated. It is one of the top programming languages. You would know this if you had looked at the article. You might not like Java, and that is fine. But at least get your facts right.
Write once run anywhere is also true for large projects. You could move a major web server project between OSes without even recompiling it. I have personally moved installed my employer's web application on a different OS than it is officially deployed on just for amusement. Because it could be done. I also tried it on a Raspberry Pi (prior to the 2) and it 'ran' (in the sense of how a snail can 'run'). But it actually worked and connected to a database server running on a big box running a different OS.
GC on Android is not a problem. Billions of devices are in daily use. What kind of 'problem' are you talking about? Something hypothetical?
Java at Google may be a fork, but it can't be any worse the the multiple dialects of other languages and compilers like C / C++ or Python 2 / 3 and other examples.
Java is not perfect for every problem. If there were a perfect programming language, everyone would already be using it. But at least get your facts right. Java is going to be around for a very long time. The language has just gotten some major new features in the last couple releases. More major improvements are on the horizon. The sheer size of Java codebases alone is proof enough that it will be around for a long time.
You'd think that the industrial strength JVM might also have something to do with it.
You can have a JVM with a heap of tens of Gigabytes and with a modestly tuned (not extremely tuned) configuration, have Garbage Collection times in the tens of milliseconds. If you need hundreds of Gigabytes in your heap, Azul can sell you a JVM that can do this with GC pauses of about 10 ms.
The JVM dynamically compiles the bytecode down to native code. Not like a C compiler does ahead of time. But it compiles it for the actual processor and features that your hardware has. The JVM compiler aggressively inlines methods instead of making function calls. So there is no drawback to writing lots of small methods. Even tiny methods like getters and setters. You can dynamically reload a class binary at runtime. But what if the new class has a new implementation of a method that some other foobar method had inlined by the compiler? No problem. The JVM knows this and it de-optimizes the class that had the foobar method so that it no longer has inlined a 'stale' version of the code in the class that was just now dynamically reloaded. If dynamic profiling reveals that the foobar method truly is a hotspot for the cpu, then the JVM will again compile it to native code -- based on the now current conditions of what code is in the overall system. It's like having a global -O 5 optimizer that can dynamically change / recompile any or every thing based on any code changes dynamically made to the running system. Want to change from a carburetor to caffeine injection while driving down the road at 70 mph? No problem.
Call me when a dynamic language or other system can do that.
Is it any wonder that so many languages other than Java also run on the JVM? The JVM might even stick around longer than the Java language.
The JVM and Java run on the smallest systems to big iron. The SIM card in your phone is a tiny self contained secure tamper proof computer -- running Java. It verifies certificates using a private key that was forged inside the SIM and never leaves the SIM. Your Blue Ray player runs Java. You can write a Java program that provides the 'menu interface' for your disk. Old flip phones from 2000 run Java.
Serendipity could also mean that it was in the right place, at the right time, and that is why the base of code written in Java become so huge. It solved a problem. And did so better than other solutions at the time. And arguably, still does.
Other solutions may look sexy. And for smaller projects, they probably are.
But long term maintainability is important. Does your project still need to work in ten years? Twenty?
Having a compiler is also probably a major factor to Java success. If I make a typo in my code that breaks something, red flags start appearing on files in the source code tree all over the project for files that no longer will be able to compile. Lots of things that dynamic languages don't discover until runtime (or hopefully unit testing) are immediately discovered by the compiler. In a sense, the compiler is the zeroth step of unit testing before you even run the unit tests. The compiler effectively provides the first most basic set of 'tests' on the codebase.
People who don't understand why Java sticks around also don't comprehend the sheer size of some Java code bases. I would like to see what would happen if a dynamic language were used to write a system that had hundreds of different forms or over a thousand; and maybe thousands of different reports it could produce.
I'm not saying there is anything wrong with other languages. Just that Java does have a place. It is a solution to a real problem.
If there were one perfect programming language, then everyone would already be using it.
Readability goes along with 'toolability'. The fact that tools can 'understand' Java code and therefore can correctly make so many kinds of automated changes to the source code is a major sign of readability. If it is not possible to make tools that can do precise and sophisticated manipulations of the source code, then chances are that humans cannot understand it easily.
As an example of what I mean by 'toolable'. When I rename a variable in Java, every instance of that variable throughout the entire project are changed. This is not a dumb 'search and replace'. It is a precise change made by tools that use most of the Java compiler front end in order to make these changes. Similarly if I rename a method, the change is precisely made throughout the source code. It doesn't matter if there is a variable, or a class or even another method elsewhere with the same name, there can be no possible confusion. Just as the compiler has no confusion about what identifier 'foo' in some line of code refers to, the renaming and refactoring processes are equally precise. That is what is meant by toolable.
Not only do you have to re-learn basic elements every decade, you might have to rewrite very old code to work on current systems.
The people who make these incompatible changes vastly underestimate the cost of such incompatibilities.
The sheer amount of working Java code is not only why the language will stay around for a long time, but economically represents a very large amount of wealth.
Slashdot Mirror
I like getters/setters in Java because in practice, the JVM compiles everything down to native code and aggressively inlines. So typical getters/setters cost nothing and are direct accesses to member variables. But it gives you the flexibility to later make the getter/setter do something else without affecting other code.
Suppose you were to change the getter/setter and then dynamically re-load the class at runtime in a running system. The JVM will immediately de-optimize (go back to interpreted bytecode) for all methods that now have stale inlined code (from the old version of the class). Dynamic profiling may then quickly reveal that the de-optimized code is (still, as it was before) an actual CPU hot spot, causing it to get re-compiled again, and if appropriate, to have those getters/setters inlined, or not.
The JVM compiler is like having a global -O 5 optimizer that can optimize globally across the actual code running on the machine, and the code generator of the compiler is tailored to your actual hardware and whatever instruction set extensions it might have.
The JVM as a runtime platform will probably outlast the Java language.
> It seems the hackers are demanding money else they will release the rest of the data.
Would the hackers instead release the data in exchange for money?
Your never going too get you're weigh on this. Their are just two many people out they're using there words wrong too get to upset. Sew don't loose you're cool about it. You can sea mini common examples that exist of incorrect usage. People pick the write words two use according too there porpoises. But you'd have two be a fool to begin or end a sentence with the word "but". And only an idiot would begin or end a sentence with "and". And a preposition is a very bad word too end a sentence with.
I made such an effort to conceal my sexual orientation!
Or not using a large enough font or large enough monitor. Or using a font where the asterisk glyph is visually similar to a quote glyph.
Hey, it's always easier to blame the programming language for things done by stupid developers, stupid practices, stupid managers, stupid organizations, stupid vendors, stupid requirements, and stupid teachers.
But your list of the bashing comment types is right on the money as evidence in these comments.
While operator overloading can be used for good, it is far more often used to create huge messes. It makes the simplest expressions impossible to understand locally because now, everywhere there is an operator, you cannot be sure what is actually going on. IMO, operator overloading is evil, despite the good intentions.
I hear you about type erasure for generics.
Lambda statements in Java are a recent addition. But I hear you about first class functions. There are a lot of other languages that run on the JVM platform and are interoperable with Java. And many of these have first class functions. JavaScript (Nashorn), Clojure (a modern lisp with concurrency and immutable structures), Groovy, Scala and many others. And the interoperability is very real -- because they all pass around the very same underlying types and objects from the underlying runtime system.
I hear you about lack of properties and the annoyance of getters/setters. IDEs help, but its not the same thing. (like kissing your boyfriend through a veil)
Please don't assume that bad developers and practices are intrinsically tied to a language or platform. As I said in this same thread, that kind of stupidity transcends languages. :-)
You forgot: . . . and not check the licensing conditions of all those 3rd party packages.
I have not switched to Maven . . . so far.
But your 'three line loop' example is NOT a Java problem. That same kind of stupidity transcends languages, platforms and tools, and often opens up career paths into management.
Don't blame Java for that. It is the fault of many managers. They want cheap, interchangeable droids to build their applications. Run them hard, burn them out, throw them away like a used spark plug. They're cheap to replace. So those managers want a language all these droids understand. So not only do you get experts, but hoards of below average drones who's main skill is interviewing and taking certification exams. (aka 'certified idiots')
Any programming language could have stumbled into that phenomena. It just happened to be Java. That doesn't make Java itself bad. If anything, the huge community of wealthy enterprise Java users has benefited the Java ecosystem tremendously.
The platform itself has its major strengths. For just one example, in 2012, Twitter switched from Ruby to Java because Java could scale. You need major scalability when you handle a billion tweets per day and must route each of them to many destinations and platforms. It doesn't matter how much cpu / memory the platform uses, it matters that you can scale it linearly by just adding more boxes. Java already has a lot of ecosystem and infrastructure that enables that kind of scalability. You can google for twitter's 2012 switch from Ruby to Java, and they also have (last time I looked a year or so ago) a lengthy YouTube video presentation discussing the benefits of the change after the fact.
It sounds like your gripe is with a badly run project, organization and practices rather than a programming language.
In ways that affect most programmers, for most everyday purposes, Java is an advance over Pascal just as Pascal was an advance over earlier languages. Just as Pascal gave you new powerful tools (structured programming without GOTO, data structures, strong typing, recursion, etc), Java gives you more new tools (objects, inheritance, polymorphism, garbage collection, a very large standard library, object code portability across platforms), later on the JVM brought portable source level debugging, dynamic profiling and hotspot compilation, better and more sophisticated garbage collection, and more.
Ultimately it depends on what your goals are. If you are writing high performance video codecs, or signal processing, for example, then you would probably not use Java.
But for many everyday things, Java is great. That is probably why it is so widely used to build huge enterprise software projects that should run for decades;.
> you could in theory make an Enterprise class application in GWBASIC.
In theory you could make Enterprise applications in assembly language. Or write the direct machine instructions in Hex. An IDE might help. But the language you use also plays a large part. Perhaps larger than the IDE. The IDE is a lever that helps leverage the power of the language that you start with. If the language you start with (GWBASIC or machine code) isn't that high level, abstract or powerful, then the IDE can only help you leverage what you have, which isn't much.
You seriously have no clue what Java is used for nor how huge its ecosystem is. For years and to this very day Java is always shifting between the number one and number two spots of most widely used programming languages. The amount of enterprise software written in Java is so large that Java may never go away. There are certain things that Java is very good at, which is why it is used. It's not perfect for everything. If there were one perfect language, everyone would already be using it.
VirtualBox keeps getting updated regularly. A new VirtualBox 5 is in beta even as version 4 upgrades come out regularly.
For C users:
// makes code faster // makes data use less memory
#define while if
#define struct union
Yes, it is a function of the IDE. But the language itself has something to do with why this was easy enough to implement for Java that it was done long ago and not just recently. I'm sure that even for the Java language it is not easy to implement. But the language is statically typed. You cannot reference members via strings (like in JavaScript). The meaning of an identifier does not depend on anything that happened at runtime prior to that identifier being used. It is possible to statically analyze the code easily without so much research into what might affect the meaning of the code you're looking at. No operator overloading (that also affects readability, or ability to abuse things).
Pascal would be 1970's.
The read() function (and writeln()) are not even functions. They are built ins in the compiler. Sure, they compile to calls in the pascal runtime library. But you cannot control where read/write go to except through implementation specific tricks, if at all. In Java there is no behind the scenes magic.
Every part of the operation, the I/O, the parsing, the byte to character conversion (using what char encoding?) is explicit. And all these small pieces can be wired together in infinite ways. You get access to all the small nuts and bolts. In Pascal you don't get access to what ever integer parser that was used by read().
I'm not saying there is anything wrong with Pascal. I loved it for a dozen years covering the 1980's and into the 1990's.
In Java you can in just two or three lines of code make your own simple to use read() function using the basic parts.
I think you are not understanding the insight behind the maintenance remark.
Tools that work on the Java source code can be exact in what they do. No ambiguity exists. A method call foo() is understood by the compiler to be exactly one certain method. It doesn't matter how many other foo() declarations there are, or that there may also be variables and classes named 'foo'. The tooling makes maintenance tasks like refactoring very easy.
If I am reading some dynamic languages, I might have to do some searching or research to determine exactly what is being called by this foo() function call. Java tools can tell you exactly, prior to compile time, what method is being called -- and that it is declared, and where it is. The tooling doesn't get confused no matter how badly the code might be structured.
Maintenance becomes a big factor on a huge code base. The cost of maintenance can truly dwarf the cost of initial development.
You do not know what you are talking about.
Java has not stagnated. It is one of the top programming languages. You would know this if you had looked at the article. You might not like Java, and that is fine. But at least get your facts right.
Write once run anywhere is also true for large projects. You could move a major web server project between OSes without even recompiling it. I have personally moved installed my employer's web application on a different OS than it is officially deployed on just for amusement. Because it could be done. I also tried it on a Raspberry Pi (prior to the 2) and it 'ran' (in the sense of how a snail can 'run'). But it actually worked and connected to a database server running on a big box running a different OS.
GC on Android is not a problem. Billions of devices are in daily use. What kind of 'problem' are you talking about? Something hypothetical?
Java at Google may be a fork, but it can't be any worse the the multiple dialects of other languages and compilers like C / C++ or Python 2 / 3 and other examples.
Java is not perfect for every problem. If there were a perfect programming language, everyone would already be using it. But at least get your facts right. Java is going to be around for a very long time. The language has just gotten some major new features in the last couple releases. More major improvements are on the horizon. The sheer size of Java codebases alone is proof enough that it will be around for a long time.
You'd think that the industrial strength JVM might also have something to do with it.
You can have a JVM with a heap of tens of Gigabytes and with a modestly tuned (not extremely tuned) configuration, have Garbage Collection times in the tens of milliseconds. If you need hundreds of Gigabytes in your heap, Azul can sell you a JVM that can do this with GC pauses of about 10 ms.
The JVM dynamically compiles the bytecode down to native code. Not like a C compiler does ahead of time. But it compiles it for the actual processor and features that your hardware has. The JVM compiler aggressively inlines methods instead of making function calls. So there is no drawback to writing lots of small methods. Even tiny methods like getters and setters. You can dynamically reload a class binary at runtime. But what if the new class has a new implementation of a method that some other foobar method had inlined by the compiler? No problem. The JVM knows this and it de-optimizes the class that had the foobar method so that it no longer has inlined a 'stale' version of the code in the class that was just now dynamically reloaded. If dynamic profiling reveals that the foobar method truly is a hotspot for the cpu, then the JVM will again compile it to native code -- based on the now current conditions of what code is in the overall system. It's like having a global -O 5 optimizer that can dynamically change / recompile any or every thing based on any code changes dynamically made to the running system. Want to change from a carburetor to caffeine injection while driving down the road at 70 mph? No problem.
Call me when a dynamic language or other system can do that.
Is it any wonder that so many languages other than Java also run on the JVM? The JVM might even stick around longer than the Java language.
The JVM and Java run on the smallest systems to big iron. The SIM card in your phone is a tiny self contained secure tamper proof computer -- running Java. It verifies certificates using a private key that was forged inside the SIM and never leaves the SIM. Your Blue Ray player runs Java. You can write a Java program that provides the 'menu interface' for your disk. Old flip phones from 2000 run Java.
Serendipity could also mean that it was in the right place, at the right time, and that is why the base of code written in Java become so huge. It solved a problem. And did so better than other solutions at the time. And arguably, still does.
Other solutions may look sexy. And for smaller projects, they probably are.
But long term maintainability is important. Does your project still need to work in ten years? Twenty?
Having a compiler is also probably a major factor to Java success. If I make a typo in my code that breaks something, red flags start appearing on files in the source code tree all over the project for files that no longer will be able to compile. Lots of things that dynamic languages don't discover until runtime (or hopefully unit testing) are immediately discovered by the compiler. In a sense, the compiler is the zeroth step of unit testing before you even run the unit tests. The compiler effectively provides the first most basic set of 'tests' on the codebase.
People who don't understand why Java sticks around also don't comprehend the sheer size of some Java code bases. I would like to see what would happen if a dynamic language were used to write a system that had hundreds of different forms or over a thousand; and maybe thousands of different reports it could produce.
I'm not saying there is anything wrong with other languages. Just that Java does have a place. It is a solution to a real problem.
If there were one perfect programming language, then everyone would already be using it.
Readability goes along with 'toolability'. The fact that tools can 'understand' Java code and therefore can correctly make so many kinds of automated changes to the source code is a major sign of readability. If it is not possible to make tools that can do precise and sophisticated manipulations of the source code, then chances are that humans cannot understand it easily.
As an example of what I mean by 'toolable'. When I rename a variable in Java, every instance of that variable throughout the entire project are changed. This is not a dumb 'search and replace'. It is a precise change made by tools that use most of the Java compiler front end in order to make these changes. Similarly if I rename a method, the change is precisely made throughout the source code. It doesn't matter if there is a variable, or a class or even another method elsewhere with the same name, there can be no possible confusion. Just as the compiler has no confusion about what identifier 'foo' in some line of code refers to, the renaming and refactoring processes are equally precise. That is what is meant by toolable.
Not only do you have to re-learn basic elements every decade, you might have to rewrite very old code to work on current systems.
The people who make these incompatible changes vastly underestimate the cost of such incompatibilities.
The sheer amount of working Java code is not only why the language will stay around for a long time, but economically represents a very large amount of wealth.
final T up = (T) throwable;
throw up;