Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java 7: What's In It For Developers

samzenpus posted more than 3 years ago | from the take-a-look-under-the-hood dept.

Java 338

GMGruman writes "After five years of a torturous political process and now under the new ownership of Oracle, Java SE 7 is finally out (and its initial bugs patched in the Update 1 release). So what does it actually offer? Paul Krill surveys the new capabilities that matter most for Java developers, from dynamic language support to an improved file system."

cancel ×

338 comments

Sorry! There are no comments related to the filter you selected.

Kill it Oracle (-1, Troll)

Anonymous Coward | more than 3 years ago | (#37200804)

Oracle can't kill Java fast enough. Once it's dead we can go back to having actual competent people writing code rather than Java weenies who couldn't code themselves out of a paper sack without a VM to hold their hand.

Re:Kill it Oracle (0)

Anonymous Coward | more than 3 years ago | (#37200840)

You can always tell a language fanboy. He's the one with no computer science degree. He's also a flunkie that needs to attack other languages because of his own inadequacies as a developer and as a person.

Re:Kill it Oracle (-1)

Anonymous Coward | more than 3 years ago | (#37200870)

You can always spot a Java weenie. They get super defensive at any criticism of their shitty language. They're also so poor at being a programmer that their code is still able to leak memory despite the presence of a GC in the language.

Oh and I don't program in C or C++ if that's what you think, weenie boy.

Re:Kill it Oracle (1)

LordLimecat (1103839) | more than 3 years ago | (#37200886)

You can usually spot "likely to be baseless" criticisms on slashdot, even if youre not up to date on the particular topic. Usually they are made by ACs.

Re:Kill it Oracle (0)

mywhitewolf (1923488) | more than 3 years ago | (#37201644)

You can always spot a "over the squabbling" post as it normally sits at the end of a chain of AC's, normally followed by "THIS!" and also someones request to "mod parent up!"

also, mod parent up!

Re:Kill it Oracle (-1)

Anonymous Coward | more than 3 years ago | (#37200902)

So I take it you're a VB6 developer?

Re:Kill it Oracle (-1)

Anonymous Coward | more than 3 years ago | (#37200930)

The last guy who signed an expensive licensing agreement from Oracle to use Java 7 ended up looking like this [clownsong.com] .

Re:Kill it Oracle (0)

slack_justyb (862874) | more than 3 years ago | (#37201292)

Warning goatse link in parent!

Re:Kill it Oracle (0)

Anonymous Coward | more than 3 years ago | (#37201442)

It is not goatse. Totally different guy doing something even more extreme.

Not something new like this [1guy2needles.com] . No butts on this last one

Re:Kill it Oracle (0)

binarylarry (1338699) | more than 3 years ago | (#37201076)

I hate to break it to you asshole, but all languages suck.

Re:Kill it Oracle (1)

secretsquirel (805445) | more than 3 years ago | (#37201528)

except for l0lcode at least :(

Re:Kill it Oracle (4, Insightful)

Anonymous Coward | more than 3 years ago | (#37200948)

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?

As Dilbert so succinctly put it: you're solving the wrong problem!

COBOL -Basic-Apple ][ (-1, Troll)

Anonymous Coward | more than 3 years ago | (#37201136)

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.

You tell'em AC!

I once wrote an operating system in COBOL that was interpreted by Apple Basic. It was slick, man! The Apple ][ would boot up with its prom BASIC interpreter which would load the COBOL interpreter which would then load the OS that was written in COBOL! Man, it was AWESOME! (It is still starting up 'Hello World' which I started in 1984 butt ROCKS!) It PROVED with out a doubt that I was God's gift to CS AND Programming! Jim Gosling has an alter set up to me - he'll deny it, but he does! He prays to me on a daily basis as HIS personal God. I inspired him to write Java. Although, he couldn't achieve my Godliness, he tried with Java.

He is a disappoint, though - he never measured up to Stroustrup. Although, Stroustrup is a disappoint with his bastard child, C++0X or whatever the fuck he calls his demon spawned shit.

I will have to smite him with my COBOLx00xx0xxABCDx0 object oriented parallel quantum multidimensional language for light quantum parallel programming.

I have said and will say, COBOL is the future of CS!

Re:Kill it Oracle (1)

Lord Kano (13027) | more than 3 years ago | (#37201494)

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, you have very good odds of being let go when that happens. If you are competent in many, you can go far.

The hands down best programmer I ever worked with could code in anything from FORTRAN 77 through .NET and his code was always amazing. But, that's one out of hundreds.

LK

Re:Kill it Oracle (2, Insightful)

Afforess (1310263) | more than 3 years ago | (#37201128)

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.

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

Re:Kill it Oracle (3, Funny)

Rik Rohl (1399705) | more than 3 years ago | (#37201194)

Obligatory xkcd [xkcd.com]

Re:Kill it Oracle (2)

AliasMarlowe (1042386) | more than 3 years ago | (#37201216)

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...

Re:Kill it Oracle (2)

Afforess (1310263) | more than 3 years ago | (#37201432)

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.

PS. Nitpicking grammar - that's nearly as bad as using machine code directly. :p

Re:Kill it Oracle (1)

AliasMarlowe (1042386) | more than 3 years ago | (#37201624)

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.

PS. Nitpicking grammar - that's nearly as bad as using machine code directly. :p

Hmm... now was I picking at a grammar nit or a spelling nit? Or were you suggesting that grammar related to a disgusting [wikipedia.org] activity is nearly equivalent to direct use of machine laguage?

Re:Kill it Oracle (1)

mywhitewolf (1923488) | more than 3 years ago | (#37201706)

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.

A language with a file system? (-1)

John Hasler (414242) | more than 3 years ago | (#37200810)

WTF?

Re:A language with a file system? (2, Informative)

pauljlucas (529435) | more than 3 years ago | (#37200896)

I assume the author meant, "... to improved file system access." See here [oracle.com] .

Re:A language with a file system? (1)

Joce640k (829181) | more than 3 years ago | (#37201700)

Why are you both confused/assuming? Too busy to read the article?

Re:A language with a file system? (0)

LordLimecat (1103839) | more than 3 years ago | (#37200904)

Not being a programmer, I would guess that it has something to do with Java running on a VM, and needing some way to interact in a universal manner with the host OS's FS.

Any Java whizzes want to comment?

Re:A language with a file system? (-1)

Anonymous Coward | more than 3 years ago | (#37200908)

It is a poorly written article. What he means is that Java has a new version of the File APIs which is meant to make working with files easier and faster.

Re:A language with a file system? (5, Informative)

iggymanz (596061) | more than 3 years ago | (#37200946)

It's just improvements to the I/O API. Java has the New IO API for doing I/O. java 7 has extended it, hence NIO2. http://www.ibm.com/developerworks/java/library/j-nio2-1/?ca=drs- [ibm.com]

Re:A language with a file system? (0)

Anonymous Coward | more than 3 years ago | (#37200972)

The improved file system API isn't even really about I/O, it's about a better API for querying file system metadata more or less.

Re:A language with a file system? (-1, Troll)

whiteboy86 (1930018) | more than 3 years ago | (#37200998)

Bullshit feature or not, it is another cherry on Oracle's fooled execs' lunch pie.

Re:A language with a file system? (1)

Anonymous Coward | more than 3 years ago | (#37201014)

I don't know what you were voted up for, but it is kind of obvious that it means "an improved file system API".

Re:A language with a file system? (1)

mywhitewolf (1923488) | more than 3 years ago | (#37201714)

It's really not that obvious in the summary.

Re:A language with a file system? (2)

NotBorg (829820) | more than 3 years ago | (#37201872)

Thats why the summary links to an article. You must be new here.... oh wait... You'll fit in great here. Carry on.

all i do (0)

Anonymous Coward | more than 3 years ago | (#37200874)

is think about you.

you made my soul a burning fire
you're getting to be my JavaOne desire
you're getting to be all that matters to me

Re:all i do (2)

iggymanz (596061) | more than 3 years ago | (#37201138)

Well since JDK downloaded, ant XML in my head,

jars, wars, and .class files all night with laptop by my bed,

well java you look so fine (look so fine)

for C++ errors took all my time,

for you to help me java

get Stroustrup outta my heart.

help me java, help help me java

help me java, help help me java
.........

help me java, yeah, get him outta my heart.

Bjarne was gonna be my god,

and we gonna be his bitches,

preprocessor bloat came between us,

patterns ruined by the glitches

The answer is... (0)

Anonymous Coward | more than 3 years ago | (#37200932)

A: Not much that is interesting given the number of comments?

One day we will be done with java... (0, Flamebait)

FlyingGuy (989135) | more than 3 years ago | (#37201042)

But not soon enough. FTFA...

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."

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() ?".

Re:One day we will be done with java... (5, Insightful)

Anonymous Coward | more than 3 years ago | (#37201124)

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.

Re:One day we will be done with java... (0)

PerformanceDude (1798324) | more than 3 years ago | (#37201224)

Please mod this reply up! Despite the slightly offensive language, it is NOT a troll statement. That new construct certainly has the potential to eliminate basic mistakes, which invariably will lead to more stable code. It is almost like a garbage collection for resources - and the value of that is (in my opinion) beyond dispute.

Re:One day we will be done with java... (1)

Anonymous Coward | more than 3 years ago | (#37201336)

Ruby showed the value of this technique as well. The Java haters live in ignorance. Java is frequently used to solve difficult integration problems that require the use of diverse resources; database sessions, networks connections, file system resources, etc. Simplifying the code necessary to do this while reducing the chances for leaks is a genuine improvement.

Re:One day we will be done with java... (1)

Anonymous Coward | more than 3 years ago | (#37201930)

So, it's basically like C++'s ancient RAII...

You know what? Bjarne Stroustrup was right: The more useful Java becomes, the more it approaches what C++ already provides.

Java is Great (0)

Anonymous Coward | more than 3 years ago | (#37201050)

Java is great. The new release proves that Sun lives on inside Oracle.

The new version is a little faster from what I can tell especially file IO as a few have stated. It did even matter that much people just wanted to see that Java was still alive and it is.

Re:Java is Great (1)

Anonymous Coward | more than 3 years ago | (#37201914)

You forgot "once upon a time" and "they all lived happily ever after."

Improvements (0)

FirefallPro (1517211) | more than 3 years ago | (#37201062)

Does this mean Java got any faster or a better UI toolkit?

Re:Improvements (4, Interesting)

slack_justyb (862874) | more than 3 years ago | (#37201282)

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.

Re:Improvements (0)

Anonymous Coward | more than 3 years ago | (#37201476)

Wait, you're using the monster known as Eclipse as an example of speed or UI improvements? Is GIMP a 1990's relic than? Most people aren't using Java software in their user facing day to day lives (Andriod comes close if you could even call it Java still). I could lay claim that some simple VB app was fast, but that hardly applies to comprehensive and cohesive applications.

Re:Improvements (0)

Anonymous Coward | more than 3 years ago | (#37201824)

Wait, you're using the monster known as Eclipse as an example of speed or UI improvements?

His point was even more misguided than you're making it out to be. He wasn't mentioning Eclipse, he was mentioning JPA. One of the main implementations of JPA is called Eclipselink and is maintained as an Eclipse-hosted project. But the bulk of the development work for it was done by Oracle when it was called Toplink. Still, it has little to nothing to do with desktop application development since it's an ORM solution for interfacing with a relational database.

However he could have mentioned SWT as an example of how Java desktop applications can be fast. SWT is not the reason Eclipse is slow. Eclipse is slow because of the component architecture and the fact that basically the entire app is OSGi bundles. Applications that use SWT outside of the Eclipse RCP framework can definitely be fast. It does this by basically delegating everything to native code that uses the actual widget toolkits on each platform. So, unlike Swing, SWT apps are actually native Win32 widgets in Windows, Cocoa widgets on a Mac and GTK widgets in Linux. There's very little overhead.

Re:Improvements (1)

Joce640k (829181) | more than 3 years ago | (#37201712)

Arguments for slow Java are so 1990's.

Nope, still as relevant as ever. Java simply doesn't scale. Try running your microbenchmarks with a million objects in memory...

Re:Improvements (1)

slack_justyb (862874) | more than 3 years ago | (#37201956)

Java simply doesn't scale. Try running your microbenchmarks with a million objects in memory...

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 objects out of memory and to disk, network host, database file, or something other than memory once I hit over more than I could keep in my head. Pagination designs help smooth this out for users and using task workers keeps everything moving smoothly. For the curious the pagination design pattern in Java SE looks exactly the same using the QT toolkit (if you use that toolkit.)

I don't know your situation and I won't pretend that I do, but in most cases I find it is the developer just assumed Java would do this or they are still following an old convention that doesn't work well with today's JVM. Either way, EE or SE, if you are dealing with millions of objects in memory, there are ways of moving that data around to keep space on the stack for responsiveness in your application. Just having a million objects in memory just because is not a good idea.

Just curious what use case do you have that requires you to have that many objects in system memory at once? Are we talking simple objects or pretty complex ones?

Re:Improvements (3, Informative)

Lisandro (799651) | more than 3 years ago | (#37201742)

To be fair here compared to other interpreted languages Java is still the king of the hill. By far.

Disclaimer: Yes, interpreted. Bytecode is interpreted, even with stuff like JIT.

Devs can now be more lazy (1)

nzac (1822298) | more than 3 years ago | (#37201066)

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.

Re:Devs can now be more lazy (5, Insightful)

ApplicativeJones (1579281) | more than 3 years ago | (#37201188)

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.

Re:Devs can now be more lazy (1)

nzac (1822298) | more than 3 years ago | (#37201606)

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 you could pretended they don't exist and then it may not matter) were to accumulate it could hurt the language rather than make it better. Assuming that Java programs do run (insignificantly) slower, it makes C++ and its dev's all that more important.

Re:Devs can now be more lazy (1)

The Dawn Of Time (2115350) | more than 3 years ago | (#37201676)

In your first sentence you explain you have no idea what you're talking about, then you proceed to spout off in the remainder of your post anyway. You're pretty clearly the voice of inexperience. You should learn to lurk more and talk less.

Re:Devs can now be more lazy (1)

Joce640k (829181) | more than 3 years ago | (#37201724)

Are these really meaningful advances?

Making it easier for people to close files? I'd say that was an advance.

At least somebody is finally admitting that garbage collection causes as many problems as it solves.

Re:Devs can now be more lazy (1)

ApplicativeJones (1579281) | more than 3 years ago | (#37201894)

Let me just make one suggestion: Learn another programming language. Learn something fundamentally different. Learn it thoroughly. Then decide if there have been advances made in the design of programming languages since C++.

I'd recommend Haskell, myself. It's the furthest you'll get from the mainstream, while still having incredible support for writing real software. But if you learn it, make sure to learn it thoroughly.

Understand what the IO type really is. Not how it's implemented, that's boring. Not what type classes it implements, that's still relatively boring. Understand the consequences of it being a higher-kinded type that describes IO operations as a first-class type. Understand what a type like "IO (IO (), IO ())" means, and why IO is far more interesting than just a tag on impure functions. Understand what a type like "FilePath -> IOMode -> (Handle -> IO r) -> IO r" means, and how it's related to the original point here.

And that's just scratching the surface. Is Haskell perfect? Far from it. Very far from it, in fact. But there are a lot of things it does better than any other language you can build real software with. It's worth learning what those things are. Once you see that there are fundamentally better ways, you might begin to welcome advances to mainstream languages.

Re:Devs can now be more lazy (3, Interesting)

slack_justyb (862874) | more than 3 years ago | (#37201356)

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.

Re:Devs can now be more lazy (1)

nzac (1822298) | more than 3 years ago | (#37201444)

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 it?

Re:Devs can now be more lazy (1)

dummondwhu (225225) | more than 3 years ago | (#37201558)

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.

Re:Devs can now be more lazy (0)

Anonymous Coward | more than 3 years ago | (#37201634)

shoppers are fine with that but architects have to make sure that said door does close.
be careful not do degenerate from a programmer into a user.

Re:Devs can now be more lazy (1)

dummondwhu (225225) | more than 3 years ago | (#37201774)

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 advance after advance, and no one would think to say a farmer today is less capable. Sure, he could do his job with hand tools. But how many people would he be able to feed that way?

Re:Devs can now be more lazy (1)

nzac (1822298) | more than 3 years ago | (#37201734)

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 would both open and close for me.)

Re:Devs can now be more lazy (1)

dummondwhu (225225) | more than 3 years ago | (#37201822)

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 room to do bigger and better things without being encumbered by so much of the small stuff (especially forgetting the small stuff here and there and spending an inordinate amount of time trying to figure out what went wrong).

Re:Devs can now be more lazy (1)

nzac (1822298) | more than 3 years ago | (#37201912)

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.

Re:Devs can now be more lazy (2)

slack_justyb (862874) | more than 3 years ago | (#37201690)

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.

Likewise, GC has been a favorite subject of C++. Should we have GC in the core of C++ or not? There is always a third party library that can add GC to your C++ project. Does using that library make you a bad coder?

Making your job easier is not equal to making you a bad coder. A bad coder *is* no matter the language, platform, or libraries used. When I develop applications that need to talk to a DB, I have to think about when I need to let that connection go, it doesn't matter if I am using Java or C++ or Python, when to let go of a connection is part of the design, not the language. The language part only dictates how many lines of code it will take to let the connection go, not when. If you are not thinking about how you handle resources it is not a problem of the platform so much as it is the design phase. Even in GC environments you have to keep track of what is happening to your resources, you just keep track of them in a different manner.

As a rough example: I open a file in Java or C++, I still have to think about how that file will be used and when I need to close it (no other option in C++) or just let it close by itself (an option in Java but not usually the best one.) If we are talking about a text file that only the current running application is going to use then yeah let it close by itself in Java and close the file in the destructor of the main delegate (or whatever you may have used to open the file) in C++. Both of those options function the exact same way, the file doesn't close until the application does. It's just syntax sugar that separates them, either way I've got to remember that I have a file open.

I did not say its currently the case, looking at the article I suggested/said it could be going there.

That's been an argument for decades for everything. Again, making something easy does not make a bad programmer. Bad programmers tend to not think things out fully and giving them a manual or automatic isn't going to change that.

Re:Devs can now be more lazy (1)

Joce640k (829181) | more than 3 years ago | (#37201748)

Java you don't have to worry about cleaning the mess up and in C++ you clean it up in the destructor

If you're doing it right C++ needs very few destructors and memory leaks only happen once every blue moon.

Re:Devs can now be more lazy (1)

sjames (1099) | more than 3 years ago | (#37201636)

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!

Now GET OFF MY LAWN!

Re:Devs can now be more lazy (1)

tsotha (720379) | more than 3 years ago | (#37201790)

After using java for a decade or so I can't go back to C++. It would be hard to program anything after gouging my eyes out.

I think I speak for many when I say... (1)

mattcsn (1592281) | more than 3 years ago | (#37201090)

...please don't let all these fancy tech buzzwords stop Minecraft from working.

Re:I think I speak for many when I say... (0)

Anonymous Coward | more than 3 years ago | (#37201666)

...please don't let all these fancy tech buzzwords stop Minecraft from working.

Well... in a way I guess you DO speak for many. The jest you're making has a lot of truth. It definitely appeals to the anti-intellectual instant-gratification sentiment that's so damned common. They just want their shiny. They'd never voluntarily learn anything about how their shiny works. All that looking beneath the surface kind of shit would be too much work.

Compatible with Andriod SDK (1)

Billly Gates (198444) | more than 3 years ago | (#37201142)

How compatible is Java 7 with Java 6? Can I run the Andriod emulators? Is it more secure than java 6? I would like to use Chrome but it always runs Java by default and I got owned a month ago from this exploit. I hate using IE as it is the only browser I can disable Java from

Re:Compatible with Andriod SDK (0)

Anonymous Coward | more than 3 years ago | (#37201304)

I'm confused. Just go to about:plugins in Chrome and click disable.

Also I'm certain there was a way to do it in Firefox aswell.

SELL !! AAPL !! SELL NOW OR LOSE IT ALL !! (-1)

Anonymous Coward | more than 3 years ago | (#37201152)

It's heading for the tank, then it's headed for the bottom. MSFT !! Move Over !! AAPL Is Coming Down !!

Three Days of the Condor !! Oh, wait, Three Days of the Candor !!

What's in It for Developers? (1)

microphage (2429016) | more than 3 years ago | (#37201244)

Well going by previous statements by Larry Ellison and Oracles actions in regards to Red Hat Linux. They'll wait until your stuff is popular and then just take it and start charging support fees for your stuff.

"If an open source product gets good enough, we'll simply take it" link [computerworld.com]

"Java 7: What's In It For Developers" (0, Flamebait)

jordan_robot (1830144) | more than 3 years ago | (#37201272)

A bag of hurt.

Re:"Java 7: What's In It For Developers" (1)

mrmeval (662166) | more than 3 years ago | (#37201596)

Can we get it reviewed by someone who isn't a fanboi and butt licker?

Re:"Java 7: What's In It For Developers" (1)

phantomfive (622387) | more than 3 years ago | (#37201922)

Yeah. Basically it's this:

There were a number of proposals for how to improve Java. Some of them were controversial. The controversial ones got moved out to Java 8, and the ones that everyone agreed on made it in to Java 7.

In essence, this is a good, solid, incremental update.

My idea of a perfect programming language is somewhat different, but I can respect this as a solid improvement.

Poor Ol' .NET Dev--A Pity Party Next To Java 7 (0)

curmudgeon99 (1040054) | more than 3 years ago | (#37201284)

People, People, calm down, put a lid on it.

Look at yourselves... having a big jolly party. There are already so many fantastic features in Java--we're jaded in our big happy family. So many open-source offerings court the Java developer, we forget that we could be going back to Ol' Mamma Redmond night after night. Horrors!

Look at the poor, pathetic .NET developers. Unloved by Microsoft. Uneaten dogfood. Jilted in Windows 8. Told that .NET experience on a resume is a black mark with startups. They need an intervention.

Gentlemen and Lady, how can you Java Developers be so insensitive? .NET developers are weeping. A decade of hard-won knowledge lost and back with that FoxPro DBA textbook. They lay down with the Evil Empire and woke up with fleas. Go figure!

Re:Poor Ol' .NET Dev--A Pity Party Next To Java 7 (1)

Kensai7 (1005287) | more than 3 years ago | (#37201382)

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.

Re:Poor Ol' .NET Dev--A Pity Party Next To Java 7 (0)

Anonymous Coward | more than 3 years ago | (#37201470)

Why you people keep perpetuating this myth?

Schadenfreude mebbe?

Scam the scammers, FUD the Fudders. Life is sweet.

Re:Poor Ol' .NET Dev--A Pity Party Next To Java 7 (1)

slack_justyb (862874) | more than 3 years ago | (#37201764)

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 Apple and keep quiet.

Re:Poor Ol' .NET Dev--A Pity Party Next To Java 7 (1)

Anonymous Coward | more than 3 years ago | (#37201520)

You need serious attention of a psychotherapist. Hurry!

Re:Poor Ol' .NET Dev--A Pity Party Next To Java 7 (0)

Anonymous Coward | more than 3 years ago | (#37201570)

This pathetic's own home page is developed using .NET (not that .NET has problem)

http://www.allegient.com/Pages/solutions.aspx

Do these developers include Android developers? (1)

bogaboga (793279) | more than 3 years ago | (#37201306)

"...Paul Krill surveys the new capabilities that matter most for Java developers..."

Do these developers include Android developers? Well, that's the question. After all, Java code will run on Android's Dalvik VM without modification, right?

Re:Do these developers include Android developers? (1)

renrutal (872592) | more than 3 years ago | (#37201366)

Since current Java SE code isn't expected to run and have the very same behavior in Android without modification in previous versions, I don't think it the current version would be any different. BTW, are Android developers considered to be Java developers by Oracle?

What Java really needs (0)

Anonymous Coward | more than 3 years ago | (#37201320)

1. C#'s 'using' block so I don't have to use try/finally everywhere.
2. C#'s 'out' and 'ref' parameters so I don't have to allocate memory to return more than one value from a function.
3. C#'s 'struct' for "pass by value" data structures, or at least strong typedefs, so that a variable of type "typedef int A" cannot be implicitly converted to "int" or "typedef int B".

But honestly, I'd settle for a C# cross-compiler that targets the JVM.

p.s. Why oh why did I start a year-long game development project in Java? The hoops I have to jump through to get half-way acceptable performance are maddening. Someone please kill me.

Re:What Java really needs (0)

Anonymous Coward | more than 3 years ago | (#37201610)

As someone who develops daily in both Java and C# (and Scala, C++, sometimes Smalltalk), I agree with #1 and #3. I write games and graphical or database intensive apps all the time. Regarding games, I would never use anything but C++ (maybe now C++0x), it's just a painful fact that most people aren't willing to accept.

#2 though, I am not sure you need this. As far as memory, if you learn how the GC works, things tend to work out just fine if you are returning objects from a function call. Smalltalk doesn't have either and it's in many ways the most practical and pure OO implementation out there. IMO, "out" and "ref" are symptoms of bad design. I rarely need them except when calling APIs (DirectX) that use them and with P/Invoke or COM programming. They're nice to have, but I find most bad programmers abuse the hell out of them. Most functions should do 1 and only 1 thing. Keeping things atomic is better all around for writing stable, maintainable, and multi-threaded/parallel code. "ref" and "out" lead to huge messes and are crutches for a lot of people who cut their teeth on C++ but haven't learned much. I was raised on C and ASM and later C++, but I certainly don't feel the need for either very often. I can see your need if you're constantly running out of memory, but I think you're likely wishing for something that will create more problems than it solves. There are better ways of optimizing memory.

Re:What Java really needs (1)

Homburg (213427) | more than 3 years ago | (#37201640)

1. C#'s 'using' block so I don't have to use try/finally everywhere.

That's in Java 7, in the form of the try-with-resources statement [oracle.com] .

Meh. (1)

jlarocco (851450) | more than 3 years ago | (#37201396)

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.

Re:Meh. (1)

RightSaidFred99 (874576) | more than 3 years ago | (#37201928)

Python is still a scripting language and has all the baggage that comes along with such for larger programs. Let me guess - you come from a system admin background?

Here's a reason why it is not on http://java.com. (1)

antdude (79039) | more than 3 years ago | (#37201480)

http://www.java.com/en/download/faq/java7.xml [java.com] -- "Why is Java SE 7 not yet available on java.com?

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 interested in trying Java SE 7 it can be downloaded from Oracle.com..."

It sounds like even Oracle, itself, doesn't think Java 7 is ready for the public!

Re:Here's a reason why it is not on http://java.co (1)

MischaNix (2163648) | more than 3 years ago | (#37201622)

I believe this is actually because the JVM for 7 hasn't made it to the Mac yet.

Re:Here's a reason why it is not on http://java.co (2)

Lisandro (799651) | more than 3 years ago | (#37201770)

It sounds like even Oracle, itself, doesn't think Java 7 is ready for the public!

And they are right [slashdot.org] indeed...

Re:Here's a reason why it is not on http://java.co (1)

antdude (79039) | more than 3 years ago | (#37201892)

If it is that bad, then don't release it!

Did update #1 even fix it?

Re:Here's a reason why it is not on http://java.co (1)

Lisandro (799651) | more than 3 years ago | (#37201906)

AFAIK it is planned to be fixed on update 2. Which is kinda retarded - even for Oracle standards.

Re:Here's a reason why it is not on http://java.co (1)

antdude (79039) | more than 3 years ago | (#37201936)

Wow, that is seriously messed up if it is true. I will stick with the older stable version (v6u27) that just got an update last week. ;)

Riddled with errors (3, Insightful)

Samantha Wright (1324923) | more than 3 years ago | (#37201504)

Among the delayed capabilities are adding Lambda expressions, or "closures," to Java for multicore programming, ...

Lambda expressions are not closures, and neither enable parallelization. Yes, the Wikipedia articles for both are dense swamps, but couldn't you have at least tried to ask someone? Please?

Re:Riddled with errors (1)

MischaNix (2163648) | more than 3 years ago | (#37201642)

I know better than to dare read the actual articles nowadays. It's never anything but disappointment.

Re:Riddled with errors (3, Insightful)

Animats (122034) | more than 3 years ago | (#37201776)

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.

Re:Riddled with errors (0)

Anonymous Coward | more than 3 years ago | (#37201838)

Java 6 (and before) does have closures with "bindings" to local variables. They are done using anonymous classes. Most Java programmers routinely use them (listeners) without even knowing they are closures. The syntax is a bit verbose but much clearer than the proposed lambda expressions for Java.

Scala is static, not dynamic (0)

Anonymous Coward | more than 3 years ago | (#37201674)

Just to correct the article: Scala is not a dynamically typed language. It uses type inference (at compile time) to create a highly expressive language which still benefits from static typing.

What's In It For Developers (0)

codepunk (167897) | more than 3 years ago | (#37201682)

What's In It For Developers? Lawsuit

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?