If Java Is Dying, It Sure Looks Awfully Healthy

Hugh Pickens DOT Com writes "Andrew Binstock writes at Dr. Dobb's that a recurring prejudice in the forums where the cool kids hang out is against Java, often described as verbose and fading in popularity but Binstock sees little supporting evidence of Java being in some kind of long-term decline. While it is true that Java certainly can be verbose, several scripting languages have sprung up which are purpose-designed to spare developers from long syntactical passages to communicate a simple action, including NetRexx, Groovy, and Scala. As far as Java's popularity goes, normally, when technologies start their ultimate decline, tradeshows are the first to reflect the disintegrating community. But the recent JavaOne show was clearly larger and better attended than it has been in either of the last two years and vendors on the exhibiting floor were unanimous in saying that traffic, leads, and inquiries were up significantly over last year. Technically, the language continues to advance says Binstock. Java 8, expected in March, will add closures (that is, lambda expressions) that will reduce code, diminish the need for anonymous inner classes, and facilitate functional-like coding. Greater modularity which will be complete in Java 9 (due in 2016) will help efficient management of artifacts, as will several enhancements that simplify syntax in that release. 'When you add in the Android ecosystem, whose native development language is Java, it becomes very difficult to see how a language so widely used in so many areas — server, Web, desktop, mobile devices — is in some kind of decline,' concludes Binstock. 'What I'm seeing is a language that is under constant refinement and development, with a large and very active community, which enjoys a platform that is widely used for new languages. None of this looks to me like a language in decline.'"

Comments

Re:Wake me up...

[nitehawk214]

Wake me up when netcraft confirms it. Until then it's not dying.

scripting language?

[Anonymous Coward]

Is Java a scripting language? I think anyone that thinks Scala is a scripting language, whatever that is, doesn't know what they are talking about.

Re:Scripting Language?

[narcc]

It's a completely meaningless term. When you see someone arguing about whether or not a given language is a "scripting language", just assume that they're morons.

Java already had closures

[Anonymous Coward]

Java had closures in the form of Anonymous classes. While it is true that lamda expressions will be much more concise, it is not correct to suggest that closures are being added with Java 8.

I often hear that Java "doesn't have closures." Since anonymous methods can capture variables within the scope of their declaration, they are closures.

I also frequently hear that Java is "interpreted," but that's a whole 'nother discussion.

Re:Java already had closures

[Anonymous Coward]

Since anonymous methods can capture variables within the scope of their declaration, they are closures.

Only if variables in the outer scope are declared final, which works well for anything that's immutable or if you don't need to change an immutable without returning the new value. (final == const, but final !=== const, ymmv, etc)

Re:Java already had closures

[lgw]

That entirely misses the point. The conciseness is the entire point.

If I have a list of strings, and want to append ".txt" to each, using a for loop is just one more annoying piece of COBOLesque boilerplate.

fileNames = names.Map(n => n + ".txt");

That's what you want.

docFileNames = names.Where(n => n.StartsWith("Doc")).Map(n => n + ".txt");

You can understand what that does even though I just make up the methods. That's the damn point.

Re:Java already had closures

[Hentes]

Java doesn't have closures and it won't have any in Java8 either. A closure isn't the same as a lambda. In a closure, free variables are stored by reference, and their changes are reflected in the closure. Java8 lambdas require all free variables to be final.

Re:Java already had closures

[tyrione]

That entirely misses the point. The conciseness is the entire point.

If I have a list of strings, and want to append ".txt" to each, using a for loop is just one more annoying piece of COBOLesque boilerplate.

fileNames = names.Map(n => n + ".txt");

That's what you want.

docFileNames = names.Where(n => n.StartsWith("Doc")).Map(n => n + ".txt");

You can understand what that does even though I just make up the methods. That's the damn point.

In short, you want the for loop to be done behind the scenes without you writing the code and just referencing a method to call that loop?

Re:Java already had closures

[stewsters]

If conciseness is more important than structure, you could use you could use Groovy:

["here","is","a", "list", "of", "strings"].collect{it+".txt"}
Result: [here.txt, is.txt, a.txt, list.txt, of.txt, strings.txt]

["Dochere","is","Doca", "list", "of", "strings"].collect{ it + (it.startsWith("Doc") ? ".txt" : '' )}
Result: [Dochere.txt, is, Doca.txt, list, of, strings]

That compiles down to a jar you can use from Java.

Re:Java already had closures

[tonywestonuk]

I find the following easier to know whats going on:

I don't understand that. I do understand:

Arraylist docFileNames = new Arraylist();
for (String name:names)
                            docFileNames.add(name+".txt");

Re:Java already had closures

[lgw]

No, the for loop is a needless intrusion. If you're used to LISP-like languages, you wonder what all this wasteful for-loop-obsession is in other languages. But then, people talk about "map reduce solutions" on "big data" without even knowing those are canonical names for LISP functions for common list-processing tasks.

Methods that clearly express an intent to operate across a collection of data are simply more straightforward. There's a limited set of such operations, they're quite common patterns, and there's no need to do boilerplate for them every time. Lambda is needed to avoid the boilerplate.

Re:Java already had closures

[lgw]

No, the "original purpose" of closures is the abstract algebra od the lambda calculus, which is neither here nor there - that's very far removed from production code. The place where lambda make for better production code is for in-place definition of simple functions that need no name and aren't returned out of their context. Objects in most languages let you do the more general-purpose encapsulation of state that closures are the primitive for - and that's nothing new.

Re:Java already had closures

[lgw]

Sure, but "real" closures are just objects with only 1 method, a not very interesting primitive, outside of the academic study of computability and the most primitive forms from which all else can be built.

Re:Java already had closures

[ahabswhale]

FFS, anonymous inner classes aren't even close to being closures. Anyone who's ever used real closures could tell you that. AICs are a hideous frankenstein monster of a construct that should have never been included in the language in the first place. I would go so far as to say that they are one of the biggest mistakes in the language and had they actually added real closures early in the development of the language, the java programming world would be vastly better for it. It's not like closures are a new invention. There's no real excuse for it other than shortsightedness. It's the same level of retardation that gets you into the situation where new BigDecimal(0) doesn't actually equal zero. I could go on but I think I've made my point.

Scala is a scripting language?

[bendilts]

Funny, I thought Scala was a fully compiled, statically type-checked language (at least as much as Java is). A language is not a scripting language just because it doesn't suck.

Re:Scala is a scripting language?

[pscottdv]

More to the point, it's not Java. It's Scala.

Re:Scala is a scripting language?

[binarylarry]

Scala is basically C++ on the JVM.

It's what Java would be if the stewards of Java weren't so conservative (or lazy) about new features.

The powerful features of Scala tend to make code unreadable months down the road in my experience. :(

Re:Scala is a scripting language?

[GuldKalle]

That doesn't mean it's not compiled. It just means that it's compiled automatically and possibly saved to a temporary location.

Re:Scala is a scripting language?

[slack_justyb]

Java only promised write once and run anywhere. Nowhere in that promise was write once, be able to read it later. <<Takes cover>> :-D

Re:Scala is a scripting language?

[marcosdumay]

A language is not a scripting language just because it doesn't suck.

Are you sure about that? I always tough not sucking was the definition of "scripting language".

Re:Scala is a scripting language?

[dkf]

Java only promised write once and run anywhere. Nowhere in that promise was write once, be able to read it later.

Oh, you can read it later. It's just so damn verbose that you'd better set aside a long time for reading it...

Re:Scala is a scripting language?

[DickBreath]

> I always tough not sucking was the definition of "scripting language".

Then Perl is obviously not a scripting language.

Re:Scala is a scripting language?

[jeremyp]

Scala is basically C++ on the JVM.

No. Scala is a functional programming language, it's nothing like C++.

Re:Scala is a scripting language?

[Lawrence_Bird]

Scala is not C++, sorry.

Re:Scala is a scripting language?

[AmaDaden]

The wiki def for a Scripting language is "A scripting language or script language is a programming language that supports the writing of scripts, programs written for a special run-time environment that can interpret and automate the execution of tasks which could alternatively be executed one-by-one by a human operator." Check out this video and you'll see that Scala can do this. Scala is a weird hybrid. It's a full powered language build on top of the JVM that can run as a script or be compiled directly in to Java bytecode.

Re:Scala is a scripting language?

[Douglas Goodall]

That is always how I felt about COBOL, closer to English than any other language at the time.

Re:Scala is a scripting language?

[GuldKalle]

Java can run in a console, too. Does scala have an equivalent to python or javascript eval()?

Re:Scala is a scripting language?

[AmaDaden]

Java and Scala can both be run in the console but, as the video shows, Scala can be run AS a console. Scala code can be run one line at a time in a Scala console or compiled. Java code can only be compiled. By the above given definition, this makes Scala a scripting language.

Scala does have similar support to eval with the ScalaInterpreter class.

If in fact it is dying...

[scottnix]

I wish it would get the fuck on with it. Type erasure.

Re:If in fact it is dying...

[Anonymous Coward]

Fixing that will be one of the main features of Java 9. It's too bad it is taking so long to address that.

Re: Wake me up...

[DVega]

It has an unsigned 16 bits integer. It is called "char"

javas not dead!

[nimbius]

I use it on mission critical applications at work and it does a very efficient job of testing all the functionality of Nagios to page me at 3:00 AM. I have other java applications that are designed to explore the limits of slab allocation and heap return in memory. Theres even a java application I wrote that calculates financial reports. I know what you're thinking, and yes, it performs well as it stress-tests VoIP bandwidth and the helpdesk ticket system.

there are still so many uses for java. one of my earliest and oldest projects I still use to this day! its an application to help post Slashdot comme!####)))!%[NO CARRIER]

Re:javas not dead!

[znanue]

I only use two Java applications: Liferea (after google reader died) and Jitsi. When I start them, I can feel the sadness in my computer. They take ages to startup, but granted, after they've started they're just like any regular native application. Though Jitsi doesn't integrate well with gtk3, but overall it is pretty good.

You can't know this unless you purposefully don't want to count using web apps as "using an app". My understanding is the backend of much of the google stuff is written in Java, just as an obvious example.

Re:javas not dead!

[dmbasso]

I use plenty of Java applications, I have an Android phone. I was referring to those that I have to run a JVM in my computer, sorry for being vague.

Re:javas not dead!

[X0563511]

32-bit or 64-bit JVM?

If you're using the 64-bit, I don't think they have a client hotspot (optimized for quick-start) JVM, only the server (optimized for runtime throughput but with a long startup) one.

Re:javas not dead!

[MightyMartian]

Microsoft could only wish .NET had the penetration Java has. Java may have its stinky bits, but at the end of the day, it's value is its ability to run on a large number of divergent platforms, from cell phones to supercomputers, running multiple operating systems and architectures.

Re:javas not dead!

[lgw]

have other java applications that are designed to explore the limits of slab allocation and heap return in memory

You remind me of far to many C programmers I've met (and projects I've been on).

"Look I've reinvented that difficult plumbing built into C++ - my language is just as good as C++!"

"Yeah. How much time did that take? How many nightmarish bugs did you overcome?"

"Lots. And a few."

"Time well spent then, I'm sure, and my best wishes that there's not one last plumbing bug that you'll find in the field".

Different tools for different jobs. C++ isn't the right tool for much, but nothing else comes close for jobs that actually need the cruft that clutters C++. Taking over memory allocation is a perfect example. (Checking an object every time it's dereferenced to make sure it hasn't been freed or worse, re-used is another - man that's a stupid problem to solve in Java or C#.)

Re:javas not dead!

[dmbasso]

Damn, you are right! The worse part is that I just assumed it was Java because it was slow (the whole startup behavior matched the Java timing pattern), but I never actually verified. In the end it was just terrible coding...
I apologize for my misinfo and prejudice... ;)

Re:javas not dead!

[RCL]

I don't think "an app" applies to web "applications" and not sure those two will ever blend. The depedency on a (good) connection is still a problem, if you are commuting or, say, torrenting. Even on mobile devices, people want offline maps and offline dictionaries precisely for the reason of being location-independent.

Re:javas not dead!

[RCL]

Java abstracts away all the fun in programming. You cannot really target specific hardware with it, and it means you cannot get (close to) maximum performance on any given piece of hardware - you are deprived of control over processor cache, memory locality of data and code, or access to vector instructions. JIT, which "compiles" the code piecewise, is at obvious disadvantage compared to a proper compiler that has global view of the program (and JIT is also more time constrained, compiler can spend hours compiling the code), and uncontrollable garbage collector means that you will have hard time enforcing even "soft realtime" requirements.

Different people may look differently, but for me, all that means that Java is suboptimal for games or other heavily performance-oriented stuff, and this is the only kind of software I enjoy programming. Making performance-insensitive backends full of "business logic" is for someone who is in the software industry for money only...

Re:javas not dead!

[petsounds]

I think people find different sorts of fun in programming. For you, the fun may be getting down to the metal and squeezing every drop of hardware performance. For others, the fun may lie in the expressiveness of the language itself, where code feel more like poetry. In both cases Java misses the mark. Java feels more like it was designed by the same people who designed Soviet apartment blocks – soulless and severe. Entirely focused on function without the human form in mind, or any aspirations to truly inspired work.

Re:javas not dead!

[RCL]

I like that comparison with soulless apartment blocks. To be fair, it wasn't only Soviets who built those - I have seen similar unimaginative housing in US, too. Either way, Java indeed feels like a typical business, "no nonsense" solution and I can picture a grey, dull world of a corporate 9-to-5 programmer for whom Monday is the worst day of the week. Don't want to work like that.

Re:javas not dead!

[RCL]

I know that some HFT platforms are written in Java, but I think this is caused by other reasons than trying to attain maximum performance. E.g. it is certainly harder to find programmers who have both high- and low-level skills (i.e. know hardware well and have good understanding of math, for instance).

As for "better than JIT" argument, I think you are putting too much trust into a rather generic approach. Even traditional (and performance oriented) compilers don't handle all use cases well and you can hit a roadblock there too, let alone all the fundamental problems with "managed" code (e.g. random memory access patterns which hurt CPU caches, various safety checks, stack-based VM design that doesn't map well to register-based hardware - stack-based processors are at inherent performance disadvantage, by the way, that's why Intel shunned FPU in favor of register-based SSE). My statement of JIT weakness is supported by the well-known fact that server-side software rarely has great single-thread performance (and often it doesn't need it, but it's another topic), so server CPUs tend to have gobs of cache in order to alleviate that.

Again... language (syntax, etc) doesn't matter much for me, I wouldn't mind Java if it allowed me to get as close to hardware as possible, even via non-portable extensions. It's the layers of code to profile and debug through and resulting feeling of not being in control is what I don't like.

Re:javas not dead!

[Xest]

"As for "better than JIT" argument, I think you are putting too much trust into a rather generic approach."

It's not generic, that's the point. You have a JIT compiler specific to the platform, or at least, a generic one configured for the platform on which it has been installed, and that allows it to optimise for the specific platform it is executing on. In contrast, with, say, C++, you tend to only compile for a generic architecture, otherwise you end up with a combinatorial explosion of binaries for every case. This is why all in all, Java normally performs as well as C++.

"My statement of JIT weakness is supported by the well-known fact that server-side software rarely has great single-thread performance (and often it doesn't need it, but it's another topic), so server CPUs tend to have gobs of cache in order to alleviate that."

What do you mean server-side software doesn't have great single-thread performance? I could write a WCF web service right now and set it to single thread mode and it'll perform exactly the same on a desktop as it will an equivalently performant server. There's a lot of server software that's optimised for multi-threaded environments, but that's because normally when you're serving you rarely want to only be able to serve one client at a time and normally want to be able to serve multiple clients simultaneously. Server CPUs having more cache has literally fuck all to do with JIT compilers, I don't know where you came up with such an absurd idea. Server CPUs have more cache because a) corporations that buy such servers are more willing to accept the additional cost of greater CPU cache than consumers who would balk at CPU prices if consumer CPUs had more cache, and b) because it's extremely beneficial for many server applications, for example, databases.

"I wouldn't mind Java if it allowed me to get as close to hardware as possible, even via non-portable extensions."

Then pay attention to the GP's suggestion of using JNI. Sure you're not writing in Java, but that's not what Java was ever designed for. For the bits where you genuinely need to go native though, Java provides an interface, whilst for the bits where you don't, you can avoid all the pitfalls that come with doing so and gain the benefits of Java.

Re:javas not dead!

[tibit]

Checking an object every time it's dereferenced to make sure it hasn't been freed or worse, re-used is another - man that's a stupid problem to solve

What are you talking about? This applies neither to C++ nor to Java. Heck, there is in fact no way of checking for either directly, whether in C++ or in Java. You can hack around it in C++ by adding code to the destructor that will mark the object as "freed" in some global dictionary, but what's the point of doing that I wouldn't know. If you need such code, you're doing it wrong.

In Java it's even simpler: if you can access the object, it's there, or you've hit a garbage collector bug or a bit flip in your hardware. There's basically no way of freeing an object. You can reset the reference, but that's it. It's same as in modern C++: if you use std::weak_ptr, you may get a nullptr and you must check for it. If you use a std::shared_ptr and it's non-nullptr, the object is there, and it won't magically become nullptr unless you reset it.

Re:javas not dead!

[lgw]

what's the point of doing that I wouldn't know. If you need such code, you're doing it wrong.

Ahh "I don't understand the ned for it, so there is no need for it and you're just wrong". Are you perhaps a manager?

The need arises for complex embedded programming: appliances, storage networking boxes, some normal networking boxes (though much of that work actually uses functional languages), and so on. When you're coding for multi-year uptimes and need to be utterly, absolutely sure beyond any doubt that not only do you have no resource leaks, but that you have no "dangling pointers". Slab allocation makes dangling pointers the chief cause of corruption, and a much bigger security problem than in normal code, because a pointer to a object that has been freed will almost certainly become a pointer to a valid object of the same type soon enough.

Marking the object as "freed" does you no good, because that object will be re-used by the next alloc and marked "good" again.

Java is unsuitable for this sort of coding, unless perhaps you hack around to make slab allocation work in some way (which would bring these problems along), because it's quite important that the space reserved for each specific type of object be known and fixed in advanced.

Re:javas not dead!

[RCL]

Thanks for the link, it's an interesting read. Still, I don't see any reason to use Java for performance work given that there are closer to metal languages available. It's like imposing an artificial limitation on myself, and then fighting hard to overcome it.

Re:javas not dead!

[RCL]

JIT is generic in a sense that each program (and even different parts of a single program) is different and you cannot base them all on a common framework. E.g. in C++ sometimes you have to abandon STL at all because you cannot allow dynamic memory allocation (and memory fragmentation it causes). I wouldn't say that "Java performs as well as C++", unless you are speaking about UI-heavy programs where bottleneck is user input - or, alternatively, C++ programs written by people who don't know how CPUs implement a virtual method call and why it's slower than a non-virtual one.

Yeah, with native languages you are bound to a specific architecture (and even variations of it, e.g. AVX, SSE), but is it better to be a jack of all trades and master of none? And also, there's no "explosion of binaries" anymore - unfortunately, the number of architectures available is continuously shrinking (kind of undermining that design goal of Java). "Boring" native software that is not performance-tuned may very well ship just a generic binary targeted at, say, all Pentium IV and higher CPUs.

Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance. That is also the reason why Java can be used server-side without much problems, too. However, once you bring it to desktop, where performance matters, it starts to suck immediately. That's not a problem of Java, though, but all managed languages - .NET also sucks. Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)

Sure, when I'm forced to use Java (e.g. Android), I immediately use the JNI window to escape. I am not interested in "benefits" of Java, if it means that I need to waste even more time trying to profile the application. Is there any low-level Java profiler, by the way, which would tell where CPU is burning cycles in your code at? Down to the level of assembly - i.e. something like perf annotate.

Re:javas not dead!

[Xest]

"JIT is generic in a sense that each program (and even different parts of a single program) is different and you cannot base them all on a common framework."

What does this have to do anything? That describes just about every language ever or are you under the impression that the JCL doesn't exist?

"I wouldn't say that "Java performs as well as C++", unless you are speaking about UI-heavy programs where bottleneck is user input - or, alternatively, C++ programs written by people who don't know how CPUs implement a virtual method call and why it's slower than a non-virtual one."

No, I'm saying it performs as well as C++ in most cases. Virtual method handling is one example as to why, the JIT has a better view at execution time as to what can and can't be inlined, so it can inline much more than a statically compiled C++ program possibly can.

"Yeah, with native languages you are bound to a specific architecture (and even variations of it, e.g. AVX, SSE), but is it better to be a jack of all trades and master of none?"

Well that's precisely the problem you face if you don't have an explosion of optimised binaries, unless you want to accept that the JVM is going to optimise more efficiently. It's not just about compiling for different architectures, it's about the JIT automatically being able to optimise to take advantage of extensions, and other hardware that may be present too. It can optimise dependent on amount of RAM, cache sizes etc. - something that just isn't known when you compile a plain old generic C++ binary for, say, the generic x86 platform.

But there are a number of other things it can do better too - better loop vectorisation (as a result of better inlining of virtual functions) and more efficient heap allocations for example.

"Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance."

This is nonsense. It depends entirely on the application. A heavy load web server for example may not really be I/O bound in the slightest depending on the size and what it does. Bulldozer is designed for optimisation of performance per watt, you're again confusing cause and effect as to why some things are the way they are.

"That's not a problem of Java, though, but all managed languages - .NET also sucks."

