Full disclosure, we are a Java bytecode toolchain and runtime, and Java language runtime environment vendor.
Thus I am completely biased.
Don't know what the statement "Java core" is dead means. We offer a true hard realtime environment,
competitive with, and far more reliable than C, C++, or probably anything else short of Ada.
We are the leadership on the JCP Realtime Specification for Java (RTSJ) JSR, and participate in
several other JSRs. We offer a lightweight process, multithreaded, multicore, secure, dynamic
application framework product. We have a feature rich product suite, and continue to enhance it.
Would say that the general interest in using Java continues to grow as more and more management
realizes that depending on weak languages like C or C++ costs their companies in development,
maintenance, and product support.
Another huge advantage of Java bytecodes is all the other languages that compile to it, and
more being developed all the time (e.g. JRuby, Jython, Groovy, Scala, Clojure).
I would challenge anyone to come up with a wider adopted, scalable, safe and reliable system than
Java bytecodes, Java runtime, Java APIs, the Java language, the other languages, the application
frameworks (e.g. OSGi), the vast amount of open source software, the number of universities
using Java for teaching and research, and the vast amount of developer tools.
Such a comment about Java belies near-zero knowledge of the software development community.
I would go further to suggest that if the kernel development for Linux and similar OS's that
are all C code related, were removed from a comparison of use of languages, the use of
Java would far dominate the use of C.
But as I said at the outset, I am biased. Maybe there is another runtime environment,
community and language that is competitive and a better choice than Java...
The GPL precludes Oracle or anyone else controlling what is done with the GPL source code. That is the intent of the GPL license on any source code.
The OpenJDK is under the GPL, Java is not. That is, Oracle owns the brand Java when referring to the runtime and runtime classes.
Thus you can't "fork Java" by forking the OpenJDK. Referring to the Java programming language or a runtime that runs programs
written in the Java programming language,such as running on the OpenJDK is allowed. There are no claims of certification with
Oracle's Java with the OpenJDK. To be certified as Java and allowed to use the Java logo, an implementation must pass the TCK tests.
Although I saw a previous comment that the TCK's are also under GPL open source, I believe to be certified as Java, a
TCK license is required from Oracle.
From my reading of the appeallant ruling, Google did not claim the use of the OpenJDK and thus the protection of the GPL license
for Android. I don't know if this was claimed in the original trial or not. My reading of the GPL is that Oracle would not
have been able to claim copyright infringement on the OpenJDK APIs since the APIs are published as open source under the GPL for
the OpenJDK. However, Oracle would be able to claim Java branding infringement and the Java logo if Google made claims
Android was Java or "ran Java" instead of stating that it ran an implementation of the OpenJDK.
To return to limitations placed on GPL source code, the only limitation is that changes to the source code are also published. There
are no limitations on what is done to the source code. It is perfectly legitimate to make a derived work that deletes small or large portions
of the source code. There isn't even a requirement that the derived work actually "work". Thus a derived work using the OpenJDK can
do anything desired with the source code provided the terms of the GPL are met.
I've just read all the comments on 802.11g versus 802.11b, the raw data rates and data throughput. What I don't see is any discussion of how the raw data rates train down with distance as the signal strength weakens, and how the slower devices will then slow down the entire wireless network, even if there is a 20 Mbps. throughput potential.
Claiming that you will see 20 Mbps. in the real world is only true if you are within the a distance allowing for maximum raw data rates (54 Mbps.). This is not a fixed distance, but in my limited experience is 50 feet or less without obstacles such as walls.
Slashdot Mirror
Full disclosure, we are a Java bytecode toolchain and runtime, and Java language runtime environment vendor. Thus I am completely biased. Don't know what the statement "Java core" is dead means. We offer a true hard realtime environment, competitive with, and far more reliable than C, C++, or probably anything else short of Ada. We are the leadership on the JCP Realtime Specification for Java (RTSJ) JSR, and participate in several other JSRs. We offer a lightweight process, multithreaded, multicore, secure, dynamic application framework product. We have a feature rich product suite, and continue to enhance it. Would say that the general interest in using Java continues to grow as more and more management realizes that depending on weak languages like C or C++ costs their companies in development, maintenance, and product support. Another huge advantage of Java bytecodes is all the other languages that compile to it, and more being developed all the time (e.g. JRuby, Jython, Groovy, Scala, Clojure). I would challenge anyone to come up with a wider adopted, scalable, safe and reliable system than Java bytecodes, Java runtime, Java APIs, the Java language, the other languages, the application frameworks (e.g. OSGi), the vast amount of open source software, the number of universities using Java for teaching and research, and the vast amount of developer tools. Such a comment about Java belies near-zero knowledge of the software development community. I would go further to suggest that if the kernel development for Linux and similar OS's that are all C code related, were removed from a comparison of use of languages, the use of Java would far dominate the use of C. But as I said at the outset, I am biased. Maybe there is another runtime environment, community and language that is competitive and a better choice than Java...
The GPL precludes Oracle or anyone else controlling what is done with the GPL source code. That is the intent of the GPL license on any source code. The OpenJDK is under the GPL, Java is not. That is, Oracle owns the brand Java when referring to the runtime and runtime classes. Thus you can't "fork Java" by forking the OpenJDK. Referring to the Java programming language or a runtime that runs programs written in the Java programming language,such as running on the OpenJDK is allowed. There are no claims of certification with Oracle's Java with the OpenJDK. To be certified as Java and allowed to use the Java logo, an implementation must pass the TCK tests. Although I saw a previous comment that the TCK's are also under GPL open source, I believe to be certified as Java, a TCK license is required from Oracle. From my reading of the appeallant ruling, Google did not claim the use of the OpenJDK and thus the protection of the GPL license for Android. I don't know if this was claimed in the original trial or not. My reading of the GPL is that Oracle would not have been able to claim copyright infringement on the OpenJDK APIs since the APIs are published as open source under the GPL for the OpenJDK. However, Oracle would be able to claim Java branding infringement and the Java logo if Google made claims Android was Java or "ran Java" instead of stating that it ran an implementation of the OpenJDK. To return to limitations placed on GPL source code, the only limitation is that changes to the source code are also published. There are no limitations on what is done to the source code. It is perfectly legitimate to make a derived work that deletes small or large portions of the source code. There isn't even a requirement that the derived work actually "work". Thus a derived work using the OpenJDK can do anything desired with the source code provided the terms of the GPL are met.
I've just read all the comments on 802.11g versus 802.11b, the raw data rates and data throughput.
What I don't see is any discussion of how the raw data rates train down with distance as the signal strength weakens, and how the slower devices will then slow down the entire wireless network, even if there is a 20 Mbps. throughput potential.
Claiming that you will see 20 Mbps. in the real world is only true if you are within the a distance allowing for maximum raw data rates (54 Mbps.). This is not a fixed distance, but in my
limited experience is 50 feet or less without obstacles such as walls.