Along with promoting an easier multithread API the artical also contain the paragraph:

Project Coin's diamond syntax for constructor calls lets the compiler infer type arguments, and the try-with-resources statement helps the compiler make reliable code by automatically closing files, sockets, and database connections when developers forget to do this, Ratcliff says: "That's something that's been tripping up developers -- especially young developers -- for years. That'll be a good productivity improvement and will reduce bugs."

This is almost like programming language lock in, once you have programed in Java for a few months you are incapable of writing functional C++ code and if you lean to program in java you have no idea why your non java programs fail.

Yes. Let's shun all advances in programming language design, because they make it too hard to use languages without them.

Man, imagine what'd happen if you ever ran into a programming language with a good design. There are some out there that are actually pretty good. Of course, no language is perfect - or even close. But people who resist making things better just because it makes defects in existing languages more obvious is doing themselves, and the entire field of software engineering, a disservice.

Are these really meaningful advances? (If they are then yes i would agree with you)

Though i have no idea what they added to thread module if it was an advancement i would think you could sell it a bit better than it makes things easier. There has got to be a performance hit for "extending" garbage collection to files, sockets, and databases. How hard is it to realise you no longer need a resource and free it.

Sure its fine if you don't need it to be faster than python (or pypy) but changes like these (yes yo

// file is closed here because the compiler has inserted// the right epilogue for you, saving you boilerplate, preventing// you from inserting the wrong boilerplate, and not impacting// the GC in the slightest

Sorry was not clear i meant to imply they were applying the concept of GC to resources other then memory. Java decided you no longer need the resource and frees it. This is simplified situation say you make an object that opens a file (or other resource) but then still need the object without the file then the VM would recognise this and close the file. Its more complex than just SS.

And you raised the issue of what happens if you cant close/save the file, it would be come more complex to handle the only way

Performance hits for closing files is extremely minimal. By far the slowest part of writing a file is the time it takes to transfer it to disks. It is in fact often on the order of a million times slower than any other part. Worrying about the performance hit of a few extra instructions to close a file is silly in that context. There is a law related to this point, but I can't find it right now. It is described under The General Task of Code Optimization [azillionmonkeys.com].

There has got to be a performance hit for "extending" garbage collection to files, sockets, and databases. How hard is it to realise you no longer need a resource and free it.

Garbage collection can take some time to realize that a resource is no longer needed and release it. For memory, it's mostly not a huge problem (and you can tune how often the garbage collector runs) but many other resources come from really rather small pools so releasing them earlier is really important. This is especially so for anything connected to a file descriptor and/or process, such as all those that you list.

Releasing a resource early means doing some kind of close operation on it, and requires th

once you have programed in Java for a few months you are incapable of writing functional C++ code

Having been a Java developer for eleven years now, I still write C++ with few memory leaks and a couple of passes through a debugger usually fixes that. I am not sure why people believe Java makes you a bad programmer. Java, C#, and C++ all follow the same design patterns, they just use different methods on getting there. It is really not that hard to remember, hey in this language the object is GC and in this one it isn't. A singleton design pattern in C++ and Java look exactly alike and function exactly the same. Java you don't have to worry about cleaning the mess up and in C++ you clean it up in the destructor, c'mon some people make it out to be the difference between gutting a fish and brain surgery. It's all syntax sugar, a lot of people need a new argument.

I did not say its currently the case, looking at the article I suggested/said it could be going there. (I do think that some of Javas features unnecessary make it easy for people to write programs that could easily preform better.)

Do you believe, not having to close unlock things makes you a better programmer? or that developer of Java will magically make it so there are no issues like (unnoticeable but cumulative) effects on performance, keeping the file open longer than it needs to be or having to reopen

I don't know about you, but when I walk into a convenience store, I pull the door open and walk in. From there, I don't turn around and pull the door closed behind me because it does that by itself. I don't think that makes me a better or worse shopper, but I think it's one less thing for me to worry about. There are no points awarded in life for having a bigger pile of stuff to worry about.

I don't like your metaphor, you have simplified the issue too far and it hides the numbers needed to compare things to see if the tradeoff is worth it and I never said there is a problem with the part you described.