Really, the problem is simply that you don't understand managed languages. Your understanding of the optimisations performed by JIT compilers is clearly woefully inadequate to being making this sort of comment. Your comments on server applications just don't even make sense for the most part to the point I'm not even sure you have the slightest grasp of what sort of things servers commonly serve.

"Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)"

This is just further nonsense. There was a Microsoft research project to try and build such a thing, and they did, and open sourced it. I don't know what you mean by "Now they are going native :)", they've always been native with their operating systems. If you were expecting their managed OS to cause them to throw out 3 decades of legacy code then you have a disturbing view of how software is developed.

It was a research project and nothing more, and even then it wasn't purely managed, they still had to bootstrap natively because no one ever pretended that managed languages are designed to do such low level operations. You can find out more about it here:

http://research.microsoft.com/en-us/projects/singularity/

It's worth noting though that some of the things learnt from this research project have already made their way into Windows, but that's kind of the point of r

Re:javas not dead!

[RCL]

No, I'm saying it performs as well as C++ in most cases. Virtual method handling is one example as to why, the JIT has a better view at execution time as to what can and can't be inlined, so it can inline much more than a statically compiled C++ program possibly can.

You realize that JIT is inherently limited to a tiny bit of program which it compiles? JVM cannot spend neither time nor RAM building a whole program tree and making global optimizations like compilers can. And by the way, if you think that compilers are limited to static analysis only - there's also profile-guided optimization.

Well that's precisely the problem you face if you don't have an explosion of optimised binaries, unless you want to accept that the JVM is going to optimise more efficiently. It's not just about compiling for different architectures, it's about the JIT automatically being able to optimise to take advantage of extensions, and other hardware that may be present too. It can optimise dependent on amount of RAM, cache sizes etc. - something that just isn't known when you compile a plain old generic C++ binary for, say, the generic x86 platform.

But there are a number of other things it can do better too - better loop vectorisation (as a result of better inlining of virtual functions) and more efficient heap allocations for example.

In theory, it could do that. But if you do a reality check, you'll find out that JVMs right now are pretty mediocre compilers that lack even basic optimizations. Again, everything that JVM does, can be done by a compiler, but not vice versa. Compilers have nearly unlimited time and can spend gobs of RAM analyzing the program. They can use profile-guided optimization, allowing you to gather stats from a compiled program and then recompile it to better account for runtime behavior - if needed.

Oh, and while we're at it, fine-tuning assembly with specific CPU in mind does not matter these days except for SIMD ops. Waiting for memory accesses dominates CPU time - and here Java is at inherent disadvantage because you cannot really control memory layout of your data.

"Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance."

This is nonsense. It depends entirely on the application. A heavy load web server for example may not really be I/O bound in the slightest depending on the size and what it does. Bulldozer is designed for optimisation of performance per watt, you're again confusing cause and effect as to why some things are the way they are.

Before you call this nonsense, go read some analysis and check benchmarks.

"That's not a problem of Java, though, but all managed languages - .NET also sucks."

Really, the problem is simply that you don't understand managed languages. Your understanding of the optimisations performed by JIT compilers is clearly woefully inadequate to being making this sort of comment. Your comments on server applications just don't even make sense for the most part to the point I'm not even sure you have the slightest grasp of what sort of things servers commonly serve.

"Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)"

This is just further nonsense. There was a Microsoft research project to try and build such a thing, and they did, and open sourced it. I don't know what you mean by "Now they are going native :)", they've always been native with

Re:javas not dead!

[ahabswhale]

Your notions about JIT compilers and Java performance is really outdated. Java is extremely fast and the JIT is actually an advantage over traditional compiler optimization in that it evaluates what the program is actually doing as it's running to perform performance tuning. A traditional compiler has no insight whatsoever to what code gets hit hard and what doesn't. I've been writing Java a very long time and I have yet to run into a situation where a performance problem was due to poor performing Java. In fact, with the exception of very specialized situations that applies to less than 1% of all coding, I don't think there's a situation where Java's performance would ever hold you back.

The story, as visualized in Python

[idontgno]

The Dead Collector: Bring out yer dead.
[a company puts COBOL on the cart]
Oracle Corporation with Dead Body: Here's one.
The Dead Collector: That'll be ninepence.
Java: I'm not dead.
The Dead Collector: What?
Oracle: Nothing. There's your ninepence.
Java: I'm not dead.
The Dead Collector: 'Ere, he says he's not dead.
Oracle: Yes he is.
Java: I'm not.
The Dead Collector: He isn't.
Oracle: Well, he will be soon, he's very ill.
Java: I'm getting better.
Oracle: No you're not, you'll be stone dead in a moment.
The Dead Collector: Well, I can't take him like that. It's against regulations.
Java: I don't want to go on the cart.
Oracle: Oh, don't be such a baby.
The Dead Collector: I can't take him.
Java: I feel fine.
Oracle: Oh, do me a favor.
The Dead Collector: I can't.
Oracle: Well, can you hang around for a couple of minutes? He won't be long.
The Dead Collector: I promised I'd be at Microsoft. They've lost nine today.
Oracle: Well, when's your next round?
The Dead Collector: Thursday.
Java: I think I'll go for a walk.
Oracle: You're not fooling anyone, you know. Isn't there anything you could do?
Java: I feel happy. I feel happy.
[The Dead Collector glances up and down the street furtively, then silences the Body with his a whack of his club]
Oracle: Ah, thank you very much.
The Dead Collector: Not at all. See you on Thursday.
Oracle: Right.

Re:A Man Can Dream

[i kan reed]

Yes, we can all dream of a day when Oracle is just ashes on the ground, and a footnote in corporate history.

Java won't die.

[sirsky]

The reason Java is still alive and well is not because it's a good language. It's not because Oracle does a good job patching security faults with it. It's not because it may be able to run most of it's code on any given OS that can run its VM.

The reason Java is still alive and well is because it is the OO language most schools, universities and colleges teach in their CS classes.

Re:Java won't die.

[Anonymous Coward]

Uh huh. Maybe you're not old enough to remember PASCAL? Which was the overwhelming favorite of colleges and schools back in the late 80s and early 90s?

Re:Java won't die.

[ausekilis]

The reason Java is still alive and well is because it is the OO language most schools, universities and colleges teach in their CS classes.

Which is both a blessing and a curse. I went through my programming undergrad classes in the last round they offered C and C++. It worked out well because my employer needed those languages and for me to be able to learn others quickly, such as Java and C#. My experience with classes in C++ and lower level bit-bashing in C gave me the knowledge in being able to create custom libraries and handle oddly defined standard binary blobs, such as DTED data.

This same employer stopped looking at my school afterwards simply because Java was the dominant language. The graduates being churned out had knowledge of data structures and libraries, but knew very little of the ins and outs of binary data streams, binary blobs, memory management, and all those other things that you need in C and C++ that Java gives you for free.

Yes, it's good to have an approachable basis for such a complicated field as programming (computer science/software engineering/development/etc..). However, going from C/C++ to Java is a lot easier than the other way around. There's a reason my professor called Java a "Training Wheels Language"

Re:Java won't die.

[Anonymous Coward]

The reason Java is still alive and well is not because it's a good language. It's not because Oracle does a good job patching security faults with it. It's not because it may be able to run most of it's code on any given OS that can run its VM.

The reason Java is still alive and well is because it is the OO language most schools, universities and colleges teach in their CS classes.

And the reason most schools, universities and colleges teach Java, keeping it alive and well, is because it's a good language...

Re:Java won't die.

[pak9rabid]

Horse shit...Java is nothing but pointers (aka "references"). It just hides dereferencing and memory management for you.

Re:Java won't die.

[91degrees]

Java pointers can be null.

Re:Java won't die.

[ebno-10db]

Leaving aside its pros and cons, the biggest reason that Java initially caught on was Sun's marketing department.

Re:Java won't die.

[slim]

Pointer arithmetic is missing (good).

Re:Java won't die.

[angel'o'sphere]

Isn't that a chicken egg problem?

I always thaught Java was taught in universties because it was so widely used in the industries ...

What other language/platform is out there that could rival Java? AFAIK none!

Re:Java won't die.

[gtall]

Oracle has too many of its tools built around Java in the browser to let it go. Redoing them would be expensive, their customers would scream bloody murder if Oracle attempted to shake them down for development using...what...Javascript?

Re:Java won't die.

[hondo77]

There's a reason my professor called Java a "Training Wheels Language"

This.

Re:Java won't die.

[gtall]

Nah, it caught on because you could do simple stuff simply without whacking away in C or C++ and that it was cross platform at a time when attempting to do cross platform development usually meant you had to shell out for proprietary pile of stuff which locked you in. Java was good for backends as well where you had a lot of horse power to apply to its programs. Java was also good for universities to use in teaching programming, not that it made for good teaching.

Sun had a marketing dept? What were they marketing?

Re:Java won't die.

[Phillip2]

This is demand lead. Students want Java. Many of them think it's good, or that it's a "real" language or something. Even though, it's not actually very good for teaching, it's what people want.

Re:Java won't die.

[benhattman]

Bzzzzt, wrong!

Java is still alive and kicking because it's an enterprisy kind of language in a world where all the hip new languages simply aren't that. As much as someone might love them a ruby or python, those languages are not controlled by the kinds of entities who are hesitant to break 12 year old software with new releases, nor are they backed by the kinds of major players who could force a language through the entire industry.

If you just look at languages that either have enthusiastic big money backers or importance due to legacy, you are generally limited to C/C++, C#, and Java. Companies like IBM, Microsoft, Sony, Google, Oracle, Facebook, or even Amazon don't put an effort behind a language like ruby, which is at least one reason it's more niche. And if you look at what's out there, most of those companies are wedded for one reason or another to one of the languages already in broad use.

Now, if Google ever made a serious effort to push go, perhaps it would gain traction in a serious enterprise kind of way. Likewise, if Facebook were to ever decide to push a language, they might have the clout.

And so, we have C/C++, C#, or Java. Neither Java nor C# fill the niches that C/C++ do, so those aren't even direct competitors. So if you want to use a language designed for large software systems with a lifecycle potentially in the range of decades, and you want garbage collectors, you're probably going to choose between which devil you prefer (Oracle or Microsoft).

Re:Java won't die.

[geminidomino]

I used Pascal back in my Senior year of HS, but I don't remember anything object oriented about it. Shit, it was dead and buried before the turn of the century. What does it have to do with Java today?

Luckily, FSU only made me take 1 Java course (just enough for me to be able to dick around making mods for Minecraft), but used C++ for the "applied theory" courses.

Re:Java won't die.

[buddyglass]

Ditto. You'll know Java's in trouble when the College Board replaces it as the language used in the AP Computer Science Exam. When that happens, it will be because they've identified some other language that has two qualities: 1) considered appropriate in a teaching context, and 2) is actually used in industry or is thought to be on a path to quick adoption. The only possible replacement I see on the horizon is Python.

Re:Java won't die.

[wagnerrp]

Java is used because of rank misconceptions. The only value to Java is that the virtual machine is tied to the platform, rather than cooked into the binary, so you can in theory, run Java applications anywhere with a suitable version of the VM. PHBs making decisions get caught up in this concept, and fail to see the bigger picture.

When you're talking about software for embedded platforms, like the Bluray menu system, this makes some amount of sense. It allows you to write the software once, and then run it on any manufacturer's player, regardless of the underlying hardware. On the other hand, when you're talking about software for embedded platforms with limited resources, there's all that much more reason to custom tune the application for the hardware.

When you're talking about software for the server, it makes little sense. At a high level, you want to be able to re-architect your systems to run on whatever hardware or operating system you want, without rewriting your software. At a low level, you're going to invest so much in the management framework surrounding your hardware or operation system of choice, that you're never going to want to switch, but you still insisted on using Java. On top of that, even if you used C[++] for your application, the vast majority, if not all, of the code can simply be recompiled for whatever new platform you want to run on.

When you're talking about software for the desktop, it makes zero sense. Compiled applications are neat and tidy. They're self-contained. Java requires the user install some 3rd party runtime environment in which to run Java applications. That's a hassle, and a good portion of your user base is simply going to refuse, and use a competitor's software. This wouldn't be an issue if a Java VM can pre-installed, but it doesn't. At least with .NET on Windows, it's bundled in with first party updates, and disguised a bit.

Re:Java won't die.

[Wootery]

What other language/platform is out there that could rival Java? AFAIK none!

Depending on what you're after, C# (yes, with Mono, it's actually pretty good) or D might work for you.

Re:Java won't die.

[VGPowerlord]

What other language/platform is out there that could rival Java? AFAIK none!

For good or bad... Java's younger cousin C# / .NET.

Re:Java won't die.

[HeckRuler]

DAT'S DA JOKE

Or

Whoosh!

Or

Yeah.... That's, you know, the joke. The fact that it hides it for you means that they simply don't teach that aspect of programming anymore.

Or

That's the sad state of affairs in college level computer science education. Yes, damn near everything in Java is a pointer and you can make it jump in circles if you really want. But while that's true, it doesn't keep professors from deciding that they can just skip over teaching the students anything about pointers. Because it's Java. I went through ISU's computer engineering program. This was before they had a software engineering degree, and they were co-opting the ComSci departments classes for teaching kids how to code.

Well I got the lovely experience of them switching from C++ to Java mid-way through. That was lovely. And this is a quoate from the ComSci professor who taught the intro to Java class: "Java has no pointers".

The engineering department stopped sending students to comSci courses shortly after I graduated and made their own software engineering degree.

Re:Java won't die.

[bsdasym]

Nowhere? Pascal, Turbo Pascal, Delphi (Object Pascal)? Nowhere? I did professional Delphi development for roughly 10 years for companies of every size. Their IDEs were, and still are, a step beyond anything else, and when you had to get applications out the door quickly, it was Delphi or VB. The most visible brand, Borland, screwed up a lot of things. Embarcadero has been doing an admirable job bringing the product up to date and, slowly, back into the public eye. It's still very much alive. The current version can do cross-platform development for just about any mobile device (Win, iOS, Android), producing native code. Delphi (and Java, for that matter) are about as dead as the BSDs, which is to say, not. It's used in basically the same sort of way; quietly, behind the scenes, making things work that you don't think about day to day.

Re:Java won't die.

[sirsky]

If you just look at languages that either have enthusiastic big money backers or importance due to legacy, you are generally limited to C/C++, C#, and Java. Companies like IBM, Microsoft, Sony, Google, Oracle, Facebook, or even Amazon don't put an effort behind a language like ruby, which is at least one reason it's more niche. And if you look at what's out there, most of those companies are wedded for one reason or another to one of the languages already in broad use.

Now, if Google ever made a serious effort to push go, perhaps it would gain traction in a serious enterprise kind of way. Likewise, if Facebook were to ever decide to push a language, they might have the clout.

You may be surprised if you actually looked it up at how much Google and YouTube use Python. Here, let me do that for you: http://www.python.org/about/quotes/. Facebook is built on PHP, a language designed to solve the same types as Ruby. Other than Oracle and IBM, none of those companies make much if any use of Java as a core language for any of their products.

Re:Java won't die.

[ADRA]

So is Haskell and LISP and where is their commercial penetration? No, Java is everywhere because they have developers, and as long as those developers are effective at making things, they'll be in demand from people wanting to make things. Making things easier and cheaper is important. Having lots of people of varying skill levels is important.

Commercial assembly developers may have the absolute brightest people in the entire computing world working on development, but when there's only a few hundred and they each cost a fortune to pay for, it doesn't make much business sense to support the language unless its truly the only solution.

Re:Java won't die.

[JavaElementOfStyle]

From the people I know who have worked there and from various pieces about the technology used by Google. Their technology stack looks something like this:

C/C++ for all the OS/Server development.
Java for all the messaging and web services.
Python for the scripting glue.

What gets used for front end development is all dependent on the team working on it. Gmail and the various Google apps are created using GWT. Which is Java that gets compiled down to a Javascript front end and Java back end.

Also, Google hired the guy who created Python so he would shape it in the direction that they wanted it.

Facebook replaced PHP right away. They're all C/C++ now. They function a lot like Google and Amazon do. They create a lot of their own infrastructure using home grown solutions.

Re:Java won't die.

[Gibgezr]

No, they started teaching Java before it became really big. It became really big because every student who graduated from uni had a Java hammer, so every problem looked like a nail to them. It was back when everyone was having orgasms over "write once, run everywhere" and it looked like Java was going to be the answer for making things happen on the web.

Intro programming languages were always "fad of the year" in CS departments. It used to be that students learned some random language, Fortran/Modula-2/Forth/Pascal/Basic/Whatever in year 1, then went on to learn C (and later, C++) in years 2-4 and beyond. Unfortunately, when Java's turn came up in the random year one language slot it invaded years 2-4 as well because it was OO and super-trendy, and way easier to teach. The side effect is still being felt; university CS grads come out of many schools lacking the skill to deal with real-time systems/binary data/memory management etc.

Re:Java won't die.

[maccodemonkey]

The reason Java is still alive and well is because it is the OO language most schools, universities and colleges teach in their CS classes.

I transferred and finished my degree at a different school than I started at. I knew they were a good school when they refused to transfer any credits for any class that was taught in Java.

Re:Java won't die.

[ebno-10db]

Were you around in '95 when Java was first introduced? Seriously.

As for the marketing department, Silicon Valley style isn't so much about ads and whatnot, as creating hype and buzz (with the emphasis on hype). Sun did that in spades.

Re:Java won't die.

[ebno-10db]

I'm sorry to hear that the acquisition caused you to lose your job in the Sun marketing department. Based on the fantastic job you guys did though, you ought to able to find something else.

Re:Java won't die.

[angel'o'sphere]

No, they started teaching Java before it became really big.
Sorry, your perception is just nonsense.
The rest of your post is nonsense, too. I spend nearly 17 years at the university. Java started to be the main language for teaching 7 to 10 years after it was broadly getting attention in the industries.
Universities never have driven language usage in the industry, otherwise we all would program in Lisp, Prolog, Haskel or Sather/Sather K.

Re:Java won't die.

[angel'o'sphere]

C#/.NET does not run on iPhone/iPad/Android/HP Unix, Mac OS X, Oracle Solaris, IBM AIX, Mainframes, Midrange Computers (AS 400 etc.) ... should I continue?

Neither has C# in any area the open source frameworks or tools Java has, nor a useable IDE.

So no: there is no alternative to Java unless you want to write closed source desktop applications for Windows.

Re:Java won't die.

[angel'o'sphere]

So you like to suggest that I suggest to the amazon CTO that we do the next system upgrades in D ?

Because? There are so many D programmers? And we already have a D compiler for the AS400 and the IBM Mainframes? And it gives us over Java ... what exactly? A servlet framework? JPA ersatz which is "better" somehow?

D is a language, not a platform.

Re:Java won't die.

[farble1670]

translations: everyone is dumb, but me. i see through the fog where no one else can.

it's used by professors because they like it. it continues to be used by students because they like it. it's used in industry because the people that work therein like it. it was chosen for android app dev because the powers that be at google liked it. i can assure you, most of those people are not fools. in fact, most of the people that made those decisions are above average.

Re:Java won't die.

[Wootery]

So you like to suggest that I suggest to the amazon CTO that we do the next system upgrades in D ?

"Nobody ever got fired for choosing Java", right? Fair point, but you asked What other language/platform is out there that could rival Java, and I submit that the C#/CLI language/platform pair, and the D language, could. They're by no means a million miles away from Java; if we look at the broader spectrum of programming languages, the three are pretty close.

There are so many D programmers?

Again, fair point: D ranks at 37 on TIOBE, where Java is in second place to C. It depends what you mean by could rival Java, really; if you are asking for a language with considerable pre-existing adoption, that's of course quite different from the technical side, which is what I was looking at.

And we already have a D compiler for the AS400 and the IBM Mainframes?

For funky platforms, Java will beat D, of course. For the major server/desktop platforms (Lin/Win/Mac), D should work (though it generally focuses on Windows), but yes, Java certainly wins on implementation maturity.

And it gives us over Java ... what exactly? A servlet framework?

It gives you a language which rivals Java. Basing my decision purely on language preference, I'd choose D over Java.

D is a language, not a platform.

It's a little fuzzy what this means - D doesn't have a security model like Java does, sure, but as I understand it, CLI doesn't have one either. Compilation is fully ahead-of-time, also. This doesn't rule out D from doing some of the things Java is used for, though.

Re:Java won't die.

[Gibgezr]

Java became the intro programming language in unis around here in the late 90's. That's JDK 1.2-1.2 era, so you are saying it was big in industry before then? Hell, the language was invented in 1995...even looking at the unis that didn't adopt it until 2004 it couldn't have been "big in industry" for 7-10 years like you claim, it was only 9 years old (and the first couple of years it didn't even have a reliable implementation).

Java is a very young language; so young that it didn't have time for industry to "make it big" before unis started pushing down student's throats.

Re:Java won't die.

[angel'o'sphere]

Perhaps the universitied in your country are different than others :)
Certainly Java was not pushed by unis. They teach it / taught it because it had an easy free to use tool chain runnin gon all majour platforms. AFAICT it was already widely used in the industry when it was used in universities.
I did my first commercial Java projects around 1995/1997.

Re:Java won't die.

[angel'o'sphere]

You definitely know a lot about D.
With rivaling I ment "usable for enterprise computing" (at least) and D and also C# simply lacks libraries and frameworks. The main reason C# basically is useless is: MS never tried to make it a cross platform alternative to Java. It only runs on windows. The maturity of Mono does not compensate for this.

