Is Java the platform of the future?
markclittle.blogspot.co.uk
markclittle.blogspot.co.uk
Except for a major redesign of the JVM (is that still Java?), it's a dying/stagnating platform.
With java, you have tons of libraries for doing complex computing, the ones that come to mind first for me are search oriented ones like Apache Lucene / Solr as well as NLP libs, etc... Java no longer needs to try to be the "end all" solution, but are there other platforms that have the wealth of libraries for working with big data? (honestly am a bit curious about this)
No, I mean that if you completely redesign the JVM, you might as well invent a new language/VM without all the crap that comes from backwards compatibility (e.g. type erasure for generics, value types, ...).
I agree that dynamic languages won't replace Java, and C/C++ can't compete for business applications either, but I'm betting on a new language that combines the benefits of static&dynamic, object&functional programming. C# would be a powerful contender, if it were truly cross-platform.
Legacy code is a big "problem", however, all these projects already have language/platform neutral API (e.g. Thrift interfaces), so integrating them into new environments will be much easier than it was in the past.
Like Scala? Already 8 years old.
2) http://news.cnet.com/8301-13579_3-57410476-37/apples-securit...
3) http://krebsonsecurity.com/2012/03/new-java-attack-rolled-in...
Oracle has been irresponsible if not reckless on the security front; between them and Adobe, you have the source for most of the malware attacks out there.
If a company sold locks to everyone in America, and failed to notice that their locks accepted any key, I'd like to think they'd be held accountable in some way for the ensuing wave of burglaries.
I know, security isn't trivial. But if you're deploying software this widely, you have a duty to the public to hire yourself a security aware dev team and make half an effort.
For the concurrency model and heap I'm not competent enough to debate, but for the other stuff you say I can't agree. For functional programming in Java there are a lot of ways of doing it and tutorials as well, starting from those on DeveloperWorks
https://www.ibm.com/developerworks/java/library/j-fp/index.h...
and OpenJDK shows that it is OpenSource indeed. For example, JBoss (Red Hat's division) uses OpenJDK.
And I don't get the point of redesigning the JVM? What's wrong with it now? Is it's architecture somewhat wrong? Please elaborate..
Let me elaborate. There are no tail calls. The GC is not suited to functional programs (lots of small, short-lived allocations) (though that has been improving recently). No first class functions (you have to make an object with a method instead). I might be wrong, but that's a significant overhead.
WUT? That's _exactly_ the thing the GC is good at, and it's that way not since yesterday.
The limiting factor is the speed of allocation (no GC involved), not GC.
That's how OCaml does it. I'm not sure how to do it concurrency-safe, though. Maybe using small per-thread heaps that get collected whenever an object is shared between threads, or by statically inferring which objects can be shared and which are thread-local.
That's also how the JVM does it. You can criticise the JVM on some things, but GC performance is not one of them. You should really make sure you're better informed before posting FUD like this.
It has a number of assumptions hardcoded into its design, making it difficult to use it as a target architecture for programming languages that have different requirements.
You run into problems currently if you need structs, complex numbers, unusal parameter-passing conventions (call by reference, call by name, call by value-result), currying, tail calls, multiple dispatch, multiple inheritance, structural subtyping, algebraic datatypes, continuations, fast thread-local variables, micro-threads, coroutines, ICON/Python/C#/Sather-style generators, nested functions, software transactional memory, etc.
It is not that you cannot have these features (after all, the JVM is Turing-complete, and quite a few JVM languages do support them), it's that at some point using the JVM loses its advantages over, say, targeting the LLVM or CLR. On top of that you have JVM-specific downsides to deal with (such as a fairly large memory footprint even for small processes).
It also can't fix the overhead issues involved with, say, complex numbers (which may or may not get fixed in the future [1]). Try to do a simple Gaussian elimination on a 1000x1000 matrix of complex numbers, for example. The indirections and per-object overhead are bad for your processor cache.
[1] https://blogs.oracle.com/jrose/entry/value_types_in_the_vm
> Most of it is supported in Scala
scalac does not use trampolining. It rewrites tail-recurisve calls into “loops” (or jumps if you look at the bytecode).
This is a case where the JVM lacks the necessary feature.
There are experiments with value classes in Scala, which might allow you to use arrays of primitive numbers for them, but currently it looks like it won't happen for 2.10 because it can't be made work good enough in some corner cases like reflection, toString, equality, ...
The proposed value classes in Scala do not solve the overhead problem for complex numbers. As specified in SIP-15, they have exactly one field, and basically are designed to give you information hiding for classes with a single field without boxing overhead.
Edit: By the way, you don't have to sell me on Scala. I have been using it since 1.x (I have forgotten the exact version number).
> No, Scala cannot optimize all forms of tail recursion (such as mutually tail-recursive functions). In that case, you have to use scala.util.control.TailCalls to do it via trampolines.
I guess we are just nick-picking each other here. :-) I think be both understand what the compiler can do, cannot do, what it does automatically and what not.
Have you seen the Complex implementation which uses an underlying Long as Floats? (Sounds ugly but seems to work quite nicely.)
The biggest problem at the moment is putting value types in an array. Currently it seems like some ugly clutch/work-around ill be used. I hope SIP-15 gets either rejected or delayed until there is a better solution, Because the difference between an array of references and an array of primitives really matters imho.
You're factually wrong about the open-source thing: the primary impl of Java is open source (http://hg.openjdk.java.net/jdk7u/jdk7u). Sure, some impls like Azul might not be - but that's the joy of an Open language with a real spec, anyone can write an impl under any license they choose.
The claim that Objects have 'too much' overhead is subjective - but also basically wrong. Generally Objects in Java have 8 bytes of straight book-keeping overhead, plus padding to get the size of the fields to the nearest multiple of 8 bytes. That's expensive relative to C, but cheap compared to almost any other object oriented, GCd language (and can often be avoided via primitives, escape analysis, etc). For reference, CPython (the main Python impl) has ~30 bytes of overhead on an Int between tag bits, book keeping, etc last time I investigated.
How do you think the Java concurrency model is flawed? Almost any concurrency model I can think of, from Erlang-style message passing (see: Akka) to the new Fork/Join framework can be implemented in Java since its concurrency primitives are complete. I've even done basic impls of STM on AtomicRefs. Frankly, Java has one of the better defined and fine-grained concurrency models I know of. C++ just got a well-defined memory model in the '11 standard IIRC (vs '04 for the JVM).
I'm with you on the functional programming thing - syntax on anonymous inner classes and a lack of type inference make it way too verbose. But it's (largely) fixed via Project Lambda in Java 8. And, in the meantime, there are plenty of great JVM languages (Scala, Clojure, etc) with better support.
As I read Wikipedia, HotSpot is opensource. I'm not sure if that includes the best JIT compiler (what the JVM is known for) as well, or if that's still closed/proprietary, but I'd be pleasantly surprised if it's open source as well. Still, we have the patents issue, i.e. the current legal battle between Google and Oracle. Releasing the source but suing anyone who uses it is not the way to do open source, IMGO (true, the source was release by Sun, and Oracle is the one who's suing, but still).
I believe that a general purpose programming language (suitable for business applications) has to be able to perform as well as C for heavily optimized code. What I mean is that you have to be able to write algorithms that run very fast. You can probably do that with C# (supports unboxed structs) and maybe even Objective-C (supports MemoryPools, and method lookup caching), but not Java (AFAIK). Sure, you can always link to external C libraries, but then you have to face dependency hell and portability issues.
The issue that I see with Java's concurrency model is not that it is not powerful enough, but that it is too powerful. It allows synchronization on any heap-allocated object, which probably has a lot of overhead (used to be performance overhead, but HotSpot was heavily optimized for that, so after a lot of programmer-hours overhead, the performance overhead was lowered). However, I think that this kind of threading model is not scalable to massively parallel/distributed environments. Synchronization/sharing will have to be limited, e.g. as in Erlang/WebWorkers/Rust, using GCD in Objective-C, using MVar (Haskell) or transactional variables (Clojure). Java probably can never do that, without sacrificing backwards compatibility.
Lack of support for functional programming was meant more on the JVM level. There are no tail calls, no fast object allocation, no true polymorphism, and I'm guessing that since closures have to be represented as objects, they are not particularly cheap.
- The case between Oracle and Google is not related to the code released by Sun/Oracle.
- You can write heavily optimized code in Java that is as fast or faster than C, without using escape hatches.
- There is no overhead for things you don't use (synchronization).
- The JVM has probably the fastest general-purpose implementation for concurrency primitives for high-level languages. See for example: http://letitcrash.com/post/20397701710/50-million-messages-p...
- The lack of tail calls is very annoying. The rest just works. -
The patent issues are regarding Dalvik AFAIK, so I don't see how it's relevant to this discussion ... (although, from what I've heard, it seems like Oracle's being a jerk ...)
If you think that a general purpose language has to be able perform as well as C without calling native code (JNI, FFI, etc), I guess I'd have to agree Java isn't 'general purpose' . But I'd contend neither are Python, Ruby, Erlang, Javascript, etc under that definition. Therefore, that's probably not the right definition, since it excludes most general purpose languages ;-)
Being able to synchronize on any object is actually really efficiently implemented (8 bytes of Object overhead total, neat optimizations like biased locking, etc). And, if you don't want to share state between threads, Java can do pretty clean actors/message passing (http://doc.akka.io/docs/akka/2.0/java/untyped-actors.html) or transactional variables (AtomicRefs are built in). Java concurrency does give you the ability to shoot yourself in the foot if you use it wrong, but so will any sufficiently powerful tool.
Re the JVMs support for FP:
- JVM7 added an InvokeDynamic instruction which I believe addresses your polymorphism concerns.
- It sucks that there isn't a bytecode instruction to allow TCO. But, in practice, many JVM languages will convert recursion to iteration at compile time with constructs like http://clojure.org/special_forms#Special%20Forms--(recur%20e...
- What do you mean by 'fast object allocation'? I'm not familiar with the term ... Creating objects is fairly fast in Java though. A quick test suggests I can alloc around 200 million objects per second on the heap once the code path is JIT'd on my laptop. Incidentally, it's surprisingly tricky to fool the JVMs escape analysis and force a heap (not stack) allocation, without introducing too much extra work in a microbenchmark ;-).
- AFAIK, you're right that closures require an object allocation - but how else would you do it? When I was writing Common Lisp, we had to avoid creating closures in tight loops for the same reason
http://www.reddit.com/r/scala/comments/m1dks/poor_performanc...
I don't know if this is what the author originally intended, but as a most-of-the-time .NET programmer, I do see one glaring flaw to Java that falls along these lines, and which I believe is inherited from the JVM (I've heard of it being a problem for people trying to write a C# compiler that targets the JVM): There's no concept of a user defined pass-by-value type. There are only primitive types and reference types (i.e., objects).
This does create some overhead. It means that for any instance of a user-defined type you have to use additional resources in two ways which may be unnecessary: First, it goes on the heap, so it invariably adds to the garbage collector's workload. Second, it's always going to be internally referenced indirectly via a pointer. That's an extra 4-8 bytes that could be significant overhead for a sufficiently small type - say, a struct that represents an RGBA value as four separate bytes. That's also poorer locality of reference, in a way that I suspect could bite when you're dealing with large collections of small elements.
Everything is pass-by-value, but I understand what I mean.
> Second paragraph ...
Yes, it all sounds legit. But in reality, it is often quite different and after the JIT compiler ran not a single object allocation or dereference is left. It's not like JVM engineers are stupid, you know. :-)
EDIT: here's a language running on rubinius (a ruby VM) http://rubini.us/2011/02/23/introduction-to-fancy/
ah, and as java on the desktop has been dead for a couple of years, I think security holes are a minor issue. We've got firewalls for that!
That said and rather meta: That blog had the most mobile friendly layout I encountered so far.
I keep hearing this from PHP people, too. :-) Yes, it is not as bad as PHP, but probably just 15 years behind modern language design.