But to carry it on what happens when you go to another store and the door does not close and something goes wrong (say something gets blown over and you have to pay for it) or when to cover the cost of putting the door they markup your prices. (I assume the door is hypothetical as here the door w

The example was intentionally simple because I'm only pointing out that there's nothing inherently wrong with, as a programmer, letting technology make life a little easier. Certainly we can take the door example or even the real world example of people not closing files/sockets properly in all sorts of directions, but in general, it's OK if things are made easier. Generally, it doesn't turn programmers into simpletons because for every new little nice short cut and helpful feature, there is more and more r

Thus we have scripting languages (for performance CPython or pypy) which is this taken to the extreme.

I said that due to the tone of the article and the quote (i don't know who he is) that making the language easier (rather than simpliler) would make it make it harder to move to another language (others have said this is nothing new) and that it could be intentional.I think i left it up to the reader to decide the extended consequences of this.

Certainly, but in this case, I am a user. The architects at Oracle (hopefully) made sure that the doors close correctly. I don't know that to be a certainty, as I haven't tried Java 7 yet, but you get my point. It doesn't mean that I've devolved into an end-user. It's just that my job was made easier.

At some point, farmers mostly stopped planting fields with the help of a hoe and they hooked up plows to oxen or some other beasts. Then, the tractor was invented, making life even easier. Advance after adva

Do you believe, not having to close unlock things makes you a better programmer?

No and that's not the point of these features. A car can have a manual or automatic transmission. Either one won't prevent the driver from being an ass to me on the road or make them a safer driver overall. Likewise, the features aren't there to make one a better programmer or a programmer who is bad at resource handling suddenly better. The features are there to handle certain cases automatically, cases where we've already had a solution (using finally) but would have preferred it to be less verbose.

I think the design focus should be simpler rather than easy (using the word easy over simple just screams bad deign to me, maybe the article writer just chose the other work). I tried to make it obvious that my one line was based of the paragraph from the articular. I don't think anyone who has much influence has ever wanted GC directly built into C++. It just does not fit to have automatically included in Native Code.

I never said this would make you a bad programmer just that it would be frustrating/diffic

Do you believe, not having to close unlock things makes you a better programmer? or that developer of Java will magically make it so there are no issues like (unnoticeable but cumulative) effects on performance, keeping the file open longer than it needs to be or having to reopen it?

I believe not having bugs makes you a better programmer, and if the language helps enforce that by design, even better. If you're trying to prove yourself by doing things manually that computers are capable of handling for you,

Can you believe these so-called programmers? Always going on about their infernal structured whatsises with their new-fangled compilers and crap! Real men program directly in binary and enter the code with toggle switches. How will the program layout ever be right if you let some so-called "linker" do it? IOf that wasn't bad enough, now they want to ling AT RUN TIME fercristsake!

The problem you describe isn't one of developers being lazy... it's a problem of developers being *stupid*, and failing to learn anything from the languages they've previously programmed in. Every language you use in anger should inform you about viewpoints and techniques for every subsequent language, even if they don't directly apply.

This is why all programmers should start with a language like Pascal, so they learn the basics of structured programming, lexical scoping, and what the hell the difference

Just look at those silly C++ programmers letting the compiler manage the stack for them. Once they've programmed in C++ for a few months, they'll never be able to manually set up call stacks in assembly across multiple operating systems and instruction sets.

As a developer I could care less about Java itself. It's the new Cobol.

It's in an awkward spot. For anything high level I'd rather just use Python. And for the few cases where Python's not fast enough, it's easiest to jump down to C++ and write a module I can call from Python.

The best thing about this new release are JVM improvements for dynamic languages, which should help out projects like Jython, JRuby and Scala.

Java SE 7 is the latest release for Java that contains many new features, enhancements and bug fixes to improve efficiency to develop and run Java programs.

Why is Java SE 7 not yet available on java.com?

The new release of Java is first made available to the developers to ensure no major problems are found before we make it available on the java.com website for end users to download the latest version. If you are

Lambda expressions are not closures, and neither enable parallelization.

I noticed that too. Somehow, in the Java community, closures somehow became connected to lambda expressions. Whether you have a syntax for anonymous functions is completely separate from whether you have closures.

In a reasonably static language like Java, adding closures makes the concept of the "stack" a lot more complex. A closure can contain a binding to a local variable outside the closure. That binding can outlive the scope of that local variable. So local variables now have to be handled in a more general (and slower) way. The semantics of local variables gets a lot more complicated, too.

Perl, Python, and Javascript have closures, although most programmers who use those languages don't know it. In those languages, any nested function can potentially be a closure. (Well, in Perl, there's a warning if you do that.) The Java people don't seem to have taken that route, possibly because they don't want to incur the overhead of a closure unless the programmer really wants one.

I've been playing with C++ again recently and had forgotten how much I really liked the language. I have real destructors again! That, along with oracle's recent abusive behavior toward Android leads me to dance the "Oracle can Blow Me" dance! Here I go! Oracle can blow me! Oracle can blow me! Yeah! Shake it!

Google just needs to re-implement all their shit in C++ and we can get an "Oracle can Blow Me" congo line going. Having a native mode executable build down to 20 *kilobytes* and actually run in 20 kil

20 kB. You clearly are not building applications that are hundreds of thousands of lines with dozens on people working on it. If you were you would be looking at things a little differently (and yes, sure you can do stuff in C++, as I did for a decade, but you are not nearly as productive as you are in Java).

Ah yes. The old "blame the language for the lack of a developer's skills" ploy. It's a sad carpenter who blames his tools for his incompetence. It's a sadder carpenter who blames a tool for other carpenters' incompetence.

Just curious: what do you think all those "Java weenies who couldn't code themselves out of a paper sack" would do if Java died. Would they magically become skilled code gurus because Java doesn't exist? Or would they be incompetent coders in a different language?

Ah yes. The old "blame the language for the lack of a developer's skills" ploy. It's a sad carpenter who blames his tools for his incompetence. It's a sadder carpenter who blames a tool for other carpenters' incompetence.

I can't speak for other workplaces, but there are certain languages that people at my company develop in and you can get a pretty good idea of a programmer's skill level by what language he develops in. Anyone who develops in only one language is very good at that language. S/He can solve any problem you throw at him/her in that one language. There's nothing wrong with that per se, but demand is not constant. Sometimes, they need more people in a different department. If you are a one language programmer, y

If you follow it to it's logical conclusion, the best programmer's flip the machine bits by hand...

Correct: the best programmers can use machine code if needed. But the best programmers also don't abuse the apostrophe as much as you did...

If I found out someone was manipulating code at the machine level - I'd definitely have issues with that. You lose portability and expose yourself to a nearly infinite amount of issues - there really aren't many cases left where this would even be remotely advisable.

If you follow it to it's logical conclusion, the best programmer's flip the machine bits by hand...

Correct: the best programmers can use machine code if needed. But the best programmers also don't abuse the apostrophe as much as you did...

If I found out someone was manipulating code at the machine level - I'd definitely have issues with that. You lose portability and expose yourself to a nearly infinite amount of issues - there really aren't many cases left where this would even be remotely advisable.

Well, that's why I emphasized the "if needed" bit. I suspect that cases where a real need for machine code might arise are probably limited to embedded systems and other single-architecture real-time applications, where a complete re-write (from specs) would be needed for a change in architecture.

there is a difference between understanding how the computer does what it does (and a logical extension of that is knowing how to change it should that be required), and actually attempting to do something via machine code. but you're right, modern day programming is a different beast than old school logic gate manipulation.

Let me get this straight - you think that a harder programming language increases programmer competence. While I'm not defending Java, this logic is deeply flawed.

Glad to know you're here to fix the entire world's education system. Sorry, but YOUR logic is deeply flawed. With your logic, none of the "good schools" are actually any good. So yes, clearly those capable of mastering difficult tasks show they are better in any way.

I'm going to take a wild stab here and say, perhaps you are a Java programmer? And even if you are not, YOUR logic is dubious at best and in no way invalidates the line of thinking which spurred your initial response.

I hope this means they will have basic functions like copy built-in. I was quite surprised when I took up Java on Android that such a function was simply not there. And that I basically had to add it myself (luckily code snippets all over the place, but still). The whole I/O felt very primitive to me - it may have its advantages to do it that way, but me coming from Python is used to being able to address files much easier.

Well it is. It has new asynchronous channel functionality and the FS stuff also allows Java to watch directories, walk through them, examine attributes and other stuff. Java is generally a good language but some stuff particularly Date & Time and IO have been pretty mouldy and long over due a revamp.

While you are busy being a jackass and letting us all know you have never made a single mistake EVER with resource allocation, some of us have work to do and enjoy the fact that we will never have to type try{openFile}catch(DamnException){}finally{try{closeFile}catch(AotherDamnException){}} ever again.

In the 50s and 60s, programmers were skeptical of using a high-level programming language in place of assembly, but the productivity and understandability increase was too great to ignore. Today, using assembly is frowned upon expect in very specific situations. In fact, compilers are generally regarded as being capable of doing a better job than a human could.

The computer exists to do work for you, and that inevitably includes managing its own memory. Automatic memory management in some form is an inevitab

The punchline being that C# has had "using" clauses (try-with-resources) since 1.0 and its compiler type inference (you know, the one it got in 3.0) wipes the floor with that cute diamond syntax thingie.
Sorry for the trollish language, but you know I have a point...

"Write once, run anywhere" was like communism -- an idea that sounds nice in theory in some ways but utterly fails to work in reality.

True, if you hardcode C:\something or/somethingelse in your app. I've never had cross-platform problems, either on big server side applications or trivial desktop ones. So I guess 'utterly failes to work in reality' is somewhat dependent on the developer.

I mean if that doesn't say it all I don't know what does. Hmm Allocate a resource, Free a resource. I think they still teach that in CS-101, then again maybe not. I alloc() therefor I free() ?".

Maybe they do. Doesn't mean it's not a pain in the arse to get right ESPECIALLY in Java since a close() can throw an IOException and ESPECIALLY if you have more than one resource open, e.g. input & output file and you need to ensure both get closed in all normal and extraordinary circumstances.

Arguments for slow Java are so 1990's. Every Java application, desktop or otherwise, I have written has been very snappy, very responsive. Swing has always had places where you can get caught making your own application slow to load or slow to respond. I believe that the community and Sun have really ushered in conventions to mitigate that. SwingWorker (part of core Java Swing), Timing Framework [java.net], JPA (especially our friends at Eclipse), and other community frameworks have really changed the way coders write Java desktop applications in ways that avoid a lot of the pitfalls that came with the 1.1, 1.2 and so on versions of Java.

I think this is the reason why Oracle really needs to embrace the community. It has been because of them that Java has gotten better and faster with each release. People who still talk about how slow Java is and how crappy Swing is, are still living in the past. Is it the perfect platform? No, but it has gotten multiple times better than where it was.

That sounds like EE development and not SE development. If that is the case:
That sounds like a problem with the design. Try using more lock free structures, you can use the java.util.concurrent package to find tools that will help you build these easier in Java 5 and better.

If your are indeed talking SE development, why is your desktop application using millions of objects in memory? I do not think it is wise to juggle that many objects in any desktop platform. Usually, and this is just me, I flush

The problem with Java is that the startup time is poor, which is often ignored by benchmarks.

I can understand this poorly written application usually have very long start up times. Usually if you need to yank in a ton of stuff you can do that at runtime in the background. Dynamic loading.

Compare that to, say, ASP.NET, which if precompiled can launch in a few hundred milliseconds!

You can precompile EE applications as well and have them start up in milliseconds. I think the PHP guys are the ones who came up with this in the first place but then of course I am sure that at some point Xerox came up with the idea first.

There's no good reason for this. Oracle could use a container format that's uncompressed by default, pre-compile, cache, etc...

As far as EE goes you are not required to use WAR or whatever they are ca

So does.NET, except it's not a switch away. Do you think they use the same.NET VM in Windows Server as they do in Windows Home whatever?

I dont know what he thinks, but you are quite clear about what you think and its wrong. The CLR is the same between Server and Home versions of windows. There simply is not differing branches of the CLR because that would defeat its purpose.

I can understand this poorly written application usually have very long start up times.

Nothing to do with code quality, unless you consider "using the standard libraries" poor programming practice!

You can precompile EE applications as well and have them start up in milliseconds.

Maybe, with some containers. I said that. My point is that 90% of Java environments don't or can't do this. It's certainly not the default.

In SE that is being addressed in Java 8

That's my point! Java 7, which is now 16 years old, still doesn't have minor, unimportant features like... fast start time, even though, as you put it, other people have solved the problem decades ago.

Dot NET is snazzy in the fact that the VM is loaded with the OS so you only incur the cost at startup and shutdown

Once Java is launched, you are right. I have a Java program I use on a regular basis, and it is a fine program, which is why I use it, but I hate to launch that thing because it takes forever. Makes me want to rewrite it.

My biggest problem with Java isn't the language, which I have grown to respect, it's the Java programmers. They think they are using Java so they don't have to worry about memory, that things can't leak. No, you still can stick an object in a queue and forget about it. Or register a Swing

n my experience most of Java's performance improvements have had more to do with advances in hardware.

I can tell you that all compilers have advanced in step with hardware improvements. Also, I have easily ran Tomcat 6 and Linux on a Dell OptiPlex GX300. Trust me I have tons of 90's hardware that I am required to make work and enjoy hacking on. I still change DIP switches on ISA cards at my work place.

Even Eclipse is fast unless you weigh it down with plugins. J2SE or J2EE Eclipse with a couple of plugins (e.g. Maven & source control) works perfectly well. IBM's WSAD (Eclipse + a massive amount of crap for websphere / rational / kitchen sink development)... not so much.

Interpreted code does the following: Bytecode is loaded by a native program into an Interpreter. The Interpreter reads the code and sends native code to the machine or to another piece of software that can do such.

JIT code does the following: Bytecode is loaded by a native program into a compiler. The bytecode is compiled into native code. The native code is sent to the machine.

The difference is the following, the bytecode in JIT eventually become

The difference is in the how. JIT gives huge improvements in stuff like loops and basic constructs because these are easily translated into machine code. But for Java bytecodes dealing with OOP constructs (new, for example) this basically means that the JIT has to embed a lot of machine code as an abstraction layer. The improvements there are minimal because this code is doing pretty much the same the JVM would do processing that bytecode on the fly.

One could say the exact same thing about VTables in C++, lookup pointers in C or RT-Code in Objective-C. Which bring me back to my point we could debate this at about the same rate we could debate compiler vs JIT. Machines are state based, OOP is artificial no matter the platform, a CPU is not made to natively understand the concept of an object be it C++, C#, VB, or Java.

At some point a machine will not natively do everything a language requires and thus extra "fluff" will need to be added. That's wh

I love Python, don't get me wrong, but it is nowhere near Java regarding raw performance. Even the developers acknowledge this, with stuff like the Google sponsored Unladen swallow [google.com] and PyPy [pypy.org].

Java's UI is perfectly acceptable for a range of trivial and complex applications. The fact that tools like Netbeans use it should demonstrate that it is no impediment. And if you absolutely need faster performance, or a more native appearance (though Swing is close enough) then SWT could provide that too. Eclipse is built in SWT and is probably the most complex application from a UI standpoint that anyone is ever likely to see.

A bigger issue for Java is that it uses layout models extensively to ensure GU

It won't be jilted in Windows 8. Why you people keep perpetuating this myth? Just because C++ is making a comeback (it was about time) and JavaScript/HTML5 is finding a new home, doesn't mean that we throw away.NET Framework 4.5.

I am not sure why people keep saying this even in the light that Microsoft has said that they are bringing.NET even closer to the core API here. [arstechnica.com]

HTML 5/JS is just being added onto what is already there. The fact that no one has heard about Silverlight has made everyone worried. Microsoft has talked about Silverlight just not to the degree that everyone had hope for. [zdnet.com] So since no one likes waiting until September, we'll just spread rumors and make Microsoft pay for suddenly wanting to do things like Ap

This new Java statement, C#'s blocks and C++'s destructors are all hacks that solve a problem that would not exist in the first place if those languages had lazy evaluation: the code that uses those resources could have been passed as a functor to another function that opened the resources, called the functor and then closed the resources.

It it amazing that in this day and age, language designers ignore language design and compiler basics this much.