Hm, should check how D is in the area of multi threading. But bottom line I don't like many of the design decisions in D, like having no true MI (ofc I don't like that in Java either).

Nevertheless you made a very good post and obviously know your stuff :)

(with language versus platform I mean the broad spectrum of libraries that are focused on special purposes in Java, like JPA or the Java Rest and Soap support via annotations etc. the huge amount of third party frameworks like spring or Aspect/J or hibernate)

Re:Java won't die.

[Wootery]

You definitely know a lot about D.

You're too generous - I've just read a bit about it and played about with it a little; I'm certainly no D master :P

Regarding frameworks/libraries/maturity/practical power, I think you might underestimate what Mono is capable of - I'm no expert, but I don't think you'll have any trouble doing web-dev work with it.

For D, I believe there are libraries out there for doing web-dev work. This one might do, but looks a bit on the low-level side. For serious production code I'd certainly recommend C# over D (ASP.NET is already out there in the 'real world'), but I'm sure it could be done with D.

Hm, should check how D is in the area of multi threading.

I don't know much about this, but I do know that D2 has some thread-safety features built into the language itself: 'global' variables are now by default actually merely 'thread-global'. You have to use a special keyword if you want real process-wide globals. I can see where they're coming from, but I'm not sure I like it.

But bottom line I don't like many of the design decisions in D

There are certainly seem to be some warts - I get the impression the const system is a bit broken.

like having no true MI

I've never been bitten by not having MI, but maybe that's because I learnt Java before I learnt C++. The arguments for not having MI are fairly persuasive imo: simpler for the compiler, generally less error-prone for the user, and MI is rarely the right solution anyway.

I never quite got my head around Scala's solution (it looked a lot like MI to me), but people seem to like it.

(with language versus platform I mean the broad spectrum of libraries that are focused on special purposes in Java, like JPA or the Java Rest and Soap support via annotations etc. the huge amount of third party frameworks like spring or Aspect/J or hibernate)

Ah, the advantages of bytecode and reflection. Sounds almost like Aspect Oriented Programming is what you're really getting at here. There's not much in the way of AOP for D, from what Google tells me.

Re:Java won't die.

[angel'o'sphere]

There are many good use cases for MI, all the problems I 'read' about are purely academic, I never encauntered any of them in the real world.
There are clear patterns when to use MI, e.g. Jiri Soukop uses MI in combination with templates (you inherit several times from the same template with different template arguments) or the Talingent frameworks patterns. If you want to extend a class with "completely new/unrelated" behaviour (D extends B, all new functionality programmed in D), it is better to simply write a new class (class E) with only that behaviour (probably as a mixin template class) and then use MI to combine them: D extends B, E.
That way you can easy reuse E in other scenarios, again via MI ofc.
Inheritance hierarchies should be somewhat shallow anyway, so in a good structured system MI is no real disadvantge/problem.

Re:Java won't die.

[Evil Pete]

I was involved in a large ecommerce site. $30 million. All in java, when it was finished we had started using the latest Java 1.1.5. By the time Java 1.2 came out java was very, very popular ... there was a lot of hype about it, but not much in the universities. That changed rapidly but the popularity of Java came first. Everyone knew that at the time. Now think about this image. This is post-hype, it was already waning by the time of the new millennium, but still dominant. That is before the popularity in the universities and colleges.

Re:Java won't die.

[anyGould]

You got PASCAL? You're so lucky. My U was stuck on TURING

I'll see your TURING and raise you a Modula-2. A language that I've never heard of in any context beyond those two intro classes.

Re:Java won't die.

[doccus]

You got PASCAL? You're so lucky. My U was stuck on TURING, because one of our profs who should have retired years previous only knew that, Simscript, and BASIC, and they had to have a course for him to teach because he had tenure. As soon as he was gone, they moved up to C.

Hahaha LOL!

Re:Java won't die.

[doccus]

If I hadn't had to learn binary in the 70's, I probably wouldn't have been so turned off computers that I never got back into them till the late 90's

Re:Wake me up...

[stewsters]

The great part about Java is that there are so many libraries for it.

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/primitives/UnsignedInteger.html

Scripting / PowerShell

[Thyamine]

I'm surprised no mention of PowerShell was listed. It's obviously platform specific, but Microsoft has done a nice job of including it in all their major platforms and products in recent years. I've used it on site for several customers, and I've had customers who are more technical asking about help with it. I'd be interested to see what sort of growth it's seen, and how it is supplanting (one can hope) old vbscript files that still linger.

Re:Scripting / PowerShell

[Bill, Shooter of Bul]

For what its worth, the only Vbscript I've seen has been replaced with Python. Obviously the authors of the original code were just too lazy to actually do a full VB Gui app. I'm sure there are a lot of use cases where python couldn't replace vbscript as nearly as well as powershell. I've also converted a few to bash for cygwin. I don't like using platform specific code.

Re:Scripting / PowerShell

[Sarten-X]

The point was to list decent halfway-decent scripting languages.

Powershell is a batch file on steroids. It is good for automating system administration in a known environment, but not much else. While many Microsoft products do offer modules, there's still a lot of (especially older) ones that don't. Also, since much of the existing API is a direct port from Windows' internal structure, many of the designs are non-intuitive, like having IP addresses almost completely separate from NICs.

My biggest complain about PowerShell is what I now unaffectionately call "PHP syndrome": Extensible through modules, but there are no namespaces. As the system grows, the list of core commands grows as well, and there is no clear grouping available outside the documentation.

Yes, it is a nice enough replacement for the dozens of little VBScript files kicking around, because it offers easy access to WMI and .NET. Unfortunately, it also brings over a new "On Error Resume Next", in the form of silently continuing after each error.

Re:Scripting / PowerShell

[Sarten-X]

The point was to list decent halfway-decent scripting languages.

For what it's worth, I meant that sarcastically. All languages suck. PowerShell, I've found, just sucks more than most.

Re:Scripting / PowerShell

[ErichTheRed]

You may get your wish soon -- I remember when VBS was just starting to become available in Windows, and I also remember one of the things holding back its adoption was the fact that you couldn't guarantee that there was a complete "VBS stack" on the system. WMI was an addon, MDAC was an addon, even the XML parser wasn't guaranteed to be the same version until IE 6 came out. Even the scripting engine itself was an add-on! Therefore, you had to write lowest common denominator scripts until you got all the old stuff up to date. We were still using batch files for quite a while, and knew we could do things faster and easier, but we were stuck in a mixed NT/XP environment. (Yes, this was a while back.)

I have the same issue with PowerShell and a mixed Windows 7 and XP environment. In a big enterprise you can't absolutely guarantee that a compatible PowerShell interpreter plus the right version of .NET is available. Microsoft has done an OK job of making sure most of the functionality is backported, so we're starting to move away from VBS.

Honestly, my complaint about PowerShell is its complexity. You get access to vast resources through the .NET Framework, and that's great. But just like any other modern language with a monster prebuilt library, just finding what you need to write and what has been written for you is still a Google operation. One huge improvement is the ability to dispense with thousands of "results parsing" functions. VBS meant you had to do a lot of output reading/interpreting in code, plus access to things like WMI and data services is still kind of a magic incantation thing. Now PowerShell lets you directly work on objects. Example: I wrote a script to edit an XML configuration file for one of our apps the other day, just to make a simple change. It was a huge script in VBS with all the error checking, magic incantations to access the XML DOM and parsing of results. PowerShell lets you directly manipulate the file in memory.

Re:Scripting / PowerShell

[MightyMartian]

Yes, it's platform specific, which means, other than when I need to do some scripting, I could give a fuck about PowerScript. That's like complaining that no one is talking about bash.

Re:Scripting / PowerShell

[MightyMartian]

I use it where I need full exposure from APIs in Windows. What I do find is that it is gawdawful slow when compared to the old CMD.EXE batch scripts I used, even when those scripts had to use third-party tools to do clever things like determine a user's group membership. It has its place, but I find it an awful language. I'd still prefer a native bash-like shell and scripting language that exposed win64.

Re:Scripting / PowerShell

[Bill, Shooter of Bul]

At least the upchucker took the time to arrange his vomit such that the indenting was consistent.

Re:Android is not always Java

[bluefoxlucid]

It would have been better if Android supported Python instead of Java.

Re:Wake me up...

[Anonymous Coward]

Wake me up when java supports unsigned integers. Until then it's not a real language.

Python, Perl, and Ruby are examples of other languages that don't support unsigned integers. These languages are independent of the underlying hardware and automatically upsize the integer to handle larger value. You can always use the AND operator to convert to an unsigned integer for C calls. (e.g. var & 0x0FFFFFFFF).

You're not a real programmer if you can't adapt to the lack of unsigned variables.

Android, Objective-C and Tiobe Index

[bradgoodman]

I think much of Java's *lack* of decline is attributable solely to it's "native support" (use) in the Android platform - just as the sudden rise of Objective-C (See Tiobe index) is obviously attributable to the iPhone and iPad devices.

Outside of Android - I believe use and acceptance is waning heavily. As a client-side web tool (where it got most of it's early predominance) it has been cockblocked by iOS, and is becoming overshadowed by native HTML5 (JavaScript) stuff. As a server-side tool it has been getting taken over by Ruby/Rails, Python and the stuff mentioned in the OP.

Re:Android, Objective-C and Tiobe Index

[binarylarry]

I don't think Java and Rails, Python, etc actually compete much. They're very different technologies.

Rails and Python are great when you don't have significant technical skills and just need to slap some shit together and throw in on a web server.

Java is better in areas where you need high performance and scalability, but it's also much more costly to do anything with it.

Re:Android, Objective-C and Tiobe Index

[slim]

The smart thing to do is use Jython, JRuby, Groovy.

Then you can write in Java when the problem demands it, and in something more expressive when you're gluing it together. And you have access to all the thousands of libraries Java has.

I saw a JRuby presentation in which they said they expected JRuby to outperform native Ruby -- because the Ruby runtime is written by a few guys, whereas the JVM has half a campus full of incredibly clever people, just working on making it run Java Bytecode as fast as possible.

Re:Android, Objective-C and Tiobe Index

[bradgoodman]

But people still DO use it. It may not have been a "good" solution, but it was *a* solution. Today however, (just like with Flex), it is *not* a solution, because it would yield a web site which doesn't work with a lot of popular devices. That wasn't the case before iOS.

Re:Android, Objective-C and Tiobe Index

[bill_mcgonigle]

Rails and Python are great when you don't have significant technical skills and just need to slap some shit together and throw in on a web server.

I've seen this from the other side. Java is a *great* language for the middle of the normal distribution. I'm not going to name the languages on the left side of the curve, because the point of this isn't to start a flame war, but if you have a large number of averagely competent programmers, then Java lets you (as architect/manager/etc.) have those programmers be productive for you, produce code that can be read in the future by the same segment of the population, and be reasonably sure the language will prevent them from making hidden catastrophic mistakes. Also there are a large number of existing tools that let you scale their work out both in depth and in breadth.

The alpha geeks employing Ruby, Python, modern Perl, erlang, etc. are usually at the right side of the curve, doing very efficient, agile, but abstract and terse stuff that takes exceptional (not heroic, just unusual) sysadmin skills to get to work on a grand scale.

Due to the nature of the available talent pool, it's natural to see projects start with the advanced scripting languages among the startup crowd and then migrate to the Java environment over time. Twitter would be a good example of this.

Re:Android, Objective-C and Tiobe Index

[binarylarry]

Twitter didn't switch to Java to take advantage of the mediocre "kind of a programmer" Java talent pool.

They switched because their "alpha geeks" couldn't make Ruby/Rails perform adequately for the amount of traffic they get.

Re:Android, Objective-C and Tiobe Index

[tippen]

Java is better in areas where you need high performance and scalability

Now I need a new keyboard! Just spit out my Diet Dr. Pepper when I read that... What's your definition of "high performance"???

Re:Android, Objective-C and Tiobe Index

[Anonymous Coward]

Very true, but most of the replaced code at Twitter was rewritten in Scala not Java.

Re:Android, Objective-C and Tiobe Index

[gbjbaanb]

Why didn't they switch to C++ and do it properly!

Re:Android, Objective-C and Tiobe Index

[binarylarry]

Because they needed it to be fast AND secure AND fairly bug free.

Re:Android, Objective-C and Tiobe Index

[angel'o'sphere]

Because it would be a dozen times more efford in programming hours, because it lacks the relevant libraries, because the amount of capable C++ programmers is very low, because C++ is a dying language in the enterprise environment, because C++ is not truely portable across platforms, because in the end when it comes down to performance the C++ implementation (which costed you 5 times the money and 2 times the time to develop) will be only 5% faster than the Java implememtation.
And all arguments above will kill you when you plan to maintain it for the next 15 years.

Re:Android, Objective-C and Tiobe Index

[binarylarry]

Both Scala and Java compile down to java bytecode, so after compilation is done they will have similar characteristics and capabilities.

Re:Android, Objective-C and Tiobe Index

[R3d Jack]

Exactly. Java works best for heavy-duty business systems, and there is a steep learning curve. But there are a LOT of heavy-duty business systems. Java won't go anywhere until a new development paradigm comes along (which I haven't seen any signs of yet.)

Re:Android, Objective-C and Tiobe Index

[bill_mcgonigle]

But efficiency.. measured in what, lines of code, THAT kind of "efficiency"? =)

Sort of - time to prototype is pretty high up there for startups. LOC can be a weak approximation to that, but available library size is also really high.

Ruby is slow, Python is memory hungry. Perl doesn't suffer from those two problems but has fairly poor concurrency without an external dispatcher and a funky object syntax. It's all in the trade-offs for what you need.

Re:Android, Objective-C and Tiobe Index

[lgw]

Well, the underlying point was valid: it's damn hard to hire great C++ programmers these days for boring "enterprise software" shit.

Re:Android, Objective-C and Tiobe Index

[binarylarry]

LOL

Re:Android, Objective-C and Tiobe Index

[ADRA]

I agree that Rails / Python are definitely the more small scale / personal project side projects type solutions out there. Yes they can scale, but I'd argue that they're not good at it.

Java SUCKS for small scale. EE containers are heavy and require a good set of knowledge to even take crack at a reasonable site, but once that painful layer has been passed, adding more and more to the service becomes as trivial as the business domain requires. The extra leveraging from well architected services and API's makes working on larger scale Java systems a dream in comparison to others (Currently working on a Java Web/Services project single deplyment EAR that's over 3 million source lines BEFORE all the libraries and server container features that we're also leveraging).

I'd also argue that outside of hosting, you can easily get Java based web service tools/servers/etc.. for 0 dollars. You can't find much Java hosting in the zero dollar number (Redhat's cloud Jboss 7 or the non-standard Google appengine being a notable exceptions) which may be an issue to some enthusiasts who don't do their own hosting.

Re:Android, Objective-C and Tiobe Index

[IamTheRealMike]

No, I've seen pretty much that dynamic happen at Google where we use a lot of C++ and Java.

There are some places Java just can't follow C++ ... the Google core web search serving system is mostly C++ because it involves decoding extremely compact data structures at insanely high speeds, to the extent that the verymost inner code has branch prediction hints in it. Java can't do that nor will it ever be extended to do so. Lots of servers at Google are written in C++ for the same reason. I don't believe it's only 5% faster, the rule of thumb I see is you lose about 2x the performance by using Java when all the costs are taken into account (like constantly re-compiling the same code over and over on the live servers, the GC costs, etc).

Despite that, lots more code is written in Java, because the cost of using C++ is so high. Sure, when the sailing is smooth there isn't a huge difference between them as long as your libraries and support infrastructure are good, but the moment someone slips up and accidentally double frees memory on an error path you've got a problem that can take an entire team a week or more to track down. I've seen it and partaken in such bug hunts. There's nothing quite like trying to find memory corruptions that only show up in the production environment once a day, when you have thousands of servers.

Basically any programmer can screw up that way. Java strikes a reasonable balance between safety and performance, which makes sense even when you are a company like Twitter or Google.

Re:Android, Objective-C and Tiobe Index

[luis_a_espinal]

Why didn't they switch to C++ and do it properly!

Because it is not as economical (in terms of software development efficiency) compared to Java (that's my perspective as a a C/C++/Java developer in the *NIX and Windows, app and embedded arenas.)

Re:Android, Objective-C and Tiobe Index

[risingfish]

I have to disagree with this. I work for a large etailer ( w/ millions of hits a day) that has been switching to Java in recent years. As with all places we have a range of programming skill levels throughout the dev teams, though most I would classify as average/intermediate. The over-all amount of code, the complexity of the code and environment, and work required by the sysops to maintain the code very quickly outpaced the old PHP stack. While our sysop teams focus on trying to keeping tomcat running, we have an old PHP forum quietly humming away in the corner taking almost minimal work to keep running while it serves 60% of our traffic. My experience with it has been pretty negative in this environment with many 'average' developers.

But, that being said, this argument is mostly subjective, as the quality and quantity of code is less dependent on the language, and more dependent on the people/organization developing and driving it. I think where java shines is it's ability to easily enforce constraints and the inherent security benefits from a compiled language. But it also costs far more to spin up a Java environment and maintain it, so it is something that most startups will not be able to do out of the gates.

Re:Android, Objective-C and Tiobe Index

[JAlexoi]

As a server-side tool it has been getting taken over by Ruby/Rails, Python and the stuff mentioned in the OP.

I hope you are kidding here, because that is far from the case. Java is still the de-facto language for most server-side applications. RoR never outgrew it's hipster background. It has been 7 years since RoR had it's hype peak... The hype waned and RoR is still a rarity.

Re:Android, Objective-C and Tiobe Index

[JAlexoi]

C/C++ are great when it comes to highly predictable data flows or very small modules. Otherwise it's extreme cost of constant profiling of the code to actually identify the changing patterns that cause slowdowns. That being said, C/C++ can be much more than 2x performance of a JVM.

Re:Android, Objective-C and Tiobe Index

[Kagato]

Charles Nutter did a presentation on JRuby when it first came out. He runs the Fibonacci sequence over and over again. The JVM does it's optimization magic on the execution and pretty soon it's exceeds the native ruby execution speed.

Re:Android, Objective-C and Tiobe Index

[gbjbaanb]

but the point was : they had already done the development-efficiency thing and needed to update it to something more runtime-efficient.

So to choose Java is doing a half-hearted job, if you rewrite your entire codebase you could have done it much better with C++ modules in their old code, and then migrate the whole lot if necessary. Doing a whole rewrite in java means they lost out on incremental development (which would have been much more development-efficient) and lost out on the most efficient runtime performance too.

Re:Android, Objective-C and Tiobe Index

[bingoUV]

As you can see the analysis here in the garbage collection, as well as a nice research paper linked,

Time cost of garbage collection is minimal if you have physical memory 4 times as much as java heap size. I guess satisfying this requirement shouldn't be much for Google. Another limitation of java, the startup cost, shouldn't be much for Google either, as I guess most "servers" keep running for a long time.

Branch prediction and all is nice, but it is difficult to swallow the 2x estimation of performance over java. Could you give some more details? Too much floating point computation?

thanks

Re:Android, Objective-C and Tiobe Index

[tibit]

I don't think "steep learning curve" means what you think it means. If it's steep, it's easy to learn. Did you really meant that heavy-duty-enterprisey Java is easy to learn?

Re:Android, Objective-C and Tiobe Index

[binarylarry]

Java is capable of far better cache optimization than C++ (because it can profile, create a new strategy and recompile *at runtime*).

Java and the JVM

[Kagato]

People don't understand the difference between Java the Language, Java the Virtual Machine (JVM) and Java the Browser Plug-in.

What do NetRexx, Groovy, and Scala have in common? They are all languages that are considered production stable running on top of the JVM. There are about a half dozen production ready languages that run on top of the JVM in fact. By running in the JVM these languages automatically pick up all sorts of performance and availability enhancements (JIT, Hotspoting, caching, etc.) the JVM offers. That's a lot of R&D the new languages don't have to invest in. It also allows new languages to be used in existing Java infrastructure with little to no change.

The reason this is all possible is because Java the language is just an abstraction that compiles to Java Op Code. Java Op Code is very stable. Since Java 1.0 all that's changed with the opcode is a couple new operations and couple deprecations. There's still around 100 codes total.

So why do people think Java is on the decline? Well the browser plug-in has been getting a bad name as of late. But that plug-in != Java. And frankly very few applications need a Java Plug-in. HTML5 and JS work just fine for the UI. It's not going to be a great loss if peopledisable it. You also get knee jerk reporting on this advising people to get all Java on their machines. Like it's somehow less secure than the VB runtime executors.

As far as jobs, I work in the java space. There's way more need than people to fill the need. I make extremely good money java programmer.

Re:Java and the JVM

[Kjella]

Java Op Code is very stable. Since Java 1.0 all that's changed with the opcode is a couple new operations and couple deprecations. There's still around 100 codes total.

This page seems to indicate it's slightly over 200 in Java 7.

Re:Java and the JVM

[Kagato]

I'm basing it on a presentation Charles Nutter (of JRuby fame) gave years ago when he walked through all the Op Codes, how they functioned, and why it's fairly "easy" to compile languages to work with the JVM compared to .Net. It's quite possible I'm a bit outdated on the number since 1.5 was still stable and 1.6 was pretty new. It's still a very small Op list.

Re:Java and the JVM

[lgw]

The JVM and the CLR are fine if you want to write more managed languages. I'm not sure what need those fill, but yeah, you can.

CLANG/LLVM gives the same ability to use a "common language core" for a new non-managed language, and I'd surely like to see some new work there. C++ written in modern style can be a joy, but that style is too hard to discover, and the language is so full of cruft. A fresh language design, taking the "coder usability" lessons that can be learned from C#, Java, and Python, but unmanaged and targeting lower-level problems: that would be awesome.

Re:Java and the JVM

[tibit]

that style is too hard to discover

I'd say simply by going for the horse's mouth, as in reading Strostrup's C++ Programming Language book, will get you there 90% of the way.

Re:Java and the JVM

[lgw]

Actually, for a brand new project with people who have never used C it might not be so bad. People who "only know Java" would find good modern C++ style far more natural than all the bad ways. The problem is people who are C experts who are using a bit of C++ here and a bit there, with coding standards that make good sense in C and are just terrible in C++ - like the Google coding standards (I hear there's significant unrest about this inside Google now, so who knows, they may pave the way to a whole new pool of engineers who know how to do C++ right, but right now it stinks).

Which Java?

[i_ate_god]

The JVM or the language?

Sudden death

[degeneratemonkey]

A lot of very large users of Java are unhappy with it, not necessarily for technical reasons, but for legal reasons since Oracle set such a negative tone in court.

The only reason Java isn't dead yet is that it would be expensive to abandon existing infrastructure so abruptly. It will be a around for quite a while still, but it won't be too long before it's relegated to the decaying margins of the software industry.

Re:Sudden death

[degeneratemonkey]

Also, the distinction between the language and the JVM is irrelevant here. Behind both lurks an army of Oracle lawyers waiting to pounce.

Re:Sudden death

[Kagato]

I consult in a lot of sectors. Banking, Insurance, New Media, Old Media, Start-ups, etc. People who want to leave Java for some new language are doing it because of a set of features. I've yet to come across anyone, let alone an institution, that wanted to leave Java because of Oracles court proceedings (I would assume against Google for Android).

There was tons of talks on OpenJDK at JavaOne. If Oracle is the next Microsoft you would think they would have put the hammer down on that. I didn't see any of that happening. In fact Microsoft's cloud support of Java is based on OpenJDK and that was a keynote item.

On the other hand, I do hear a lot of dissatisfaction from the MySQL folks. They are moving to Maria (or other DBs). That has little to do with Java.

Re:Sudden death

[buddyglass]

Is it possible to objectively measure "relegated to the decaying margins of the software industry"? How might one do that? TIOBE market share? Number of new projects choosing to use the language? Something else?

Re:Sudden death

[Lennie]

I hear all the SWIFT stuff at the banks still run on Fortran and they are afraid to do large changes.

So I don't know if banks are a good example. ;-)

I see a lot of people go with PostgreSQL for new projects instead of MySQL.

Re:Sudden death

[Kagato]

All? No. We had all sorts of ways a SWIFT message would have been generated. Java, .Net, Mainframe (FORTRAN or COBOL), iSeries (COBOL or RPG). It really depended on the application. Most large banks still use a mainframe for domestic banking and will use a highly customized version of software (i.e. IBM HOGAN). They are unlikely to change working code to something else so long as they are still on the mainframe.

On the other hand, most mainframe banking applications only talk a single currency. So all the international stuff is newer stuff. It's also pretty common to see credit unions and community banks on newer software.

Re:Sudden death

[JAlexoi]

Banks don't want to leave JVM, they don't care much about Scala or Java....

Re:Android is not always Java

[i_ate_god]

https://ep2013.europython.eu/conference/talks/developing-android-apps-completely-in-python

The beginning of the end

[GeekWithAKnife]

It's all a matter of perspective, anything alive and well can only get sick and die eventually. Death is an eventuality. So really, Java is dying.

Re:The beginning of the end

[el jocko del oeste]

Ain't we all!

Re:Wake me up...

[binarylarry]

You should tell John Carmack about your theory, I bet he'd be really interested:

https://twitter.com/ID_AA_Carmack/status/85734195644727297

Bring out your dead! Bring out your dead!

[Zecheus]

CUSTOMER: Here's one -- nine pence.

DEAD PERSON: I'm not dead!

MORTICIAN: What?

CUSTOMER: Nothing -- here's your nine pence.

DEAD PERSON: I'm not dead!

MORTICIAN: Here -- he says he's not dead!

http://www.sacred-texts.com/neu/mphg/mphg.htm#Scene 2

Re:Wake me up...

[BreakBad]

You're not a real programmer if you can't adapt to the lack of unsigned variables.

BOOM

It's only a decline of purity.

[Max Threshold]

Oracle is doing some really bizarre things with Java 1.8, and one of the major growth areas of Java is on Android, an environment suited only for insane developers. But the core language is doing fine.

Re:Android is not always Java

[BreakBad]

kivy.org

Minecraft

[Anonymous Coward]

Java will not be dead with solid evidence.

Re:Minecraft

[PeeweeJD]

I'll bet all kinds of people are learning Java, just to make mods for Minecraft.

Apple fanboys

[rodrigoandrade]

They reason that Java is dyng because their iPhones and iPads don't support it.

Re:Apple fanboys

[angel'o'sphere]

It is easy to run a Java app on an iPad or iPhone. You only need to bundle the JVM and the relevant libs with it.

Also JavaFX is comming out end of the year with iXYZ support, completely official from Oracle, so no special hacking/bundling necessary.

Re:Apple fanboys

[tyrione]

Java doesn't get beyond a research project at Sun if NeXT Engineers don't show up and bring Objective-C isms to the Oak Project and call it Java. Seriously, it must suck not having worked for Sun or NeXT [my side] to know the story.

Re: Keep it up - you might just invent assembly...

[znanue]

As if features are the only thing that makes a language a language. I'm not saying Lisp isn't nice, but which lisp? And, after you select which lisp, which library to do the thing you're trying to do? Oh wait, they often don't exist. So you hand roll your own, because it is easy in lisp, due to lisp's powerful nature. So now you can't hire people who know about the things you're doing right out of the gate because you choose a specific lisp and hand rolled a bunch of stuff. Need to integrate with xyz technology? There's probably not a lisp library for it that is standard, if it exists at all. Its also rarely mature...

In the end, some version of lisp might still be a really good choice for some project. However, it has significant disadvantages to overcome. Adding lisp like elements to a language like Java is a much nicer thing than your quip seems to appreciate because it gives you some of the advantages of using lisp while retaining all the advantages that java will provide. Maybe lisp should try to invent java by standardizing the language and writing a lot of mature libraries?

If there's such a market.. why the Ask toolbar??

[gregmac]

It definitely doesn't help that the JRE installer tries to also install the Ask toolbar. Seriously? Even Microsoft doesn't try to install Bing with the .NET installers, and that's their own property they're desperately trying to push on everyone.

How am I supposed to take a platform seriously if the fundamental piece that has to be installed by all developers AND users to use it is doing the same sneaky things that half the crappy freeware on the internet is doing?

Just how much revenue does Oracle make from Ask anyway?

Re:Android is not always Java

[Anonymous Coward]

Great idea! Let's implement everything on our phone in an incredibly slow, dynamically typed language, whose only relevant implementation has a GIL and a pathetically bad concurrency model! That will be great for performance and battery life!

Google is dropping Python for a reason.

shipping java scientific software for 15 years

[peter303]

Over datasets are in the terabytes. Calculations distribute over thousands of nodes and cores. Only in the 1990s was thre concern about efficiency. 64-bit JVMs have been a godsend. Formerly a FORTRAN-90/C++ shop.
Java allows seamless GUI front ends and web-service control.
The new features in Java-8 are very interesting.

Re:shipping java scientific software for 15 years

[ebno-10db]

Benchmarks?

I've heard the "Java can be faster than C/C++" many times, but have never seen benchmarks that back it up.

Re:shipping java scientific software for 15 years

[Medievalist]

Formerly a FORTRAN-90/C++ shop.

Some of the big banks have been putting Java on top of COBOL backends. You think I'm kidding, but I'm not.

Re:shipping java scientific software for 15 years

[peter303]

Some here.

Re:shipping java scientific software for 15 years

[benhattman]

Not just can be, it usually is faster. At least, once it's been JITed. We just ran some XML serialization/deserialization tests, and the java implementation was much faster than the C++ one...eventually. The first several hundred iterations it was slower, but after that the Just In Time compiler optimized it, and it easily won.

For long running computations, like scientific calculations for instance, Java is really good. The problem is we perceive how fast something is based on our wait time. Every time you boot a java applications it takes a long time for it to get started relative to a C++ applications. A quick command line java application might be orders of magnitude slower than a comparable C++ one. And that delay kind of permeates our intuitions about which is faster.

Re:shipping java scientific software for 15 years

[angel'o'sphere]

Then google for the benchmarks?

Re:shipping java scientific software for 15 years

[ADRA]

" Every time you boot a java applications it takes a long time for it to get started relative to a C++ applications."
And everyone conveniently forgets that glibc / libc++ are almost guaranteed to already be loaded into ram.. Oh well =) But yes, Java apps are slower to start up, but a well cached java app doesn't actually start -that- slowly, its just that it almost always starts dead cold.

Re:shipping java scientific software for 15 years

[Anonymous Coward]

C++ really sucks for performance, because people tent to use the library as you would expect it to use.

I remember a usenet post about someone who wanted to port a little bit of Python into C++ to make it faster, problem was it was slower.
He made a small subset of his application to see what the problem was. His example was a single dictionary with string keys and string values, and inserting into them.

He wrote it quite straight forward using the C++ string class and a STL map.
It was 10,000 times (really) slower than Python.

Some C++ gurus came in and started tweaking the code, so as little as possible copies of the string instances were made (a straight forward implementation, copies a string many times for just a single insertion). In the end they created pretty much the best (from performance point of view) C++ implementation possible. It was about 80 lines of very complicated code. It was complicated because of the amount of casting, const-ing, references and pointers that were needed in combination with templates, it looked liked line noise.

Now it was only 1.2 times slower than the Python version.

Re:shipping java scientific software for 15 years

[maccodemonkey]

Not just can be, it usually is faster. At least, once it's been JITed. We just ran some XML serialization/deserialization tests, and the java implementation was much faster than the C++ one...eventually. The first several hundred iterations it was slower, but after that the Just In Time compiler optimized it, and it easily won.

For long running computations, like scientific calculations for instance, Java is really good. The problem is we perceive how fast something is based on our wait time. Every time you boot a java applications it takes a long time for it to get started relative to a C++ applications. A quick command line java application might be orders of magnitude slower than a comparable C++ one. And that delay kind of permeates our intuitions about which is faster.

Lot's of possible factors here... What compiler was used for C++?

It seems like this post is taking about the advantages of JIT, not the advantages of Java. C and C++ can be done JIT as well. You've got Microsoft's managed version, and things like LLVM. In addition, there are other languages built on top of the JVM.

Re:shipping java scientific software for 15 years

[K. S. Kyosuke]

Formerly a FORTRAN-90/C++ shop.

Some of the big banks have been putting Java on top of COBOL backends. You think I'm kidding, but I'm not.

Of course. And the protocol involves 3270 screen scraping. It's called Enterprise Integration with Legacy Systems. ;-)

Re:shipping java scientific software for 15 years

[ebno-10db]

As klugey as it is, it may make perfect sense for them. Lots of old COBOL that works, even if nobody knows how anymore. Rewrites, or even refactoring, are not real popular when you transfer a gazillion dollars a day and can't take a day off. This may be the only way they'll ever be able to move away from COBOL.

Re:shipping java scientific software for 15 years

[DrFalkyn]

Not just can be, it usually is faster. At least, once it's been JITed. We just ran some XML serialization/deserialization tests, and the java implementation was much faster than the C++ one...eventually.

What about pure numerical stuff? I'm wondering how say, a Java implementation of FFT would fair against the FFTW library (coded in C).

Of course you could make a native call to the FFTW library (MATLAB does this) through Java, but thats missing the point.

Re:shipping java scientific software for 15 years

[ebno-10db]

From your link:

The Mines Java Toolkit (JTK) is a set of Java packages and native (non-Java) code libraries for science and engineering.

In other words, there is C/C++ wrapped in Java. That may be a good idea for many applications, but it's not a measure of Java's speed.

Ye olde Computer Language Benchmarks Game has pure Java vs. pure C++. There is one test where Java is slightly faster than C++ (and even that advantage disappears depending on which of the four processors they tried). Otherwise C++ is up to 3x faster, and an average, from glancing at the graphs, of about 2x faster.

I tend to trust these benchmarks because anyone is free to defend their favorite programming language by submitting a faster program. Hence you don't get the bias that's all too common in benchmarks, where someone tries to write Java in C++, or vice versa. Those benchmarks are also running pretty up-to-date versions of g++ and the Java HotSpot Server VM, so you don't have "five years ago A was X tines faster than B, but it's changed".

Re:shipping java scientific software for 15 years

[JAlexoi]

Yes... Micro benchmarks are exactly the best way to verify real performance. /s

Re:shipping java scientific software for 15 years

[JAlexoi]

JVM JIT tends to be the best

Re:shipping java scientific software for 15 years

[ebno-10db]

Ok, so where are some better benchmarks? Everybody knows benchmarks have problems, but without them all you've got is hot air.

Re:shipping java scientific software for 15 years

[Hognoxious]

It's hardly moving away from it. It's still there, like a deformed and psychotic half-relative that you lock in the cellar and feed through an interlocked hatchway and don't mention in polite company.

And in 5 years?

[pak9rabid]

... in the forums where the cool kids hang out is against Java...

Yeah..and how many of these "developers" are still going to be writing code in 5 years?

Re:And in 5 years?

[Hognoxious]

None. They'll be in management. [shudder]

Re:Android is not always Java

[Aguazul2]

It would have been better if Android supported Python instead of Java.

To develop stable applications quickly, you want MORE compile-time checking, not less. Like if Java could mark variables as nullable or not and compile-time check that (there are some extensions for that, but they don't always keep up). Java/JVM does so much right ... If people can't see that, then I suggest they attempt some reasonably large project in several languages and compare. (I have done exactly that, in C, Vala and Java; Rust will be next when I get some time.)

Java's problem isn't verbosity

[engun]

Java's problem isn't verbosity IMHO. It's the general mindset and community that has grown around the language. Instead of simplicity, they've gone into massive over-engineering, with factory factory factories and the like. A combination of pattern mania, and "enterprise" java, has resulted in turning an otherwise simple language into a veritable nightmare. Contrast this with the python community for example. Language wise, compare Java with C#. C# has done things a lot better in general. It may help that newer versions of Java will achieve some degree of feature parity with it but in the long run, I think it also has to be accompanied by a shift in the general notion of what's "normal" design in the Java world.

Re:Java's problem isn't verbosity

[Kagato]

There's certainly a lot of factory pattern stuff out there. But your comparison is a bit outdated. Now days development uses a lot of annotations, auto-wiring/dependency injection. If I need to roll out a web service that makes some DB calls it's not that big of a lift. Maybe a half a dozen classes to get the job done (including tests).

Re:Java's problem isn't verbosity

[Anonymous Coward]

Former / current Java dev here. I agree that the Sun/Oracle-blessed Java world was moving towards overly verbose and XML-config-driven everything. What I like about the Java ecosystem is that, at least for server-side Java, there's always some plan B. In the case of Enterprise/server-side Java, the IoC people came out hard and strong against the verbosity and came up with things like Spring, etc as alternatives. What I further like about Java is that the Spring model really won out and the official J2EE direction was changed to be more in line with the approaches that were in Spring and others.

This has been the history of Java, IMO. A great idea usually starts with "wild" open source, then moves to Apache, and sometimes moves into the Java mainstream. This is how logging, db persistence, and other technologies came about. Yes, Sun/Oracle was the dictator of the ecosystem, but they do seem to listen to demand now and again and go with a better idea if one exists.
I think the tendency of critics is to focus on desktop Java, of which I'm including both applications and applets. Java never really reached a critical adoption here, and all the criticisms of the desktop ecosystem (slow to start, security-challenged, difficult to *easily* make nice, performant UIs) are completely valid. But it would be a mistake to extend those criticisms to the server side and ignore the real strength of Java. It's a breeze to create REST services that do typical business logic, with lots of shortcuts using annotations instead of XML config files. I've shown this to some Python heads to favorable feedback.

In the Fortune x00 or x000, it's really a .Net vs Java world, and I much prefer the Java option.

Re:Java's problem isn't verbosity

[Dynedain]

You know what's fun? When a so-called Java expert runs a PHP project...

Nothing but him bitching about how PHP sucks, and then discovering his code has factory factory factories in a central component that everything extended from (even when obviously unnecessary). And we wondered why we were having such performance issues.

Re:Java's problem isn't verbosity

[Jahta]

Java's problem isn't verbosity IMHO. It's the general mindset and community that has grown around the language. Instead of simplicity, they've gone into massive over-engineering, with factory factory factories and the like. A combination of pattern mania, and "enterprise" java, has resulted in turning an otherwise simple language into a veritable nightmare.

That may well have been valid back in the old J2EE days. But I'm guessing you are not familiar with frameworks like Spring (and the evolutions in the core Java platform in response). These days, it's simple POJOs, with annotations and dependency injection; no muss, no fuss. If you're writing a lot of verbose Java code (or you're bogged down in pattern mania) you doing it wrong; and working too hard!

Re:Java's problem isn't verbosity

[hondo77]

Nothing but him bitching about how PHP sucks...

To be fair, it does.

Re:Java's problem isn't verbosity

[angel'o'sphere]

Java is certainly anything but overengineered.
People claiming so simply have not enough experience.
Which factory e.g. did annoy you in particular, and why?

Re:Java's problem isn't verbosity

[sydneyfong]

The Spring framework is the symptom.

I spent my idle hours contemplating who on earth would invent such a system, and who on earth would want to use one.

Re:Java's problem isn't verbosity

[Dynedain]

Especially when you try to make it operate like Java.

Re:Java's problem isn't verbosity

[TheDarkMaster]

Exact on target.

Re:Java's problem isn't verbosity

[ebno-10db]

Thanks for a good explanation. My day job is low-latency deeply embedded hard real-time (wow, that's verbose) so Java is obviously not my schtick (to anyone who asks, Android apps don't come even close to that situation). Due to the lack of adoption on the desktop, the slow startup, etc., I always wondered if so many people are writing Java, then what are they writing it for? Now I know.

Too often programmers get very egocentric and think that whatever type of code they develop, it's the be all and end all of programming. They forget about all the areas with different requirements. One size does not fit all, and never will. It's clear why Java may be very appropriate for what you do.

Re:Java's problem isn't verbosity

[hraponssi]

Yes I like the language, the JVM and the great tools+libraries it has. But the most of the most popular ones just make me want to run away when I have to use them. Eclipse is horribly unintuitive unless you used it for years and learned to trick it. IntelliJ is great but nowhere near as popular and well known. If I have to talk to someone and show something in the IDE they are always hugging their Eclipse cause "everyone else does it".. Can't blame people for not liking it if they have Eclipse forced on them.

Then there are the libraries/frameworks like Spring, Hibernate, the REST stuff, etc. I just don't get the need to hide everything in a factory of this and factory of that and put this annotation there. I try to debug it and figure out what is going wrong and it is way too complicated because it is all hidden under 50 layers of abstraction and it is near impossible to figure out what is really going on. Not to mention when I try to get something simple to run such as a remote call over HTTP/JSON and it takes me a day to browse the docs to see how to set up the weird dependency injects, annotation configurations and whatnot.

And then the idea of "I need to do a logical expression (such as &&), let me pull in that Apache library with zillion features to do it..". Small projects ends up with some 100+ libraries for the simplest things you could do in a few lines of code, resulting in even more added complexity for no real gain. Then there is the Maven to hide your build and require a pile of configuration files spread out, added to the configuration files for all the dependency injection etc. making it impossible to navigate the code and understand it.

In some cases the factory pattern is difficult to avoid since it has not been possible to define a lambda/closures thing but hopefully the next version fixes that. Now I just wait for what kind of a mess people will make with the stream API. Some of the reputation for Java being overly verbose it true and it is fashionable for geeks to bash Java for it, but the whole stream API just seem like the perfect opportunity to write weird to understand code. Hopefully I am just too old, resistant to change, and will learn to read/like it..

Re:Java's problem isn't verbosity

[felix rayman]

Haha POJOs.

I love that typical developers using Java, an object-oriented language, got so far down the over-engineering path that they had to make an acronym for those obscure corner cases where you might want to just use....an object.

Although it's true that the Java development community does seem to be header in a much nicer direction lately.

Re:Java's problem isn't verbosity

[engun]

No, I agree that the Java language itself is not over-engineered. I said that the frameworks and community that have grown around it, have a tendency to over-engineer (especially in the enterprise). That is not to say there are no efforts within the community to overcome that, but having shifted from enterprise Java to C/Python and also having worked a fair bit with C#, I do have some experience with the general ethos in each of the communities.

RE: "Which factory e.g. did annoy you in particular, and why?" Joel explains it better: http://discuss.joelonsoftware.com/?joel.3.219431.12

Re:Java's problem isn't verbosity

[stewsters]

The problem is that there are some old functions in that language that should never have been added, and many of the developers of php apps don't know enough to avoid them. PHP can be a decent language if you have self control.

http://php.net/manual/en/control-structures.goto.php
http://php.net/manual/en/function.extract.php
http://php.net/manual/en/function.mysql-real-escape-string.php
http://php.net/manual/en/function.eval.php
Also, have they added multithreading yet?

Re:Java's problem isn't verbosity

[angel'o'sphere]

Yeah, but that is about frameworks and not about factories :D

I agree that many frameworks completely fail to make clear what problem they solve in which way and why that approach was chosen or is preferred.

Then they have ten so simplified examples that you have no clue how to grow from that into a real solution for your project.

Well, Joel wrote many bullshit, but also quite some nice stuff.

Ah I see at the end he talks about the hammer factory factory builders ... erm ... something like that.

Well, never encountered that in a Java framework.

Re:Java's problem isn't verbosity

[Hognoxious]

Former / current Java dev here.

Make your mind up. Which?

Re:Wake me up...

[frinkster]

You're not a real programmer if you can't adapt to the lack of unsigned variables.

Forget about being a "real programmer" and focus on being a "real developer.' There are functional requirements and then there are technical requirements. Functionally speaking, how important is it to have an unsigned data type rather than having the equivalent data type and enforcing a "no negative values" rule? I'm not sure I can think of any, aside from the case of being able to interpret unsigned data types for interoperability. But that says nothing about the need for the actual storage of that data.

I'm pretty sure that some respected Computer Scientist said something about premature optimization....... It's a good rule. Focus on meeting the functional requirements of the system you are developing, and then optimize where it makes sense. I don't think you are going to notice the lack of unsigned data types. But if you really need them, perhaps that should be a signal that a lower-level language is more appropriate for that particular component in the system.

Dude, still on dial-up?

[Latent Heat]

I am also in th5554444&&&&&&

Google Chrome is killing java

[goombah99]

The thing about Java is that despite flaws it was cross platform. that is it was, up until chrome. Right now you can't run the latest java in chrome. (chrome is 32 bit, and java 1.7 is 64 only.) And then there's chromebook which also has no java. And then there's Dalvik. So google seems to be pulling a microsoft on Java. I've switched away from using chrome to boycott google.

Re:Google Chrome is killing java

[binarylarry]

Java is a lot bigger than Java Applets.

Java Applets fucking suck and deserve to die.

Re:Google Chrome is killing java

[GodfatherofSoul]

Actually, it's not the applets idea it's the fairly recent exploit. I'd been a big user of Java applets previously and was a regular user of Yahoo Games which is a huge online community for all kinds of card and board games. When people bag on applets, they're usually thinking about how terrible performance was 15 years ago. The latest vulnerabilities didn't help much either.

Re:Google Chrome is killing java

[RaceProUK]

(chrome is 32 bit, and java 1.7 is 64 only.)

Total bollocks. Here's 32-bit Java for:

Windows

Linux (tarball)

Linux (RPM)

Re:Google Chrome is killing java

[Groboclown]

Java is a lot bigger than Java Applets.

Java Applets fucking suck and deserve to die.

... except when used in the Java4k game contest. Shameless plug? You betcha. But it's still a great place to find interesting submissions, such as those by _Notch.

Re: Google Chrome is killing java

[MightyMartian]

There are open source Java and Objective C compilers. That strikes me as a pretty weak vendor lockin.

Re:Google Chrome is killing java

[angel'o'sphere]

You can download a Java 1.7 32 bit version from Oracle.

Re: Google Chrome is killing java

[kthreadd]

Indeed. Apple's Cocoa libraries on the other hand. The language is open.

Re:Google Chrome is killing java

[DickBreath]

Java 7 update 25 is no longer current. You should upgrade to Java 7 update 40.

Re:Android is not always Java

[bluefoxlucid]

Actually, Python is strong-dynamic-duck-typed and pre-compiles. Each time you install a Python module, the package manager runs Python to load it as a privileged user--which automatically generates a .pyc and a .pyo compiled native object in the module directory. There are many further implementations of Python (including the ridiculous Pypy, a Python interpreter written in Python) that are compatible with the language; Google supplies Dalvik, a Google-written implementation of Java, so I fail to see why it's any huge obstacle for them to have supplied a Google-written implementation of Python instead.

Java was used for strategic reasons, not technical reasons.

Hooray!

[Greyfox]

I'm looking forward to having to support crappily-engineered code in some other language! I'm going to slap the first in-house engineer who suggests we jump on the NetRexx bandwagon.

Re:Hooray!

[slim]

I worked in Rexx on MVS and OS/2 in the early 90s. I'm astonished it's not dead and buried.

Re:Hooray!

[NeoMorphy]

I worked in Rexx on MVS and OS/2 in the early 90s. I'm astonished it's not dead and buried.

Unless IBM decides to port another scripting language like Perl or Python to Z/OS(OS/390,MVS) and z/VM/CMS, REXX isn't going anywhere.

I've used REXX on MVS, VM/CMS, and OS/2, it's a lot better than Exec or Exec2. But after moving to UNIX and learning Perl, I never looked back.

Re:Android is not always Java

[Waffle Iron]

Great idea! Let's implement everything on our phone in an incredibly slow, dynamically typed language, whose only relevant implementation has a GIL and a pathetically bad concurrency model! That will be great for performance and battery life!

Google is dropping Python for a reason.

If Google had used Sun's Java VM for Android, performance and battery life would have been even worse than you predict for Python. However, Google deployed their own implementation of Java that was specifially tailored for mobile platforms.

There's no reason they couldn't have done the same thing with Python; there are several independent implementations of Python targeted at different use cases. They have the relevant technologies with their accelerated Javascript engines.

It's shocking

[kelemvor4]

With Oracle doing everything possible to kill Java, it's shocking that Java persists.

Re:It's shocking

[DrEasy]

With Oracle doing everything possible to kill Java, it's shocking that Java serializes.

FTFY. :)

Re:Android is not always Java

[IamTheRealMike]

NativeActivity doesn't support most of the Android APIs, including most obviously the widget toolkit. It's intended for games that just need an OpenGL context and raw input, all other kinds of apps still need to use Java.

And you know what? That's not such a bad thing. A few years ago I guess I was basically a C++ programmer who was in the "Java sucks" camp, and I came back to Java only because I wanted to write stuff for Android. Over time I've come to appreciate the whole platform and ecosystem more. Things I especially appreciate:

• IntelliJ IDEA and the Inspector. My previous experience with Java IDEs was Eclipse, which is not only incredibly slow and resource intensive but also has a very confusing IDE. Over the years this situation has changed - IntelliJ is genuinely helpful, and uses much more reasonable amounts of RAM than such IDE's used to. I find myself very much appreciating the real-time, on the fly static analysis that can find all kinds of issues from basic logic bugs to common API usage errors, like inverting the arguments of assertEquals in a unit test.
• Most Java libraries are available via Maven repositories. Maven itself is a rather quirky beast that I never truly warmed to, but the Java world has what is essentially a giant apt-get for libraries. IntelliJ understands how work with Maven such that you can write some code that doesn't compile, press alt-enter over the missing class and tell it to go figure it out. It can find the right library, automatically download it and all its dependencies, install it into the local Maven repository and recompile the code, all on the fly within a few seconds. Coming from the C/C++ world where every single project has a uniquely malformed build system and package repositories (when they exist at all) are maintained by Linux distributors who are invariably miles behind upstream releases, it's extremely convenient.
• JavaFX 8 turns out to be a really nice UI toolkit. Java got a well deserved reputation for awful desktop apps that were clunky, slow, and had UIs only a mother could love. This problem started with AWT that was limited by the lowest common denominator (Motif at a time when nearly the whole world used Windows). Swing was more powerful but was still very ugly and was hobbled by the lack of any truly great UI designers for it (every IDE creator invented their own). JavaFX 8 resolves all these problems: it's designed to be competitive with Cocoa, so the whole thing is an OpenGL accelerated scene graph, it makes it easy to support fancy effects and animations, and it comes with a very straightforward and easy to use Scene Builder app that makes building UIs a snap. I've used the Apple GUI design tools and Scene Builder is even easier. JFX8 seems to make desktop app development with Java actually compelling again.
• Lots of people know it. That means, for an open source project, lots of potential contributors.

Re:Android is not always Java

[Anonymous Coward]

I never said Python wasn't strongly typed, and Python bytecode is basically nothing more than an AST. Every existing Python implementation, including PyPy, is ridiculously naive and years behind the JVM, the CLR, or modern JavaScript implementations. Languages like Python are also much harder to optimize due to how dynamic they are. Like JavaScript, it would take an absolutely massive investment to make a decent Python implementation and no one with the resources cares enough to do it.

Re:Wake me up...

[petermgreen]

I'm pretty sure that some respected Computer Scientist said something about premature optimization

I think there is a balance to be struck, putting too much effort into optimising early on is a waste of time but that doesn't mean that languages that make inefficient soloutions easy and efficient soloutions painful are a good thing. Unsigned types are just one of many cases where java does this.

Unsigned types are a good thing for several reasons.

1: They are easier to bounds check. If you have an unsigned type you only have to worry about making sure it is not too large. If you only have a signed type then you either have to make sure all your bounds checks cover the negative case or be very careful not to accidently generate negative values.
2: They can store values twice as large. Sometimes that is the difference between fitting the number you want in one size of data element and being forced up to the next size (which is likely to double your memory requirements).
3: Some algorithms (particulally in crypto) are designed arround unsigned integers of a specific size.
4: the interoperability requirement you mention. Sometimes you have to work with another system where it has been decided by someone outside your project that say a 32-bit signed integer is sufficient.

Don't get me wrong all these things CAN be worked arround but those workarrounds mean lower efficiency AND more potential for mistakes.

P.S. Java does have an unsigned 16 bit integer type despite lacking unsigned 8 , 32 and 64 bit types. It calls that 16 bit unsigned type "char".

But if you really need them, perhaps that should be a signal that a lower-level language is more appropriate for that particular component in the system.

Mixing languages adds extra complexity, especially with stuff like java. So IMO a good critera for a language is what range of "levels" it can cover without having to resort to mixing languages.

On the verge of using a type twice as wide

[tepples]

Functionally speaking, how important is it to have an unsigned data type rather than having the equivalent data type and enforcing a "no negative values" rule?

If your application logic's requirements include being able to represent values between 2^((2^n) - 1) and (2^(2^n)) - 1, such as 128 through 255 or 32768 through 65535 or about 2.1 to 4.2 billion, in a cache-efficient array, you usually want to use an unsigned type. This often comes up when trying to represent the native unsigned data types of an emulated machine or the unsigned data types of various SQL databases. You could use a type twice as wide, but that'd fill L2 cache twice as fast, causing capacity misses. And on mobile, it'd fill RAM twice as fast, causing the system to kill your application for having run out of memory.

Re: On the verge of using a type twice as wide

[tepples]

An inner loop written in C (or in another time-efficient subset of C++) is fine as long as your platform's curator allows it. A few platforms that I can think of either require all apps to be in managed code (e.g. Windows Phone 7, some Java ME phones) or have a huge entry barrier to native development that a small shop can't surmount (e.g. Xbox 360, other Java ME phones).

update nagging

[csumpi]

I only have two issues with java:

- the constant nagging from the java updater. (Although to be fair, the updater has been killed on any and all of my devices.)

- the braindead way of keeping old version of the jdk and jre around. Words can't describe how freaking lame this is. I only want one java directory, with one jre and one jdk in it. The new versions need to replace the old ones and provide backwards compatibility.

Re:update nagging

[angel'o'sphere]

The new versions _don't_ provide backward compatibility.
And having seperate directories is exactly the rit way to go. You have full control over your installations. If there was only _ONE_ Java installation and it would not work anymore with your age old mission critical application I assume you would be rather pissed!

Re:update nagging

[ConceptJunkie]

That's why so many Java apps are now distributed with, and install and use, their own copy of the JRE, which I think is the logical end-point of the whole Java mentality.

Re:update nagging

[ADRA]

"the braindead way of keeping old version of the jdk and jre around."

I don't know why it bothers, but it certainly isn't required. Usually the only time that happens is in major rev's of the architecture, and to be fair .NET and other major lib changes do the same thing.

Oracle was in part responsible when they required Java 1.1 a decade after it was dead when you installed OracleDB locally.

Re:update nagging

[csumpi]

The new versions _don't_ provide backward compatibility.

Now that would just be plain stupid, and it's obviously not true.

Re:update nagging

[angel'o'sphere]

It is obviously completely true.
Or do you really believe a Java 1.1 AWT applications still runs on Java 1.7? Cross Platform?
The newer VMs can run older byte code, but many "depricated" APIs no longer exist in the newer "Java (the platform)" installations. Hence the application wont be able to load the requested classes or wont be able to call non existing methods.

Re:update nagging

[VortexCortex]

I think they're onto something.

6. Installation

    a. Linux:
        Follow add the software repository from the following
        list then install the package named "my-software"

...

    b. Windows:
        Install Linux, then see step 6a.

I should probably just distribute it on a Debian LiveCD...

Re:update nagging

[ConceptJunkie]

Yeah, it's an unfortunate downside of "Write once, run anywhere, but only with this very, exact, precise version of the JRE" that is the reality for too much Java software.

Re:Wake me up...

[hammyhew]

You're not a real programmer if you can't adapt to the lack of unsigned variables.

You're not a True Programmer unless you use Gamemaker! Return! Return! Return! Return!

Return...TO GAMEMAKERDOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOM!

Java is the new COBOL

[ErichTheRed]

- Most CS programs train their graduates in Java.
- Java is pretty much the enterprisey middleware language these days. I've seen so many J2EE applications alive inside organizations doing mundane but vital tasks.
- Unless you're a web startup, Java is almost universally used for line-of-business application development. That ugly GUI that collects budget numbers from 500 databases and displays an "executive dashboard" was probably slapped together by an Accenture type outfit using offshore new grad coders and sold to companies for millions.

It's just too prevalent now for people to say, "Oracle sucks, we're porting everything to C#." I can definitely see a market for Java talent similar to the COBOL market 30 years down the road. People won't need millions of Java coders anymore, but they'll need older expert types to go untangle messes.

Re:Java is the new COBOL

[WheezyJoe]

That ugly GUI that collects budget numbers from 500 databases and displays an "executive dashboard" was probably slapped together by an Accenture type outfit using offshore new grad coders and sold to companies for millions.

THIS. ('nuff said).

Re:Java is the new COBOL

[Teckla]

People won't need millions of Java coders anymore, but they'll need older expert types to go untangle messes.

The good news is that Java code is relatively easy to untangle. Thanks to the design of the Java language, it's very easy to navigate and refactor code using modern IDEs like NetBeans, Eclipse, and IDEA.

Re:Java is the new COBOL

[znrt]

i find your post more insightful than funny (it's kind of sad per-se that stating the obvious seems insightful in this context). guess the funny part is "Oracle sucks, we're porting everything to C#.". yeah, made me giggle too :)

Re:Java is the new COBOL

[K. S. Kyosuke]

Thanks to the design of the Java language, it's very easy to navigate and refactor code using modern IDEs like NetBeans, Eclipse, and IDEA.

Which is another phrase for "The language is so chock-full with phrasal idioms and low on signal/noise ratio that we both CAN and HAVE TO automate its editing"...?

Re:Java is the new COBOL

[Teckla]

Which is another phrase for "The language is so chock-full with phrasal idioms and low on signal/noise ratio that we both CAN and HAVE TO automate its editing"...?

Nope, not at all.

I think Java found a pretty good balance in terms of brevity vs. verbosity. Most software development is maintenance, so what you really want is readability. Brevity vs. verbosity is a foolish debate that misses the point.

But it's all subjective, to each his own. Unfortunately, many people want to turn it into some kind of religious debate and hate hate hate the infidels and love love love the true believers.

Whatever.

who it is popular with

[cascadingstylesheet]

For whatever reason, Java seems to be popular with the work to spec, outsourcing shop types.

That's because the "cool kids" ignore servers

[daboochmeister]

Java must be dying - when's the last time you saw an applet? Let's ignore that it's hugely popular on servers, for enterprise development.

Native code produces a security exception

[tepples]

But if you really need them, perhaps that should be a signal that a lower-level language is more appropriate for that particular component in the system.

Provided that the platform curator even allows the use of lower-level languages. For example, Java applets have to be written in Java, and Xbox Live Indie Games and Windows Phone 7 applications have to be written in C#.* An applet that attempts to use JNI or an XNA game for Xbox 360 or application for Windows Phone 7 that attempts to use P/Invoke will die with a security exception.

* Technically, XBLIG and WP7 allow the subset of verifiably type-safe CIL accepted by the .NET Compact Framework. But in practice, languages other than C# either aren't verifiably type-safe (such as standard C++ in C++/CLI) or require library facilities not present in the .NET Compact Framework (such as any DLR language).

Re:Native code produces a security exception

[HaZardman27]

If you're writing an applet, you're already doing something wrong ;)

Re:Native code produces a security exception

[tepples]

The point remains the same nevertheless. MIDlets for Java ME phones have to be written in pure Java for the same reason as applets for browsers supporting Java SE.

Re: Keep it up - you might just invent assembly...

[CastrTroy]

Very much agree with this. The library/API that comes along with a language is just as important, if not more important than the language itself. You don't want your programmers spending any time writing their own hashtable or arraylist implementations. You don't want your developers writing their own sorting functions, and you don't want your developers spending time trying to write their own "date math" functionality. Thie is why I find that .Net is actually quite good. The API is amazing. It includes just about everything, and it's very consistently done. It's also relatively free of bugs, and extremely well documented.

Have you seen how much those flying yachts cost?

[swb]

Larry Ellison is just another borderline personality disorder businessman who doesn't give a fuck about anything besides making himself richer and self-aggrandizement.

He and Ballmer should go to some private island and never be seen again.

Re:Wake me up...

[RabidReindeer]

"unsigned integers" are an artefact of "bit twiddling" programming languages. Bit twiddlers are essentially high-level assembly language.

Java is not an assembly language, it is an abstract language. It is intended to create write-once/run-anywhere code that isn't dependent on the CPU or OS, byte/bit orders or how many bits are in an "unsigned integer".

Most programmers actually use "unsigned integer" to refer to a collection of bits, not actually as a mathematical unsigned integer (cardinal number), just as they erroneously refer to characters interchangeably with "bytes".

If you really DO want to work with cardinal numbers in Java, just don't use negative values. A java int can hold a respectably large integer value. And if that's not big enough, there are special classes that are more or less open-ended.

If you absolutely positively must work with 100%-guaranteed cardinal numbers, use Ada, which allows user-defined types to contain user-defined ranges that will be checked at compile time and enforced at run time and that includes integers whose range is from 0..whatever. Of course, there's a price to be paid for that.

Java Is Undead

[Ukab the Great]

I think of it like a George Romero zombie that has plodded along consuming and destroying brains for the better part of two decades and clumsily getting around the shotgun programming language deficiencies with each new release.

Re:Wake me up...

[robmv]

Java 8, Unsigned Integer Arithmetic API, not an unsigned type but helps doing integer arithmetic using signed types

"Java is dead" is a stupid Slashdot meme

[GodfatherofSoul]

Anyone with any real knowledge of Java knows how wrong that is. But, it's been cool on Slashdot to say so and it's automatic karma whoring when you do.

Re:Android is not always Java

[Waffle Iron]

Java might be a shitty language, but the JVM blows away any existing Python implementation

You're right: The JVM blows away almost any other language in terms of megabytes of physical memory wasted and CPU cycles consumed before getting to main(). And you're not going to be able to run the whole system in one JVM to try to combat this.

and is still significantly faster than any JavaScript implementation.

Mostly irrelevant. Java needs to be fast because most of its libraries are written in Java. Other languages tend to use native code for most libraries, and that's just tied together with the users' business logic. A high-tech JIT-compiled Python would almost certainly be "fast enough".

Re: Wake me up...

[KiloByte]

On the other hand, it has no type meant to store a single character that is capable of doing so.

Re:Wake me up...

[VGPowerlord]

1: They are easier to bounds check. If you have an unsigned type you only have to worry about making sure it is not too large. If you only have a signed type then you either have to make sure all your bounds checks cover the negative case or be very careful not to accidently generate negative values.

So, what does your code do if an end-user passes -1 which would get stored in your unsigned value? And as a reminder, your argument is that you don't have to do bounds checking for the lower bound.

Scripting Language?

[Anonymous Coward]

Scala is not a scripting language

Re:Long term decline

[buddyglass]

One can make a credible case that Java's decline in market share is due to the "market" for programming languages becoming more diverse over time. Let's consider the languages with the largest market share in 2001, which is the farthest back the TIOBE graph goes:

Java: ~26.5%
C: ~20.0%
C++: ~14.0%
Visual Basic: ~8.0%

Now let's check out each of those language's current market share:

Java: 16.15%
C: 16.98%
C++: 8.66%
Visual Basic: 4.84%

Now we can look at the deltas, both in absolute terms and as a percentage of original share:

Java: -10.35% (~39% decline)
C: -3.02% (~15% decline)
C++: -5.34% (~38% decline)
Visual Basic: -3.16% (39.5% decline)

The baseline decline for languages that enjoyed wide popularity in 2001 seems to be 15%. Java is declining, but seems to be doing no worse than C++ and Visual Basic are. (Which is perhaps damning with faint praise.) However, unlike C++ and Visual Basic, Java is declining from a position of dominance (at least in terms of TIOBE metrics).

IMO, if any language should be worried it's Ruby. Ruby is already less than half as popular (1.5%) as it was at the peak (4%), and it's more-or-less eclipsed by Python. There are some credible reasons to prefer Java to Python/Ruby in certain contexts (e.g. Android, where it's the only game in town). There aren't many strong reasons to prefer Ruby to Python, esp. given the larger Python development community makes it easier to hire devs.

Re: Wake me up...

[gnasher719]

On the other hand, it has no type meant to store a single character that is capable of doing so.

But then no language has. In C++, std::string is the simplest thing guaranteed to store any single character.

Re:If there's such a market.. why the Ask toolbar?

[Hypotensive]

How am I supposed to take a platform seriously if the fundamental piece that has to be installed by all developers AND users to use it

All the ones on Windows, anyway.

Re:The Java platform is an engineer’s dream

[ebno-10db]

so heavily optimized that often Java apps can even match the performance of C programs

Benchmarks?

Re:Android is not always Java

[Hypotensive]

You may not have noticed but a number of manufacturers are going down the road of using HTML5 web apps as their mobile application platform. JavaScript certainly seems to fit your description. Actually, it doesn't have a concurrency model at all.

When Java first came out it was also incredibly slow and had a pretty primitive concurrency model. It's taken many years and a crapload of cash to get it to where it is now. Python hasn't had any cash to speak of.

Re:Android is not always Java

[angel'o'sphere]

Python rund fine on Android.

The Android Java VM and the Android Java dialect are nevertheless helpfull, as you have interfaces to describe services and compile time type safty.

Re:Wake me up...

[interval1066]

It would be nice if java supported something like typedefs.

Dweebs hate Java because it is too easy

[Squidlips]

The same idiots who pushed C++ on us hate Java because it is not verbose and not "powerful"--i.e. it is easy to use and safe.

Re:Dweebs hate Java because it is too easy

[Luthair]

Quite a few people just hate it because its popular.

Re:Wake me up...

[MightyMartian]

For something that's not a "real" language, it certainly seems to have significant penetration in the enterprise.

Javascript will kill the internet

[gelfling]

No really it will. Apparently there's a law that says to have a website you have to run 45 different Javascripts nested 4 layers deep or more. And because of it basically 99% of the hosts out there are essentially slow junk.

Re:Have you seen how much those flying yachts cost

[gtall]

Noooooo....if they mated, they'd produce Satan's offspring more terrible than either of them alone. No, I think it best if we send them to private islands on different planets.

Re:Android is not always Java

[angel'o'sphere]

Erm, how can your first sentance and the last one fit together?
Exactly because Python is dynamic typed it is inferior as a systems programming language in regards to Java.
The obstwcle is the "instead".
Especially as there are python implementations for android, your rant is obsolet, just take them.

Re: Keep it up - you might just invent assembly...

[gbjbaanb]

sort of. .NET is good simply because of Visual Studio and intellisense and all the other "make it easy" features they have - features I'm sure they could have added to other languages.

But .NET is missing loads of stuff, the last one I found was the lack of a graph or tree container, a dictionary just doesn't cut it. Oh, and I keep using Single() in my EF LINQ calls.. which doesn't support it, even though its a method on IEnumerable... lovely that, an interface that supports some methods some of the time.

So no, the API is not a good thing as it constrains you into using it and the bigger the API the more people think they have to use it, and only it. Other languages do much better in this regard, by letting you add in libraries for various functionality as you need it, so if I needed a tree container, there would be one, or more, standard libs available for me to fetch and pull in. Then my library of libraries would be filled with whatever was needed today - not what was hot 5 years ago when that API was thought up.

Java is the new COBOL

[Anonymous Coward]

And it'll stick around for just as long...sadly

Re:Android is not always Java

[X0563511]

I've never seen Python do that on my systems. Those files (.pyc) don't appear until I actually cause them to be loaded for the first time. I think you're confusing what python does with what your distribution maintainers do :P

Re:Android is not always Java

[X0563511]

I don't appreciate having to pay for the IDE for personal or educational use. IntelliJ can fuck off, back to Netbeans/Eclipse I go.

Re:Wake me up...

[0xdeadbeef]

But if you really need them, perhaps that should be a signal that a lower-level language is more appropriate for that particular component in the system.

Yeah, that worked real well when j2me was the only game in town. The phone companies were so amenable breaking out of the sandbox.

As one of those "real programmers" who did work around the sign bit for bignum math, I laugh at you and the anonymous retard above, who didn't even get the bitmask right. Being able to work around other people's stupidity is something that "real programmers" can do, but it isn't something that makes them a "real programmer".

Re:If there's such a market.. why the Ask toolbar?

[Luthair]

Microsoft does try install Bing cruft every time one updates Skype however.

Re:Wake me up...

[geminidomino]

So do Microsoft Access (or, gods help us all, Excel) "databases" and PHP.

Talk about damning with faint praise.

Re:Wake me up...

[MouseTheLuckyDog]

Unsigned integers are not just for optimization.

I remember as a young pup writing a part of a program which suddenly crashed in certain circumstances but not on NT only in Win95.
Of course the problem was not detected until the program was out in the field because all the developers used NT.

I was using memory mapped IO. At one point I was reading from I something in an array of variable size. At the end I was supposed to determine how many there were. Simple enough calculate the length divide by the size.

So I cast the final address and the base address into an int and subtracted to get the length.
Turns out that when using NT the address of memory mapped IO is something like 0x1XXXXXXX and on WIn95 it's 0x8XXXXXXX. So on WIn95 the addresses got cast into negative numbers and returned a negative length. All because I used ints instead of unsigned ints.

BTW when I worked at Lucent, I got a chance to speak to one the the automated testers. Turns out that often times when you run an automated stress test, and get an intermittent failure a couple of times out of a thousand that it is usually an int somewhere that should have been declared an unsigned int.

Re: Wake me up...

[Joey Vegetables]

IMO, an optimal type system does not contain every type anyone anywhere might need at any time. It does contain the primitives from which developers can construct their own. Do I need a 36-bit "word" type? No, but if I did, I know how to construct one, in any of the statically typed languages I know. A Roman Numeral type? Same. I do not expect a language to be burdened, at least in the core language or standard libraries themselves, with either of these types, so long as I can construct them out of what the core language/libraries *do* contain. In most modern languages, which are Unicode-aware, the very concept of what constitutes a "character" is somewhat complex, but that complexity is buried in the implementation of a String or similar class. And the String class already does a superset of what you are asking. It will store a single character. (Or zero characters, or multiple characters). A subclass of String could trivially be designed to hold one, exactly one and only one, and still be Unicode-aware. Or, if you don't care about Unicode, and define "character" as simply a character representation of an unsigned 8 bit byte, then, notwithstanding Java's unfortunate exclusion of unsigned char/short/int/long types, you still can construct a class that will do what you want. Now I can't promise optimal C-like efficiency in either case. If you truly do need that, well, my Java may be too rusty to help you in detail, but I'm guessing there are multiple good approaches. Including just writing it in C and using JNI or whatever the modern equivalent is today. I sympathize with your frustration over Java lacking some of what even I would consider basic primitive (unsigned) types, and I happen to prefer C# over Java for that among other reasons, but Java's popularity and widespread use across virtually every niche and industry segment all suggest that there are ways to work around and/or through it.

Re:I was at the JavaOne 2013

[buddyglass]

My employer has had real trouble hiring an Android dev to back me up. Totally anecdotal, but there you go.

Re: Wake me up...

[jythie]

char []?

almost open source wins

[peter303]

Oracle offeres it for free on many platforms. Java's similar competitors C# and ObjectiveC cant make that claim.

Re:Wake me up...

[jythie]

Premature optmztion is rt of al evl.

Re:Wake me up...

[sydneyfong]

It would probably become UINT_MAX, then I suppose what the GP means is that the value would violate the upper bound check, and then implicitly and magically fail the validation without having to type an extra " || x 0".

Yep I think the argument is crazy, but at least the code works.

Re: Keep it up - you might just invent assembly...

[CastrTroy]

The .Net library doesn't constrain you. If you don't like it, it's very easy to get another library that offers more functionality, and use that. Over the years, I've used third party libraries for things like FTP, Email, data charting, PDF rendering, and plenty of other tasks. Some of these, like data charting (bar graphs, pie charts), are now handled well by the .Net APIs, but they weren't always. But if you have more complex needs which they don't cover in their charting libraries, then there's tons of third party libraries which offer even more functionality.

Hugh Pickens DOT Com writes

[nitehawk214]

Checklist:
* Hugh Pickens DOT Com
* Clickbait summary
* Absurd premise
* Trolling conclusion.

Re:Wake me up...

[0xdeadbeef]

It would throw an exception at the site of the cast. Why do you think Java would be dumber than C with warnings turned off?

You apparently don't know the difference between something the VM should be doing and having to repeat stupid boilerplate like this a thousand times:

if (index < 0) throw new IllegalArgumentException()

Re: Keep it up - you might just invent assembly...

[jythie]

Choosing a language is much less about technical requirements as it is about HR requirements. A while back I was watching a company that built their applications around LISP, but ended up switching to C++ due to Universities not providing enough 'ready to go' developers who use the language. Another company that I worked at ended up switching to Windows for the same reason, they had too much trouble finding Linux developers fresh out of school in the right domain, so it was cheaper and easier to move the whole system to Windows then to train up people on Linux constantly.

Re:Wake me up...

[Urkki]

Wake me up when java supports unsigned integers. Until then it's not a real language.

While unsigned numbers are great for a few things, mixing them with signed numbers is a real pain. Just consider all the C functions, which take in unsigned but return signed, and casting galore that follows. Of course you can just disable relevant warnings entirely and blindly hope implicit casts anywhere will never overflow, but that is kind of sloppy, and just asking for someone to find a way to use it for an exploit. Which incidentally is what most C code does.

Re: Wake me up...

[zakeria]

a "char" would be 8 bits

Re:Wake me up...

[Ravaldy]

I love my signed/unsigned variables. When you do high level programming this is the kind of shit you don't want to worry about. It makes code easier to read and understand AND it has zero impact on the performance of the final product. The compiler brings it back to it's native form.

Now, if you do low level programming I understand you don't want the signed/unsigned BS but Java is mostly for high level programming so it's a moo point.

Re:Wake me up...

[0123456]

Yeah, no Java programmer needs unsigned ints. It's not as though they need to interface to code which does have unsigned ints, like calling C++ libraries, or reading data from files or databases created by C or C++ programs, or reading files in standard, language-agnostic formats which are packed full of bytes that you then have to process as 16-bit signed integers instead.

Lack of unsigned variables is one of the most braindead ideas in Java.

Re:Wake me up...

[0123456]

So I cast the final address and the base address into an int and subtracted to get the length.

If you're ever, anywhere in your code, casting pointers to integers, and it's not because you're passing it to some low-level interface to hardware... you're almost certainly doing something wrong.

"cool kids"? /. has become corporate

[Baldrson]

This kind of talk, bolstering a platform that is dominant by virtue of its network effect in corporate culture, is, quite simply, corporate.

Let's be clear on what /. used to be and what it has become.

/. used to be a place where technology was king.

/. is now a place where kings are king.

Speed is Everything

[LifesABeach]

If Python, Ruby, PHP, and Javascript were sled dogs, they would be following Java. and the view would never change.

Dr Dobbs...

[Luthair]

Sure has a cutting edge website, readers are no doubt the technical leaders of the world.

Re:Dr Dobbs...

[oh_my_080980980]

So web sites optimized for tablet viewing are considered cutting edge...wow...nobody said script kiddies were smart....

Re:Wake me up...

[toopok4k3]

Your choice comes in the form of picking the language that suits your needs.

Re: Wake me up...

[lgw]

Characters suck. C++ and Python both allow easy 32-bit characters, which at least allows you to store one Unicode codepoint per "char". But in non-Western languages there are still glyphs that must be composited from several codepoints.

But why would anyone care? UTF-8 works fine for sorting and comparing and so on, it's well designed that way.

It's not dead...

[Phoenix666]

...it's just compiling.

Re:Wake me up...

[lgw]

No, that's just wrong.

Often you have a value for which negative numbers are always wrong/senseless. An unsigned type neatly encapsulates that constraint. It trivially becomes part of the API contract that "negative values don't make sense, so you can't pass one here".

ADA of course takes it a step farther, allowing both min and max constraints on any integer. But the "non-negative integer" is a common enough special case to justify a type of its own.

Oh, and your completely misusing "cardinal number" - when you use big words to try to sound smart, but get them wrong, it's quite embarrassing.

Re:Wake me up...

[lgw]

Yes, just like COBOL. And just like COBOL, it's mostly used for the most boring sorts of "Enterpise" software (which used to be called "card-whalloping code" back in the day).

The phone thing is new, and at least gave Java a new chance at being cool. Hasn't worked out that way so far, mostly because, like COBOL, there's all this annoying wordiness and boilerplate all over the place, so it's hard to ever feel the result is "elegant". And if stuff you write on your own can't be "elegant", that just uncool.

Re:Wake me up...

[MightyMartian]

I don't code out of some desire to be a hipster. As we speak, I'm writing a Joomla component in PHP, a language I loathe (though it has improved of late), but it's the language the project requires, so here I am. In a few months, maybe I'll be coding in Java, if the project requires it. For me, the one place I have little or no desire to go is to any of the .Net languages, simply because of the lack of meaningful portability.

sorry but ...

[znrt]

who said java was dying (apart from some of the dozens of clueless tech-tabloids regularly cited on /.) ?

Re:Android is not always Java

[dkf]

Swing was more powerful but was still very ugly and was hobbled by the lack of any truly great UI designers for it (every IDE creator invented their own).

I've seen non-ugly GUIs done with Swing. I'm pretty sure they're a demonstration of the fact that pigs can fly as long as you provide sufficient TNT-derived thrust (and that you don't really want to stand underneath as the pieces soar overhead).

Re: Wake me up...

[angel'o'sphere]

No it is not!
char a = 1234; // compiles
char b = a + 15; // does not compile
char c = 15;
char d = a + c; // does not compile

Everywhere a char is used (and the java code actually compiles) the char is promoted to an int, an signed int.

Just because a char is 16 bits wide and arguable a 'variation' of an int does not make it a useable 16 bit unsigned int.

 

Re: Wake me up...

[DickBreath]

> a "char" would be 8 bits

It's the 21st century. A byte is 8 bits, something computers use. A character is something that is the basis of human languages and comes in many, very many, different varieties.

There are various ways of encoding characters (for humans) into bytes (for computers) and then later decoding them back to characters again. Several of these 'charsets' or 'character encodings' are standard and well known. UTF-8 is a particularly nice way of encoding characters because in one byte it can represent the commonly used Roman characters and ancient 7-bit ascii from some forgotten millennium long ago swept away in the sands of time. Any character can be coded as UTF-8 and may end up encoding into multiple bytes. Those bytes are just as easily decoded back to a string of characters.

Banish from your thinking the very idea that characters and bytes are the same thing and are assignment compatible. They are not assignment compatible. An array of characters is passed to an encoding function to give back an array of bytes. And vice versa.

Re:If there's such a market.. why the Ask toolbar?

[VGPowerlord]

How am I supposed to take a platform seriously if the fundamental piece that has to be installed by all developers

You had me up until said you "all developers".

Developers need the Java Developers Kit, which notably doesn't prompt you to install toolbars. Nor does the JRE installer on the Java developer site (which used to be java.sun.com).

Unfortunately, unless you know to grab the installer from there...

Re: Keep it up - you might just invent assembly...

[iONiUM]

I don't know what you are talking about, EF does support .Single() just as any other LINQ method works on an IEnumerable (here's a question about it). If it was throwing an exception, it's because you had more than 1 item meeting the criteria, and you don't know what you're doing. Try .FirstOrDefault(), which will not throw an exception.

As for why there is no Tree class in .NET, you can refer to this question, where the answer is enumerated for you. Having worked with .NET since 2003 when it came out, and in the interim having to work with Java, Obj-C, and other platforms, .NET is without question the most "well done." Typically if you're having problems like you cited above, it's due to a lack of understanding on your part.

Re:If there's such a market.. why the Ask toolbar?

[phantomfive]

Even Microsoft doesn't try to install Bing with the .NET installers, and that's their own property they're desperately trying to push on everyone.

They install it with the OS.

Re:Wake me up...

[RabidReindeer]

Yeah, no Java programmer needs unsigned ints. It's not as though they need to interface to code which does have unsigned ints, like calling C++ libraries, or reading data from files or databases created by C or C++ programs, or reading files in standard, language-agnostic formats which are packed full of bytes that you then have to process as 16-bit signed integers instead.

In other words, "bit twiddling".

Java has had closures for years

[Animats]

Java has had closures, with all the stuff that does to local variable lifespan, since Java 7. Lambda expressions are just syntactic sugar for writing small closures.

Re:Wake me up...

[DickBreath]

> Any *real* programmer that used anything but a toy language would understand why unsigned integers are important.

As the Minbari ambassador Delenn says, it's all a matter of perspective.

If you don't program close to the bare metal, then you seldom, if ever have a need for unsigned integers. Think of languages as a continuum starting from the very low level of abstraction (assembler) to the very high level of abstraction (Mathematica, Clojure, Scheme, Haskel, Scala, etc). What you call a real language and a toy language all depends on what kinds of software you write. If you are working on symbolic reasoning, you probably use a different language than you would if you were writing an mp3 encoder. The former would call C a toy language.

Also, if you happen to have the PBS NOVA documentary about IBM's Watson (a couple years ago), pay attention to some of the close up screen shots of the Watson developers' laptops. It's all (gasp!) Eclipse and Java. OMG -- those not "real" programmers need to use a language with unsigned integers! How can they expect to accomplish great achievements without unsigned integers! (Gee, I wonder if they ever once, one single time, thought: "drat -- I wish Java had unsigned integers".)

Re:Wake me up...

[RabidReindeer]

If you want to complain that Java lacks the ability to define its own non-class data types, I'll be glad to sign the petition. Although I don't like "special case" types, and the 0..(some limit) sequence isn't really any different than any other range-restricted integer type other than in popularity.

As for definitions of Cardinal and Ordinal numbers, those were the ones foisted on me in 5th Grade. Blame my teachers for not being enough into advanced Set Theory.

Re:Wake me up...

[Drethon]

And if that end user is working with a boundary constrained entry field?

Re:Wake me up...

[jeremyp]

No, that wasn't the problem unless the memory mapped region crossed the boundary from 0x7FFFFFFF to 0x80000000. For example, 0x90000000 - 0x80000000 is 0x10000000 whether you use 32 bit signed or 32 bit unsigned arithmetic.

Also (this might not have applied at the time of Win95 and crappy Microsoft C compilers) it is legal to subtract one pointer from another in the same array (or one past the end of it) without converting to an arithmetic type.

Re: Keep it up - you might just invent assembly...

[DickBreath]

> sort of. .NET is good simply because of Visual Studio . . .

In case you are not aware, there are some very nice IDEs, even free and open source ones, for Java. And the IDEs run on any platform, just like the rest of Java.

Re:Wake me up...

[IamTheRealMike]

You know, it's not like Java lacks unsigned types because they simply forgot about them. It lacks them because experience with C and C++ indicated that mixing of signed and unsigned types can lead to lot of weird bugs. It's one of the reasons those languages have a reputation for being giant cannons pointed at the developers feet.

On the flip side, although lack of unsigned types probably makes pure Java code more robust, the moment you have to do any kind of parsing of file or wire formats it immediately becomes a sharp edge with which to cut yourself (that and the decision to make the JVM big endian - doh!).

Ultimately I'd rather Java had unsigned types, if only to make interop eaiser, but the line between safety and features is always a finely balanced judgement call.

So fix it

[Weaselmancer]

It's an object oriented language. If it's missing a type you need, go make one.

Re:So fix it

[HornWumpus]

It's a broken OO language. When it supports operator overloading you will be correct. Until then, it sucks.

You can understand most of what is wrong with Java by reading about int vs Int. Enjoy IAdd and the like. Worse then Cobol.

Re:Wake me up...

[jeremyp]

A real programmer uses the tools that are available or mandated. A real programmer knows how to code around the limitations of whatever language they are using. When I program in C, I use unsigned types all over the place. When I program in Java, I barely notice they are missing. Certainly, the lack of unsigned integers in Java is far less of an inconvenience than the lack of a proper string type in C.

Re: Keep it up - you might just invent assembly...

[DickBreath]

> Static typing is valuable for catching lots of coding errors before execution.

Yes.

Also, there are subtler benefits to static typing. It enables excellent 'toolability' of the language. That is, your IDE can do 'intellisense' type stuff and get it right. It can know exactly what members to offer on a variable or value of some particular type.

Furthermore, the static type checking done by the compiler is your very first line of testing before you get into your own higher level unit tests that test the deeper logic of your code. Think of static typing as the compiler unit testing your code for obvious logic errors and assignments that couldn't possibly make sense at runtime.

Re:Android is not always Java

[IamTheRealMike]

IntelliJ IDEA Community Edition is both open source and free, so your comment is a pretty epic failure. As it happens I bought the Ultimate edition during their end-of-the-world sale that was in the hours before the Mayan calendar predicted armageddon, so I got it cheap. Best doomsday scenario ever!

Re:Have you seen how much those flying yachts cost

[lgw]

Now that's just plain wrong. C'mon: there's nothing about Larry's personality disorders that should be described as "borderline".

Ballmer at least has the grace to exit - give him credit for that!

Re:Long term decline

[znrt]

one can also make a solid case that that data is random bullshit.

Re:Wake me up...

[znanue]

hmm, wordiness is irritating, I'll grant you, as is boilerplate. But, it just stops being irritating the moment that your IDE starts taking care of all of that for you. Writing Java from the command line is an exercise in extreme torture, but Eclipse makes it just fine. Liberal use of ctrl-1, ctrl-space, and the refactor functions on context menus and the actual menu make most of these annoyances trivial. Also, I have yet to see something that can refactor javascript as well as eclipse refactors java.

Also, cool I define by how powerful, flexible, and quick a language is to accomplish tasks. Boilerplate in the age of modern IDE's seems to have almost a negligable impact on those metrics. Boilerplate and language redundancy also often helps with human parsing of the language, imo, so it might even have a bit of a positive effect.

Lastly, I almost never agree that 'terse' is elegant. Elegance should only be clever in what it is actually doing, not in how it is being expressed in the language.

Re:If there's such a market.. why the Ask toolbar?

[IamTheRealMike]

The Windows JRE installer is an obnoxious piece of crap. Fortunately modern JDKs ship with something called the JavaFX Bundler, which makes native installers (exe, msi, dmg, rpm, deb) for each platform that bundles a stripped down JRE with the app, so there is no need to install the JRE or keep it up to date. If you are distributing consumer software or don't want to handle the problem of keeping JREs up to date, it's useful.

There are also tools that can eliminate the need for the JVM entirely, for instance by ahead of time compiling entirely to native (Excelsior JET is one such program), or alternative JVMs that sacrifice some performance for code size, like Avian.

Re:Wake me up...

[lgw]

Oh, most people are innumerate these days.

Nothing to do with set theory, really. Cardinal numbers indicate a count of objects: "one, two, three". Ordinal numbers indicate an order - a position in a sequence: "first, second, third". The major usecase for unsigned numbers is really indexing into arrays/collections (you don't know the max at compile time, but you do know the min) - in a sense those are ordinal numbers - positions in a sequence.

Some people use "whole numbers" for the non-negative integers, and "counting numbers" for the positive integers, but I never heard those terms in college math classes. And anyway, I'm a programmer, I count from 0!

Re:Android is not always Java

[bluefoxlucid]

I said the package manager does it. When you run Python, it generates the .pyc and .pyo files for modules loaded:

Each time you install a Python module, the package manager runs Python to load it as a privileged user

The .pyc and .pyo files for system libraries are generated at installation time, because a non-privileged user running a Python application wouldn't be able to store those files in a system-wide location (for good reason: you could store malicious ones and jump across security zones by injecting code into other users' applications by replacing some runtime files with new ones that get loaded the next time they use that application).

Re:Android is not always Java

[X0563511]

Search for "intelliJ IDEA" and try to find any mention of that on their page. Not quite so epic a failure in reality, was it?

Nice catch on the deal though.

Re:Wake me up...

[dkf]

It would be nice if java supported something like typedefs.

What for? Either you're doing it to name a type elegantly — except you don't need that in Java because classes already have reasonable names and you don't have a mess of structures as values plus pointers and references, as in C++ — or you're doing it to hide how complex the implementation of a data structure is — but there you're really encouraged to wrap a class around it and put an honest API in place — or you're doing something like aliasing. Aliasing isn't a great idea either; it's very non-obvious when used in substantial amounts. No, the lack of typedefs is not something that is particularly felt by Java programmers.

I'd much rather have the built-in DOM support integrated into the standard collection model; that would genuinely save a lot of messing around.

Re:Wake me up...

[lgw]

Having done both Java and C#. I choose to take the C# jobs now because the language is a lot more fun. Nothing to do with fashion. If you're managing your career well, you should eventually get to the stage where you can choose a platform that is pleasant to work on, by whatever subjective measure. I code for money, no doubt, but there's no reason to do that on an irritating platform, once you have the choice. Starting out, we all have to pay our dues, of course - someone has to do the shitwork.

For fun projects I write C++, because I can be sure that proper style is used when I'm the only coder, but professionally I cringe at legacy C++ codebases.

Re: Keep it up - you might just invent assembly...

[Zero__Kelvin]

"Java 8, expected in March, will add closures (that is, lambda expressions)"

Closures and lambdas are not the same thing actually.

Re:Android is not always Java

[bluefoxlucid]

It's an application programming language, not a system programming language. Android is a Linux system written in C and C++ mostly.

The argument was that the current Python implementation wasn't good enough; the counter-argument is that neither was Java, since Google wrote their own and use a different bytecode. (Oracle sued Google because Google "java" wasn't real "Java").

Re: Keep it up - you might just invent assembly...

[Gibgezr]

None of the very nice IDEs I've tried have come close to being as nice as VS. Eclipse is OK, so is Code::Blocks, but nowhere near the magic ease-of-use and power combination that VS offers. VS isn't perfect, and it's ease-of-use has started a downward trend since VS9 in 2008, but it's still far beyond all the open-source IDEs I've tried under both Windows and Linux.

Re:Android is not always Java

[bluefoxlucid]

Google wrote their own JVM because the JVM is a piece of shit that wouldn't work. They use a different bytecode completely incompatible with Java JVM bytecode. Uncompressed Dalvik is smaller than compressed JAR for the same Java class. It's also faster, and consumes less RAM.

Re:Wake me up...

[lgw]

If the IDE can automatically insert it all, why not have the compiler do so? This is why I find Java too irritating to work with, but to each his own.

Terseness is a necessary but not sufficient condition for elegance.

Re:Wake me up...

[MouseTheLuckyDog]

What part of "So I cast..." did you not understand?

Re:Android is not always Java

[IamTheRealMike]

Yes, I have too - IntelliJ itself is written using Swing and it's quite appealing on all the platforms I've used it on. But I guess that they had to develop custom themes for it and be very careful to achieve that.

JFX8 looks great out of the box. It supports hi-dpi/retina displays and has a generic cross-platform theme called Modena which is a lot more tasteful than previous Java desktop themes. It doesn't match any particular platform, but I've been writing an app with it on the Mac and it can actually look better than Aqua sometimes. Still, the theming system is powerful enough that you can also get AquaFX which matches the theme in MacOSX Mountain Lion (it's done by a third party).

Just to ram home the point about Maven+IntelliJ, enabling AquaFX in my project involved typing in the following code:

                if (System.getProperty("os.name").toLowerCase().contains("mac")) {
                        AquaFx.style();
                }

(you're only allowed to use AquaFX on a Mac because of the art being copyrighted by Apple, etc).

Of course AquaFx is an unknown class, so I just asked for an auto correct there, told it to find the class in Maven, then did an interactive search for AquaFX in the resulting dialog. Press enter, and it was downloaded+installed in the background. Also the build system definition (an XML file) was updated so people building from the command line or using other IDEs would also see the dependency. A few seconds later the code is no longer red and the app runs.

It may well be that .NET has something similar, and I know most scripting platforms have this sorted out these days too, but it's nevertheless very convenient to have it so tightly integrated.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Java is fine, the JVM is thriving... C# dying

[echtertyp]

Java is evolving nicely. JVM languages, such as Scala and Clojure, are booming, and awesome to work with. C# , and .NET, are going the way of the Soviet Union.

Re:Wake me up...

[TechyImmigrant]

>So, what does your code do if an end-user passes -1

Every verilog coder knows that you would get '1

Re:Wake me up...

[TechyImmigrant]

A real language would have reals, integers, natural numbers, complex numbers, rings, groups, fields, modular groups, vectors, matrices and booleans.

Re: Wake me up...

[Hognoxious]

If ISO-8859-1 was good enough for Suetonius, Jesus and Shakespeare it's good enough for the likes of you.

Want to draw heiroglyphics, Pitmanesque squiggles and Morse chuffing code? Do them as gifs.

Re: Keep it up - you might just invent assembly...

[Atzanteol]

What's interesting is that I've had the opposite reaction. When I use VS I'm amazed at the lack of functionality it has compared to Eclipse. Why the hell can't it just "import what's needed like Eclipse can" for me rather than making me click on silly little drop-downs which only show when I hover over squiggly-underlined types it can't find? Just one rant but I hit things like this all the time in VS (or VS2012 at least - the last one I used). That and I have to get used to compiling again. ;-)

It all comes down to expectations.

Re: Wake me up...

[VortexCortex]

Well, I agree UTF-8 is good for storing and rendering (and it supports the full Unicode range [and then some], Unilke 32 bit chars), however, unless you are normalizing your composed characters (decompositions) then Unicode isn't very good for comparisons or sorting, and neither is any encoding of Unicode, such as: UTF-8.

The problem is that normalized (decomposed) compositions can take up a lot more memory than the composed character, esp. in UTF-8 (which favors the western characters). Since memory (and bandwidth) is no longer as much of a concern UTF-8 is fine, but we should not store compose characters except for internal representations... However, I've yet to find an implementation that properly handles the normalization features of Unicode 3.0 as well as over-long forms -- both can be leveraged as exploit vectors: the former by improper sorts and duplicate displays despite different representations, and the latter to bypass input validation.

Furthermore, at the lexical level Unicode is poorly supported, for identifier names, etc. See also the above exploits and more, then occurring at the source level. I've a toy compilable language in the works that handles these issues and more, for which I've had to implement my own Unicode processing functions. It's remarkable how poorly nearly all languages fail when I start applying my unit tests to them...

I'm of the opinion Earth needs a single official language, but I'm disheartened that it will be English -- The least machine comprehensible of them all. Oh well, there's always next big bang.

Re:Android is not always Java

[markhb]

I just Googled IntelliJ IDEA (didn't use quotes), and two of the links that were neatly arranged for me were "Community Edition" (which seems like a Big Flag to me) and the Download page, which as noted above includes both the full-featured and open-source variants side-by-side. It's also worth noting that Google has adapted IDEA into the "official" Android IDE.

Re: Wake me up...

[lgw]

You should have seen language before this big bang!

Yeah, composition sucks, but fortunately there just no reason to care how much space human-written text takes up these days (logfiles are a different matter). The biggest weakness in the Unicode standards is the lack of semantic information IMO. They should be releasing normative tables of machine-readable metadata about characters. It's still maddening just to write ToUppercase() in a cross-cultural way, and there's just no reason that should be hard.

I've written "any encoding to good clean Unicode" readers that handle broken encodings well, but I just can't figure out where to even start on composition. Something from the standard to make it all clear (for every reasonable composition) would sure be nice.

Re:Wake me up...

[vilanye]

That is the battle cry of the inept programmer.

There is a difference between premature optimization and blatantly writing inefficient code because you don't know any better.

Re:Android is not always Java

[jonabbey]

Yes, I have too - IntelliJ itself is written using Swing and it's quite appealing on all the platforms I've used it on. But I guess that they had to develop custom themes for it and be very careful to achieve that.

JFX8 looks great out of the box

Agree about the difficulty with Swing. Swing permits different look and feels to differ too much in essentials like ordering of operations, focus, and etc. It makes it very hard to adjust the styling of individual components and expect it to do anything reasonable in different look and feels.

JavaFX sounds really good, but I've not yet developed against it. Thanks for the link to SceneBuilder, I look forward to playing with it.

Re:Long term decline

[buddyglass]

The TIOBE data or my summary?

Confusion

[Fnord666]

This is what happens when you confuse anecdotal evidence with fact.

BSD is dying

[Nick]

It is now official - Netcraft has confirmed: *BSD is dying Yet another crippling bombshell hit the beleaguered *BSD community when recently IDC confirmed that *BSD accounts for less than a fraction of 1 percent of all servers. Coming on the heels of the latest Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as further exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

Re: Wake me up...

[turgid]

Your kidding right? C++ supports many types of characters, including Unicode and arrays of those characters.

C++ supports bytes and arrays of bytes (statically-allocated ones at that). The rest is in the library.

Re: Wake me up...

[ebno-10db]

ISO-8859-1

The one with those funny marks on the letters? Bah. ASCII. The eighth bit is just a spare. If you can't do it in English, then it isn't worth doing.

Re: Wake me up...

[DickBreath]

> ASCII. The eighth bit is just a spare. If you can't do it in English, then it isn't worth doing.

The Vorlons would disagree.

Re:The Java platform is an engineer’s dream

[ebno-10db]

Benchmarks are the worst possible way of measuring program speed, except for all the others that have been tried from time to time.

-- with apologies to W. Churchill

Re:Wake me up...

[jkauzlar]

This is a stupid thing to even argue about, but I've been using Java for a decade and have barely needed to do these things you mentioned. I suspect they're done so rarely that the collective time saved from not having to deal with mixed signed/unsigned types in APIs far outweighs the joys of having an extra bit. And when you need to, support for byte arrays is really very good.

Re: Wake me up...

[jd2112]

Wrong. You aren't a real witch if you don't pass basic hex.

Re: Wake me up...

[Anonymous Coward]

"ToUppercase() in a cross-cultural way" ... doesn't mean anything. Case rules vary between languages, when you ask for Unicode to somehow solve this you're asking for cultural imperialism. "I want one case rule, so other cultures will be exterminated". That was never the purpose of Unicode, maybe start your own "Uniculture" forum where you agree to wipe out all the people who don't wear the same kind of clothes and eat the same kind of food. Good luck with that.

Re: Wake me up...

[lgw]

No, I'm asking for a mapping. For every codepoint, identify as L/C, U/C, or n/a. Then give me a mapping between each L/C and U/C letter. If there are some cases where this mapping varies by culture, add that to the input. Whatever. But there are already rules in place for this wherever the concept applies - collect them into the standard normatively.

I should not have to be an expert in every human language to write ToUppercase(). Take the rules that every schoolchild knows in each culture and collect them - the Unicode guys collectively know all this stuff, and it's somewhat documented in non-normative appendices and such, but it needs to be part of the standard, which will ensure completeness and accuracy.

BTW, can you give me an example of where the L/C -> U/C mapping varies by culture?

Re:Long term decline

[znrt]

i was referring to the data, actually.

nothing wrong with your summary, except it is based on a popularity contest based on some arbitrary counting of arbitrary google searches. even without checking their measurement method (which is pretty dumb, imho), you should see at first glance that there is something fundamentally wrong with a result of [16.15% java vs 4.84% Visual Basic].

Re:Android is not always Java

[angel'o'sphere]

You are not mixing apples with pears but with stones. Hint: a stone is not fruit.

Google implemented its own VM for Java because they had certain goals they could not achieve with the original concepts/implementations of the Sun JVM. Perhaps you might read about the inception and evolution of the Dalvik VM?

That has noting to do with the language.

On Android obviously Java is a systems programming language. Or why is it used for most system level programming?

The argument was that the current Python implementation wasn't good enough
That is your argument or the argument of an idiot whom you follow. Python simply is not suited for "applications" that interact via interfaces with other applications (like accessing the contacts book and the calendar and sending an automatic birthday greeting text message). Why? Because you can not define typesafe the interfaces in Python to:
-- the address book
-- the calendar
-- the text message system

Python was always mature, that never was the question. It is just unsuited to certain tasks.

Re: Wake me up...

[KiloByte]

The problem lies in UCS-2 and UTF-16. The former can't even represent most of Unicode, the latter includes all worst points of UTF-8 and UCS-4: it's not text, needs complete new APIs, any corruption corrupts the rest of the text rather than just a single character, doesn't allow random access, etc, etc.

Platform constrains language choice

[tepples]

True, I can find another language. But the other language just happens not to have a runtime environment on the target platform, as 0xdeadbeef and I pointed out.

Re:Wake me up...

[thegarbz]

You're assuming it's the user that gives the input. Unsigned values are great in things such as automatic counters which only count in one direction. Gives you twice the space as signed values and you really do only have to check the upper bound and handle the case where it overflows back to zero.

Classic use case: timekeeping in microcontrollers. Admittedly though you won't be using perl or ruby for that.

Unsigned money types; ordinals as cardinals

[tepples]

Cardinal numbers indicate a count of objects: "one, two, three".

Such as a count of each distinct item on an order and a count of cents that the customer paid for each item. For obvious reasons, a negative value would be inconsistent.

Ordinal numbers indicate an order - a position in a sequence: "first, second, third".

Ordinal numbers have two mappings to the cardinal numbers. A "zero-based count" represents an ordinal as the number of items that have already been considered: zero, one, two. A "one-based count" represents an ordinal as the number of items that will have been considered once processing of this item is finished: one, two, three.

Re:Unsigned money types; ordinals as cardinals

[lgw]

Now you're diving into set theory. I'm correcting bad elementary school education with appropriate elementary school education. :p

Re:Android is not always Java

[ed1park]

John Carmack @ID_AA_Carmack 26 Sep

Hardware does get faster more rapidly than software gets slower -- I'm finding Eclipse perfectly usable on modern hardware.

Re:Wake me up...

[RCL]

You may want to hash them for maps or sets, log them out, or even save to disk (the latter might not make sense at first glance, but sometimes it's convenient as it provides an "unique ID" for objects in a saved file, helpful if your data is an arbitrarily connected graph).

Re:Wake me up...

[JAlexoi]

The fact that lack of unsigned integers has not stopped Java shows that the designers made the right choice. If you need to have a value larger than 2bn you will probably not be satisfied with 4bn and will need a larger type. And in general, you rarely need to operate numerically without a sign.

Re:Wake me up...

[JAlexoi]

1: Those bounds checks come at a cost of having overflows getting in the way of actually checking bounds. An overflow of an unsigned value results in just a small number... that means that you still have to check the lower bounds no matter what.
2: They store the same number of values as unsigned, it's just handling of those values and comparison operations differ. A signed and unsigned 32bit integers store 2^32 values.
3: Crypto algorithms do not operate numerically, thus 2147483647 * 100 will yield exactly the same result for uint32 and int32 as much as any crypto algorithm is concerned.
4: Therefore you send 2147483648 in binary form as 4 bytes = 0x80000000

Re:Wake me up...

[JAlexoi]

And what 32 bit integer is not a 32 bit integer in C/C++ or Java?

I've never seen a dearth of Java jobs...

[bessie]

I've been working with Java since 1997, and the greatest part of my work since then has been in Java (was doing lots of Unix kernel work and 2-tier/client-server database style projects before that).

In that entire time, only immediately after the dot-com crash in 2001/2002 and for a year or so after that did I find it difficult to find a job where Java was the main skillset required. It might be highly locale-specific; I live in the San Francisco area, and there are piles of both startups and large multinationals that do Java work (although I *have* noticed startups using more Scala and Groovy lately).

But I haven't ever gotten the feeling from the job market that Java is dying.

- Tim

Re:Long term decline

[buddyglass]

True that. For more questionable data I just searched for "java", "c++", "visual basic", "ruby" and "python" at LinkedIn, limiting the search to within 50 miles of my residence, which is a "moderately" tech heavy medium sized city. Omitted "C" because it generated too many false positives:

Java: 273
C++: 160
Visual Basic: 52
Ruby: 82
Python: 173

For extra fun:

Android: 58
iOS: 67

Re:Wake me up...

[Pseudonym]

Minecraft confirms that it's not dying. Does that count?

Re: Keep it up - you might just invent assembly...

[gbjbaanb]

plain wrong.

I have a compiler that proves it. I'm writing simple code, I have a query that ends in .Single() and the runtime throws an exception, telling me to use First() instead as Linq to entities doesn't support this method.

I understand the difference between first and firstordefault, I know what I'm doing, and I can read the exception text. (caveat: I'm using .net 3.5, It wouldn't surprise me if they've changed it in current versions) I still think its nowhere near as clean a language as C# proponents keep claiming, not any more at least. .NET is the most "well done" if you consider developer happiness using it is the only factor. It is nice, it is easy, but I think all of that is down to the environment, not the language. Try coding C# in notepad to see what I mean.

Re: Keep it up - you might just invent assembly...

[gbjbaanb]

you miss my point - that C# is a bit pants if you don't have VS. No VS = C# becomes just another, reasonably crappy language with loads of "evolved" functionality that occasionally is just nonsense,

Try coding C# in notepad to see what I mean. Not that anyone would,but trying it highlights the language as opposed to the IDE assistance.

Re: Keep it up - you might just invent assembly...

[Xest]

I've worked on a lot of large Java projects using Eclipse and a lot of .NET projects using Visual Studio and you're right there are some features Eclipse has that are nice and Visual Studio doesn't, but that's not without it's problems.

For example, you hint at the fact that Eclipse will automatically rebuild for you, but I've found this feature particularly error prone in that it can sometimes fail to build, and like a jammed printer you have to prat around unjamming it before it will build properly again through no fault of your code (though this was the SpringToolSuite flavour, maybe the vanilla doesn't fail as badly at this). I've also found Eclipse's intellisense to be slow, sometimes too slow to be of any worth if you're a fast typer whereas I've never had that with Visual Studio. Things like code regions are much smarter in Visual Studio, it remembers properly what I have and haven't hid but Eclipse fails at this completely, you can make your document tidy by hiding rarely used regions only to have to do it all again next time you reopen the document. The theory behind Eclipse's plugin setup for supporting different frameworks and languages is nice but it almost never works requiring multiple installs for different flavours of Eclipse. Eclipse of course has a debugger but it's half-arsed compared to Visual Studios too. I think all this highlights the biggest problem I have with Eclipse - even where it does have features over and above Visual Studio they just never work well or properly and that applies to many features that it does share with Visual Studio.

But I think in general this highlights the fundamental difference between Eclipse and Visual Studio, Eclipse does have more features (though Visual Studio also has some Eclipse doesn't have) but it's a clusterfuck of everyone's favourite feature and none of it works well together. In contrast, Visual Studio may lack some of those features but at least the features it does have all work in a responsive and well integrated manner and that's why most developers who have used both prefer Visual Studio - because it's just hassle free, you basically never have to fix projects that the IDE has randomly broken, you don't have to sit waiting around for some interface element to respond, and features "just work". This is also why I prefer NetBeans to Eclipse in many cases - it follows the same philosophy as Visual Studio, less about number of features, more about making sure the features you do have work and that the IDE is fast enough to not be painful to use sometimes. Other Java IDEs like JDeveloper are even better again.

Eclipse would be best on the market if it cleaned up by making sure all features work properly, never break, and made the IDE more responsive in general, but it's had years and failed to achieve any of this - it's just added ever more features without making sure they all work well by themselves and work together with others also.

Re:Android is not always Java

[IamTheRealMike]

I searched that, clicked the first link, clicked download, and on the right hand side is "Community edition: FREE". I'm not sure how much clearer they could make it ...

Re:The Java platform is an engineer’s dream

[Ash-Fox]

It does stuff the CLR can only dream of

Like what?

Re:Wake me up...

[funky_vibes]

What part of Java design isn't braindead?
No, seriously.

Write once, run away

[funky_vibes]

I have for years tried to find a single redeeming aspect about Java. One of those: I know Java sucks but it has great "something".
Truth is, that it sucks, period. All aspects of its design are fundamentally stupid and divorced from reality.
Before Java we had Perl, just as slow and shitty, but a hell of a lot easier to write and run. But I guess it wasn't an ecosystem owned by a big corporation like Sun.

Java is just one of those overhyped corporate languages, still living off the fumes of past glory. Looking at how quickly a only marginally better language like C#/.net took over, it proves how it was more of a fad than anything else.

Re:"dying"

[funky_vibes]

Nope, all of these predictions were made before trends were possible. And now the trends are real.
It's just your expectation of a short timeframe that's wrong.

HTML5 is a less shitty (but still as annoying) replacement for flash.
Just about all computer systems are moving toward Linux. Especially now, when the PC has turned into a phone in most homes.
IT is an area worked many clever people, generating scaringly accurate predictions.

Fact is, Java simply isn't a suitable replacement for programming. And that's why people think it won't last.

Re: Wake me up...

[bucky0]

He was saying you don't have to cast

Re:Wake me up...

[RoboJ1M]

*mumble mumble* ...C# has unsigned integers...

Wait, what, why are you all pouring petrol/gasoline on me!? :'(

Re: Wake me up...

[RoboJ1M]

I also prefer C#, although I've had precious little use for unsigned types.
However, when I *have* needed them (dealing with legacy DLLs, etc) then thank god I had them.

Anyway, we better go hide in the corner before they notice us. >.>!

If you get caught, just strip all the UInt32 statements out of your code and pretend it's Java.

Nobody can tell the difference anyway.

Re:Android is not always Java

[X0563511]

I don't know what to say. I didn't know it existed until it was pointed out, here.

Granted, I did not proceed to the downloads pages. Why would I do that when all other indications are that it's pay-for software? I have zero interests in trials or shareware, which is what you'd expect to see.

Re:Wake me up...

[nitehawk214]

Minecraft confirms that it's not dying. Does that count?

Java or Netcraft?

Re: Wake me up...

[Outtascope]

I would like to embrace and extend your comments, but unfortunately my conscience prevents from doing so.

Re: Wake me up...

[lgw]

I've never seen these problem in practice. UTF-16 is just fine for 2-byte characters - like UTF-8 you can sort and search and whatnot because the multi-unit encodings were done right.

No clue what you're going on about with "not text" "corrupts the rest" "no random access" and so on. I think you've mistaken UTF-16 for something else. UTF-16 and UCS-2 are the same for all valid Unicode codepoints under 0xFFFF. 0xD800-0xDFFF represent multi-unit encodings in UTF-16, and never had any valid meaning in UCS-2.

If what you're wanting is "one slot in the array = one glyph on the screen" that just will never happen - that approach only even makes sense for languages with small "alphabets", but for those languages UTF-32 will work for that. Easier to just accept that a glyph on the screen may be more than one slot in an array - that hardly ever matters in practice, other than the need to detect invalid encodings for security reasons (but most software that deals with text already cleans it up in other ways for security reasons, and this is a simple case).

No, still junk

[rs79]

Watch the Crockford videos. There's at lease 8 hours of stuff you don't know or else you'd never say such silly things.

I blackholed java.com, it was all I could do to keep that damn virus from coming back. Loading it transparently is naughty.

What do I miss? Holy shit, absolutely nothing. And XP stays up for months now. Golly. It's no FreeBSD, but hey anything longer than a day and you were living on borrowed time before.

Same old same old

[__aaqlvv2831]

The argument about languages and side taking is for those with a black and white view of the world. The value of a language is in the context of its purpose. Java has survived so long because it is the right fit for a purpose. The hard to read argument often has nothing to do with the language, it's about programmers who write crap programs. People who don't understand OOs or knowledge of common design patterns are going to stuff it up and there is no shortage of them. That I believe is part of the education process. Go to uni, learn a language and get a brief intro to Objects Orientation and maybe learn the MVC design pattern. Go out and start writing code!!!. The language is just a tool. It's how you design your solution before you start writing code that matters. If you can do that well you don't have to invest in a specific language and get all outraged when someone makes a slight against it or try so hard to tell everyone why your language is much better than theirs. Seen too many people get all bitter because their 'chosen language' has had its moment in the sun. Move with the times, learn new languages and keep doing what I think is one of the most satisfying jobs around.

I blame Java for the healthcare.gov mess

[rkinch]

The failure that is currently healthcare.gov is heavily based on a Java implementation for everything including the most trivial and simple things. I've spent two weeks getting nothing but inglorious errors, and the [mis]use of Java appears to be deeply involved.

It is an astonishing, breathtaking failure when viewed with any expertise in how things should be done. You log in and the screen just turns blank with no error message. Or you get an error message that literally just says "Error!" in red and nothing more. Or it gives an error that indicates what can't be the true cause. Or it says we're too busy ... at 3 a.m. Or try again later (but not how much later). Or a bunch of Java code gets splattered onto the page in literal text. Different errrors in every variety of browser. No evidence of version control or other error tracking. No indication of status, good or bad, no list of active problems, no advice when to expect resolution. There is no documentation or explanation of any of this from the authorities or the contractor. The authorities will not report usage statistics, how many succeeded, or how anyone succeeded if there is a specimen anywhere in the universe to copy. One has to question whether it has worked in a single instance.

Here is an acid-core example: every single user has to confirm via email. Yet the email is flat-out RFC-violating non-compliant, and can't be read in email readers that don't know how to handle this non-conformity. Specifically, this violation appears in the email headers:

Received: from . . . service.govdelivery.com
Content-Type: multipart/alternative;
. . .
Content-Transfer-Encoding: base64

This is not an example of bad Java, but it does show the kind of foolishness passing for system-building everywhere you look. This garbage came from govdelivery.com who are apparently the choke point for the entire system. If they fail, or if you fail to deal with them, you are SUNK.

They do have a pretty girl smiling at you from the home page. Puh-leeze.

These are not bugs or glitches or the overwhelm of success. This thing is utterly defective. A FAILURE. One must question whether it will ever work, and if it won't have to be abandoned for a do-over. Nobody expected a smooth rollout, but this is head-slapping incompetence.

And the law is, you must succeed with it, or ELSE! You cannot mail in forms, or call on the phone, to get this done. It all happens on the Web.

And when has the federal government ever appropriated non-government technology and property in this way, and used it as the sole means to enforce something against the citizenry? With the income tax, they at least give you the paper and a post office to send it back and forth. The government will depend completely on the Internet now to keep you from being fined or put in jail?

Re:Wake me up...

[Urkki]

Maybe your code is different, but have you noticed how many C functions return signed value, where -1 means error? Often same functions take unsigned size in, and then return actual size written/read/whatever. Except the maximum returned size has one bit less for positive values, than the maximum size given as argument. Do you see the problem?

As a result, lot of times an unsigned is used in C, even in standard library, a signed value should be used instead.

Re:Have you seen how much those flying yachts cost

[Hognoxious]

It's pretty unlikely the offspring would be able to randomly throw palm trees so that they'd form into working yacht to sail away from their aquamural prison.

But some chances aren't worth taking. The words "nuke" and "orbit" spring to mind.

Re:Wake me up...

[Hognoxious]

.Netcraft says so.

Re:Java is faster than C++

[RCL]

You are very optimistic. Right now even C++ compilers (which, believe me, are very much performance-oriented and rather are not memory-constrained) have problems with producing a good vectorized code, but thanks God we have assembly intrinsics and use them a lot. For JVM, that is even harder for multiple reasons (and unfortunate - historical - choice of Java bytecode is one of them). Sure, there's a broad class of software where performance does not matter, but as I said again, that is a boring software I don't want to work on. Writing such software is better to be outsourced somewhere where people crave for money more than I do.

As for HFT, I don't think that using Java is a good decision. If you can optimize for certain (best in its class) hardware, why do you need to hop through all the extra abstraction layers of Java? Sure you probably can, but it's like artificially limiting yourself.

Re: Wake me up...

[Hognoxious]

You don't, you use gifs[1]. Can't you read?

[1] png is better, but I doubt you've heard of it.

Re: Wake me up...

[Hognoxious]

Oh come on. I know accents and diactritics are rare in English. But that's exactly why, when used correctly, they add a certain ambiance, a touch of the Belle Époque

You're just being faux naïve

Scala?

[yacc143]

Sorry guys, since when is Scala a scripting language. Anything but?

Re: Keep it up - you might just invent assembly...

[yacc143]

Furthermore, static typing catches many errors during compilation. The sad part is that it does not catch all errors in some categories, which leads to multiple ugly results, the foremost being that developers expect the bugs caught by the compiler, hence don't test for them.

An example would be changing method arguments. Most developers expect the compiler to catch these. Sadly, a huge subset of these are not caught by compilers in most languages, e.g.:

void doit(int x, int y) => void doit(int y, int x);

Now while this sounds trivial, the underlying issue is fundamental (type theoretically spoken, type equivalence by structure), and even a developer knowing about this can be caught, as the typenames for x and y could be different (typedefs come to mind). Actually, C & C++ define a number of opaque datatypes where the developer is not expected to know what's inside. (e.g. FILE in Ansi C, guess most developers would not be able to tell by introspection if some random struct is type equivalent to FILE.)

Now the ugly part is, because unittesting is work (and static-ness does not help, it usually makes it necessary for code to be developed explicitly allowing stubbing out stuff), and because the compiler is meant to catch this category ("argument errors"), you will find that most statically typed projects do not apply the same degree of testing to the code (and especially for issues that the compiler is supposed to handle).

Dynamically typed languages do not promise any of these, hence testing usually includes also these topics that others believe to be checked by their compiler.

Re:The Java platform is an engineer’s dream

[yacc143]

In the artificial benchmark world, yes you can manage to construct cases where a two liner in python can beat a C++ STL program. (Hint: C++ strings are mutable, Python one not. C++ has a strong preference for by-value semantics because it lacks GC. Hence stuff a huge multi-kb const string into a big dict, no matter what, STL map will be slower because it's forced to copy the stupid strings)

In the real world of commercial development, yes, but it's a complete different pattern:
experience shows (in at least one contract I had rather exactly the same situation), that the terser-language guys tend to be quite a bit more productive, hence while the C++ guys are happy to have finished their first iteration, the more productive guys are somewhere in their third iteration, yielding improvements in algorithms, data structures, inner-loops implemented in C, plus generally speaking a way better understanding of the problem space.

Re:Android is not always Java

[bluefoxlucid]

What is "system-level programming"? Is the graphics system written in Java? Of course not; it's C++. SMS application? That's in Java; it's an application. Dialer application? Java, it's an application.

Unless you want to start expanding "System level programming" to include "Web browsers and e-mail applications", Android's system is not in Java.

That is your argument or the argument of an idiot whom you follow.

This was the argument made:

Great idea! Let's implement everything on our phone in an incredibly slow, dynamically typed language, whose only relevant implementation has a GIL and a pathetically bad concurrency model!

I could argue about whether he's flat wrong about Python being slow or having bad concurrency; or I could cite that Google wrote their own JVM.

Why? Because you can not define typesafe the interfaces in Python to:
-- the address book
-- the calendar
-- the text message system

If you try to do this in python:

apple = "apple"
apple = 5

Python throws an error because "apple" is of type "string". Python is strongly typed, but it's dynamically typed: once you define a variable, it gets an unchanging type. Assigning another type to that variable is not allowed.

class AddressBook:
name = str("")
phonenumber = int(0)

Create a class as so and your class is type-strong. Not to mention Python has a robust implementation of C and C++ binding in both directions, so you can bind C++ APIs to Python in a type-safe manner. Still, the Address Book and Calendar and such are likely written in Java, and thus in our thought experiment would be in Python; you would define the classes to carry certain types of data directly in Python, not bind to a back-end C library.

Re:Android is not always Java

[angel'o'sphere]

The android platform is a linux kernel written in C.

On top of that are systems that are necessary to run a phone. And bet those are not all written in C.

I consider interacting with the "platform" like sending an SMS system level programming. And much of that is written in Java. But perhaps you are right and it is more application level programming.

Regarding your python examples, I know that. But how good is it to have such an exception on a running application on a phone instead of a compile time error?

You can describe an interface in Python, but you an not enforce correct usage.

Java IS dead

[candlebar]

Java IS dead... just like rock and roll.

Re:Android is not always Java

[bluefoxlucid]

Ah, so the issue isn't that there isn't strong typing; it's that the compiler for a C or Java app runs through the code and cross-verifies types, while in Python you don't have a static checker. Python's duck-typing makes it difficult to write a static checker, and so you would get only limited success: You'd have to follow each possible branch and determine if a value could get initialized to something else, and raise an error on an absolute yes.

In other words: your argument is that any language with duck typing is inherently wrong for any application that people are expected to use.

Re:Android is not always Java

[angel'o'sphere]

In other words: your argument is that any language with duck typing is inherently wrong for any application that people are expected to use.
No that is not my argument.

My argument was as before: in a static typed language you can define interfaces to other parts of the system. And enforce the correct usage.

In languages like Python you can only describe interfaces (which means you require the human to read carefully) but can not make sure they are used correctly.

That means it is easy to deploy an application on a phone which fails later to runtime errors due to interacting with other apps/services etc.

There are plenty successful examples where duck typed languages where used. I'm fully aware of that.

Re:Android is not always Java

[bluefoxlucid]

Duck-typing is a special type of dynamic typing. It's inherently not static typing.

Re:Android is not always Java

[angel'o'sphere]

Sigh, everyone knows that, so is the rest of your post missing or what is your point? Or well, you are only half right, ofc it is not static, but all dynamic typing systems that use dynamic message dispatch are duck typed. Duck typing is only a lay mans term to use that stupid saying: "does it walk like a duck ... etc."
The only dynamic typing systems that are not "duck typed" are languages like perl.

Re:Android is not always Java

[bluefoxlucid]

Your argument was that static typing is necessary to create a language with restrictions which prevent misuse of interfaces. That means inheritable typing (i.e. class inheritance, where you define and explicitly use a class or its descendents which inherit its interface), but not duck typing (i.e. where you shove something at it, and as long as it reacts in a meaningful and appropriate way to the same way to the same member calls and provides the same attributes and other interfaces then it's correct).

Duck typing is a piece of technical jargon; it's not a lay-term. Duck typing is a term similar to "Floating Point Unit" and dissimilar from "Math coprocessor" (which is still kind of jargony but eh).

In any case, you seem to be arguing that the specific set of code verification afforded by a specific subset of static checking (that being compile-time checking) is required for code quality reasons, without accepting any other form of verification.

To take this down to a risk management level, you're attempting to partially mitigate the risk of improper type usage with standard interfaces (a subset of "bad code" risk) in high-importance applications (SMS application, e-mail application, Contacts, etc.) by using compile-time type checking with a statically typed language. I believe you're over-estimating the risk, as your risk domain is limited to core applications and interfaces which are subject to extra scrutiny including extensive testing and code verification. The resources expended on these applications are high enough that creating and using a static checker and taking up coding practices to enable higher accuracy from the static checker in high-importance code paths would be a reasonable additional expenditure (remember, they did write their own JVM for the Android system), allowing for further mitigation if desired.

These risk considerations are interesting because you can consider the accessibility of Python as a risk: Python is easy to code in, and easy to debug, and easily portable; this could have marketing impacts or code quality impacts (i.e. if code written in Python by equally skilled parties expending equal resources is more likely to have fewer defects than code written in Java, then Python has lower code quality risk; this is a primary argument against C and C++, with many considering these languages magnets for bugs and feeling that similar skill will produce more defect-free Java or C# or Python code than C or C++ code).

As a final note: I can convert most strategic arguments (like the decision between which language to use) into risk evaluation; I can't necessarily evaluate that risk, as it requires expert judgment. The evaluation of Python versus Java would require not only a deep understanding of each language, but also of the use of each language: knowledge of strengths and weaknesses in complex programming tasks equivalent to the tasks undertaken in the target environment are required, as well as practical comparisons of defect rate both for similarly skilled programmers and in general (because i.e. maybe Python produces fewer bugs from decent Python programmers; but maybe there's more Java programmers at a reasonable level, and so most programmers would be Python n00bs that write shitty Python code). Further, mitigation may be possible with additional effort, as I've pointed out with the potential to use and even directly accommodate static checkers; this definitely affects risk.

(I can convert most technical and strategic arguments and decisions into a variety of things--strategic evaluation is something I have a lot of tools for; it helps to examine stuff from every angle you can.)

Re: Wake me up...

[theshowmecanuck]

C not C++
char myChar;
You can argue that this is actually an integer. But under everything, all information is stored as some form of number. So if you really want to be anal or dogmatic or both, you can't any store data type only binary numbers (unless you have a quantum computer I guess).

Re:Wake me up...

[theshowmecanuck]

This is a double edged sword.

Re:Android is not always Java

[angel'o'sphere]

Duck Typing is a relatively new term, mainly coming from the groovy community or lets say it appeared at the time when groovy appeared and raised with it.

Sorry, you seem not to understand what an interface is or what a system description is.

BTW: I wonder which python version or special flags you use that:
      a = "string";
      a = 7334; // error here? ... yields an runtime error? That is not standard behaviour.

Re:Android is not always Java

[bluefoxlucid]

It was a confusing error for me, as I had just learned Python and wondered why it wouldn't accept being given a new value. Turned out I was assigning an Int type from a String type without int() casting. CPython 2.5 on CentOS.

New term still counts as technical jargon. Remember when "Graphics Processing Unit" was a new, groovy layman's term when "video card" and "video chipset" had fallen out of style?

Re: Keep it up - you might just invent assembly...

[DickBreath]

Thank you for your reply. If you look at my message which you replied to, I also said that strong typing enables 'toolability' of the language. I then gave only the most simplistic type of toolability -- intellisense.

Eclipse, which is an IDE for writing code, has lots of toolability features for Java. For example, of your doit( int x, int y) method. In Eclipse, you would click in the word doit before the open paren, right-click, Refactor, Change Method Signature...
(dialog box appears)
The dialog shows a table with all of the method formal arguments. Click a row, such as the row for X, and then click the DOWN button to move that row down below Y, then click OK. Not only will the two arguments X and Y be interchanged in the signature of method doit, but all references in your code will also be changed as well.

This is not done by some simplistic search and replace. Eclipse has a deep understanding of your source code. The editor is deeply integrated with the compiler. Or rather, to put it in simple terms, the Java compiler is a very large library and the compiler command line tool is just a wrapper around the large amount of compiler logic in a library. The Java editor in Eclipse makes extensive use of the library functions in the compiler to deeply understand the source code and have a database about everything in all of your source code in your entire project.

Another example, in a large method, select several lines, refactor, extract method. A dialog appears. You give the new method a name, the dialog tells you what the arguments are, but gives you an opportunity to rename them, then when you click OK, the lines you selected are refactored out into a separate method, and the place where those lines were becomes a function call to that method.

There are many other refactoring tools. This kind of toolability is enabled because the language is statically typed and the editor understands exactly what else in your project is related to what. There is no compile time (or editing time) doubt about what method a particular function call would go to.

In dynamically typed languages, this can be difficult to impossible to do. In languages like, let's say Javascript, it can be impossible. You could have a reference like x["foo"] = bar, which could also have been s="foo"; x[s] = bar. Both of these are equivalent to x.foo = bar. Now if I did some refactoring, such as a rename to change x.foo into x.frob, should you or should you not rewrite other code to say: s="frob"; x[s] = bar? This has a certain similarity to how in C an array reference and pointer could be interchanged and refactoring tools might not recognize subtle tricks.

As to the other part of your reply, static typing promises to catch exactly what it catches. No more, no less. Interchanging arguments is something you do with refactoring tools. Especially in a gigantic program. You never interchange function arguments by hand. Heck, you don't even reverse the then-else conditions of an if statement by hand -- you right click and refactor. The tools will reverse the logical condition in the if condition for you as well as reversing the then-else blocks.

Like all good things, these great tools (eg Eclipse) are free and open source.

Java Is Not Going Away Anytime Soon

[JBrow]

No amount of criticism is going to make Java go away so get over it and stop flaming about Java being _______________. I am going to go out on a limb here and state categorically that each and every programming language has its faults. So your choice is simple: either declare that "the glass is half-fiull" or "the glass is half-empty". IMHO Java is an incredibly fantastic language to use for accomplishing your task at hand. Yes, you need to type a little bit more in Java. Shut up and get to work is what your managers are going to say.

Re:Android is not always Java

[ahabswhale]

Are you retarded? It's on the fucking download page for IDEA. The guy even gave you a link to take you straight there.