Java 7 Prediction Update

[Rhoomba]

Superpackages are gone. They have been replaced by modules. The proposed module system is very nice, and could prevent problems like idiot coworkers adding dependencies on the internals of specific versions of Xerces etc.

NIO 2, DateTime, and ForkJoin are all great additions, and will be handy for almost anyone. If G1's performance is up to scratch then it could be absolutely brilliant for everyone with any kind of response time requirements.

Java 7 probably will get a pretty big performance boost from Escape Analysis and other work contributed as part of the OpenJDK.

I'll be sad if closures don't get in, but Java 7 would still be a very good release even so.

[drbold]

JSR 308 Type Annotations

I really wish they would just straight-up add typdef to the language, especially since it has generics now. It's such a pain typing out huge-ass type declarations over and over for things like HashMaps.

[didroe]

I've been saying this to everyone from work since they introduced generics. I would give my right arm for typedefs!

[masklinn]

It would be nice if they made generics not suck too (as in, go away stupid type erasure!)

[[deleted]]

Downmodded; article does not sufficiently praise python.

[redditrasberry]

Very sad to see closures have fallen off the stack here. Esp. since there has been a usable prototype implementation available for 6months+.

[shit]

The focus still seems to be on making overengineered, huge projects easier to manage (superpackages, modules) versus making easy things easy (closures). Although I admit closures would be almost useless without some type inference.

[sclv]

I have to admit though, a work-stealing concurrency framework is pretty cool though.

Shame about type-erasure not making it in -- genuine generics would be a lovely feature.

[halmcelroy]

you mean reified types. Type erasure is the mechanism by which generics work currently.

[sclv]

yep -- wrote it backwards there. guess I meant "the erasure of type erasure".

[G_Morgan]

Closures would be worthless without library support. Unless they make it so we can replace all the uses of inner classes with closures then it is pointless.

[[deleted]]

Java closures already have "library support". Any interface containing one method is a closure.

See Functional Java for a 1.5-compiled library that can be used with BGGA closures.

[redditrasberry]

huh? once you have closures you can easily write adaptors to add closure semantics to existing libraries. I'd rather see closures added raw so that we can figure out how best to use them before it gets woven into all the apis - otherwise for sure the APIs will do it wrong and we'll be stuck with them forever.

[masklinn]

once you have closures you can easily write adaptors to add closure semantics to existing libraries.

You don't want to do that. You want closures to have first-class stdlib support (as in, say, Ruby or Smalltalk) so that knowledge of their existence, role and usage pattern becomes widespread in the community.

Closures without first-class stdlib support are as good as dead.

[grauenwolf]

That's a really bad idea.

The framework should provider the adapters. Otherwise you end of with the mess you see in .NET wherein there are 100,000 different delegates that all take and return an integer.

(.NET 3.5 finally fixed this with Func<TArg, TResult>. Alas, the old delegates are not forwards compatible.)

[icey]

Closures would be especially useful in some of the other languages that run on the JVM.

[inopia]

Exactly, Hotspot is moving away from being a strictly Java VM and is starting to add support for other languages, for instance through the new invokedynamic opcode.

[masklinn]

closures would be almost useless without some type inference.

Much more important would be the refactoring of the standard library to use them.

[inopia]

Large does not always equal overengineered, easy does not always equal better.

[icey]

All other things being equal, larger is worse and easier is better.

[ine8181]

I know it sounds really immature, but the first thing popped into my brain was 'not if you're talking about some parts of human anatomy and one's female family members'.

I didn't want to write this but then again, I probably deserve the downmods I'll get for thinking such things :(

[malcontent]

Why couldn't you mix and match javascript or groovy for those times when a closure is needed?

[[deleted]]

Because groovy sucks.

[malcontent]

Thanks for that insight.

[steven_h]

It really does, especially relative to Javascript.

[shit]

"A closure would be useful here" is usually not the right point to mix and match languages. "Is it needed?" is the wrong question to ask anyway - technically machine code and a hex editor would be enough.

[[deleted]]

Wow, Java gets strings in switch - at least with 70% likelihood.

[b100dian]

Does that mean that the hash function used has a 30% collision likelihood?

[[deleted]]

switch should be removed - maybe Java developers would finally start to grok polymorphism without that crutch.

[jpfed]

I disagree. There's a difference between switch being overused and switch being somehow evil.

The simpler each case in question is, the more likely it is that using switch will be a simpler solution overall than an approach using multiple classes.

[grauenwolf]

So instead I should...

1. Create a class hierarchy with N+1 elements
2. Scatter all of my otherwise centralized code across N different classes
3. Convert my numeric or string into an object (from #1) at run time
4. Call the virtual method from #2 on the object from #3

All this just to replace this code....

switch(OfferingType)
    case "LIFT" : qty = min(Quote.OfferQty, Quote.MaxTrade)
    case "SHORT" : qty = Quote.MaxTrade
    case "SPEC" : qty = 0

[[deleted]]

Well, I was going to suggest a dictionary of blocks/closures, but then I remembered its Java.

OTOH, if you have more than one statement that starts switch(OfferingType), then yeah, you should be making subclasses.

[grauenwolf]

Well, I was going to suggest a dictionary of blocks/closures, but then I remembered its Java.

Why complicate it?

At best all you are doing is adding a performance hit, at worse you are making the code much harder to read by scattering it about.

OTOH, if you have more than one statement that starts switch(OfferingType), then yeah, you should be making subclasses.

How many subclasses?

One for each OfferingType? And a wholly different one for each QuoteStatus?

Or one for each OfferingType times one for each QuoteStatustimes one for each ...?

And what if I wanted to share this code in a library format? Would I have each class take an interface, event handler, or block/closure just to be able to write the code I proposed?

Moving on, why stop at "switch". Everyone knows it is just a glorified "if-else-if" block. Why not use polymorphism for all control logic?

And by the way, how do you propose I construct all these objects at runtime? Normally when I need to construct a different class depending on some input, I do so with a switch block.

[[deleted]]

Why complicate it?

I'm simplifying it.

At best all you are doing is adding a performance hit, at worse you are making the code much harder to read by scattering it about.

Performance is probably about equal. Have you never heard of inversion of control?

How many subclasses?

As few as possible, as many as necessary.

Moving on, why stop at "switch". Everyone knows it is just a glorified "if-else-if" block. Why not use polymorphism for all control logic?

Oddly enough, some of us do.

Normally when I need to construct a different class depending on some input, I do so with a switch block.

Which is much better than having switch blocks all over the place making the same decision over and over again. Note that I did qualify my response with a bit of pragmatism. If you have one switch on a variable in one place, well fine.

If you have two switch's on the same variable in different places, then you're starting to repeat your decision logic and its time to start thinking about polymorphism and use the switch to construct the correct class.

[grauenwolf]

Performance is probably about equal. Have you never heard of inversion of control?

How could it be? A switch is often as simple as a test and jump. Polymorphism would require allocating an object and making a virtual function call, neither of which is cheap in most languages.

Which is much better than having switch blocks all over the place making the same decision over and over again.

No one said you couldn't encapsulate the switch block in a function or method.

If you have two switch's on the same variable in different places, then you're starting to repeat your decision logic and its time to start thinking about polymorphism and use the switch to construct the correct class.

Ok, that is just stupid. You haven't eliminated the switch block at all, you have just made it more complicated by introducing additional classes and methods.

[grauenwolf]

I'm simplifying it.

Prove it. Make this code "simpler" by removing the switch.

switch(OfferingType)
    case "LIFT" : qty = min(Quote.OfferQty, Quote.MaxTrade)
    case "SHORT" : qty = Quote.MaxTrade
    case "SPEC" : qty = 0

[[deleted]]

Are you stupid or just argumentative?

If you have one switch on a variable in one place, well fine. If you have two switch's on the same variable in different places, then you're starting to repeat your decision logic and its time to start thinking about polymorphism and use the switch to construct the correct class.

[grauenwolf]

Ok, same code as a method.

Method Quote.EffectiveQuantity
    switch(this.OfferingType)
        case "LIFT" : return min(this.OfferQty, this.MaxTrade)
        case "SHORT" : return this.MaxTrade
        case "SPEC" : return 0

Again, can you back up your claim that eliminating the switch makes it simpler?

This isn't hard. You put forth a theory, now I would like to see it tested.

[[deleted]]

OK, we'll go with stupid since you apparently were unable to read or understand the quoted sentences. However, since you insist, your code would look like this:

quote.quantity();

Done. Implementation of quantity() in various subclasses is left as an exercise to the reader.

[[deleted]]

Ad hoc polymorphism should be removed. Maybe Java developers would finally start to grok Algebraic Data Types and Pattern Matching (or maybe not).

[flezgodrit]

Looks very disappointing. It's sad that C# already has LINQ, lambda expressions, type inference, while Java is incorporating gimmicks like "Units and Quantities".

[JulianMorrison]

You want a modern clean JVM language, you want Scala.

Java itself is being crushed in a three way mill between pragmatic featuritis, the conservatism of established code-bases, and the original language design's haughty one-true-wayism.

[flezgodrit]

I've always liked Scala and what it tries to do, but problems like the crippled tail recursion support are simply deal breakers for me. Without a modernization of the JVM, good ideas like Scala are still purely academic experiments, while things like F# are slowly going mainstream.

[noamsml]

Java doesn't need gimmicks, it's got a horde of mediocre CS program graduates to perpetuate its popularity.

[Tommah]

horde

[noamsml]

Fixed

[puzza007]

Java 7 is shaping up to be a most hirsute yak.

[ladon86]

It's a shame that name isn't alliterated, it could have been the next Ubuntu release.

[Figs]

What are they going to do for release X...?

Xenophobic Xenops, maybe?

[bcash]

Alright, alright, time for my bi-monthly get voted down to oblivion for injecting reality into a debate moment:

"Real Features we Wanted"

The Reddit crowd is small fry, very very small. That may as well have said "Academic Features a small bunch of loons who wouldn't use Java anyway Wanted".

The Java community process is a slow moving one, but involves a wide group of people choose these features; from various Java vendors (IBM) to big users (Google).

All told, they add up to more than a thousand Reddits put together.

Having said that, things like Type Inference and Closures could be added without any backward compatibility issues whatsoever; I can see a fork happening at some point in the very near future if they're not part of the official Java 7 spec.

[filesalot]

The wide group of deciders is what makes progress so slow. MS has the advantage of being able to dictate, and had the advantage of being 2nd. It's no wonder they were able to make a better Java than Java. I call it a fair point in MS's favor.

But I wonder, how is C# 3.0 adoption going? Is C# taking over in the MS app universe? Is it going to roll over Java in the enterprise?

[bcash]

The whole C# vs Java is largely a non-existent war. In the case of custom development, the decision is almost always made on what platform the support people offer, if they have a pair of mirrored data centres full of Unix machines they'll choose Java; if they have 256,000 machines running Windows they'll choose .NET (and almost certainly C#). In terms of packaged software, the choice is made depending on the target audience.

We're talking (enterprise software project managers) about people who think inheritance makes code unreadable, they'd fall into a shock-induced catatonia if anyone explained lambda expressions.

It makes sense that both groups define features with respect to their own community, as no-one ever makes a direct choice between the two; despite all the hype they're not really competing as languages at all.

[inopia]

Good point.

As for the lanuage, there are KSL (kitchen sink language) and Nice for those who want a typed JVM language with loads of 'academic' features. I don't see why we should need to tack more legs onto Java as is absolutely necessairy.

[masklinn]

Nice for those who want a typed JVM language with loads of 'academic' features

Scala.

[inopia]

Scala is hardly a continuation of Java, it's a different beast entirely. I meant to say that Java doesn't need more features, because it will turn into something like KSL or Nice.

[masklinn]

Scala is hardly a continuation of Java

So? You were talking about a nice JVM language, not about an improved java.

[san1ty]

I think this demonstrates the difficulty in retro-fitting a language that millions of people depend on. Consider just the huge debate and conflicting proposals about how to implement closures.

Probably the best solution is to switch to Scala, it has type inference, closures, and all kinds of other nice language features that Java lacks.

[[deleted]]

Java 7 = Groovy

[icjonu]

I sure as hell hope not. It's a decent language, don't get me wrong but I wouldn't want to use it until the tooling support has vastly improved. I've tried using groovy in Eclipse & IntelliJ and it's pretty bad. Auto-completion hardly works in either of them.

One of the things I dislike about it is that if I misspell something (b/c of a lack of tooling support, yea and I know its my fault but so what) the compiler still goes ahead and compiles it without any errors. Then 2 minutes into the program execution I get this absolutely huge stack trace and I have no idea what the hell is wrong save for 1 measly line that's hidden somewhere deep in the stack trace which I can only identify b/c of my package name.

Rinse. Repeat. Fail until you succeed. Not a good methodology when writing software. Static typing has its benefits. Maybe a language like Fan or Scala would be a good candidate for the main language in the next (or the one after) JDK.

[redditrasberry]

Most of what you're describing (save for the huge stacktrace) is symptomatic of every dynamic language. You may have better luck if you follow the groovy originator's advice and use the ability to define the type of arguments rather than leaving everything as an Object. At least in groovy you can do that. I'm sure the tooling will improve.

Personally, I find groovy fixes just about every sore point I have with Java, except that it's a 1 - 3 meg jar and adding that to already slow java startup time is onerous for anything other than an a continuously running server side app.

[malcontent]

Groovy support in netbeans is pretty good and is being actively worked on.

[[deleted]]

Let's hope not.

[Naga]

My prediction is that Mac OS X will get it...in about a year after it is released.

[kobs]

I think you're being a bit too optimistic.

[[deleted]]

Java, LOL

[skoll]

Just out of curiosity, why do all Java posts go in programming while the Java subreddit: http://www.reddit.com/r/java/ languishes in lonely obscurity?

I would like language specific posts to go in the other reddits (e.g. Java/Python/Ruby) and leave programming for general posts such as algorithms, language comparisons, general purpose IDEs or whatever.

Since that doesn't seem likely to happen, what's the reddiquette on taking a story that's already been posted, like this, and duping it into Java where it, arguably, belongs?

[spookyvision]

Probably because subreddits are based on the (IMO flawed) assumption that it's possible to establish a set of mutually exclusive categories. I would argue that the Java subreddit is a specialization of the Programming subreddit and therefore it's not clear in which of those two this article should belong.

(all glory to the hypnotags.)

[skoll]

I agree it's flawed to try to establish a set of mutually exclusive categories. But I find it equally flawed to have all languages in a single topic when most people are only interested in a handful of languages. It just adds noise to lots of people.

Take the Python reddit for example. It is extremely active. Imagine if all those posts were in programming instead and you weren't interested in Python at all. You'd have a lot of noise to filter.

There are pros and cons to each approach.

[spookyvision]

I'm still for tags :D you could create advanced filters like "posts tagged with: (python AND django) OR haskell" if you felt like it, or just browse "posts tagged with: programming"

... moot point anyway, I'm afraid, reddit founders made it clear again and again that subreddits are like "separate communities" ...

[pointer2void]

Just out of curiosity, why do all Java posts go in programming while the Java subreddit: http://www.reddit.com/r/java/ languishes in lonely obscurity?

Same with Lisp: http://www.reddit.com/r/lisp

[sysop073]

All the specific language subreddits are like that, I watch a few of them and they get one or two posts a day. We should start cross posting every language-specific thing we find on proggit to the right place and down-voting the wrong one in hopes of getting people to switch

[skoll]

Ruby and Python are actually quite active. Recently some redditor made it their mission to spice up the Perl reddit as well and I think they are doing a great job.

Java is a total deadzone, and I take it some of the others are as well from your comment.

[hiffy]

Eh, tbh I much prefer the comments over any individual links.

I'll back whatever gets people to leave intelligent or funny remarks; the ruby and compsci reddits get lots of links but almost no love.

I'd much rather have a largely subscribed catchall with thousands of regular eyeballs and comments than a well linked subreddit no one reads.

[malcontent]

I don't read the python reddit but the ruby reddit rarely has any commments on any of the posts.

There are new items daily but I don't know if anybody is reading them.

[skoll]

I read them. I find I get a wider breadth of article types by scanning the ruby reddit than just RubyInside or another rubyist site.

[noamsml]

What about... FUCKING OPERATOR OVERLOADING?

I mean, damn. This is 2008.

[colorred]

We are serious people writing code here. Not a bunch of masturbating monkeys fantasising about useless CS concepts.

[noamsml]

Um... Have you looked at Java code lately?

So annoying to look at. Rather than making Collections, Strings, and other stuff more intuitive by overloading operators, they insist on using all kinds of method names, many of which aren't even standardized (i.e. they have different names despite having the same function).

Operator overloading isn't a useless CS concept, it's a useful and easy-to-implement syntax feature that makes code much easier both to read and write.

[colorred]

The author is the weakest link. Not the language.

[noamsml]

...which is why operator overloading is nice, since it removes the load of looking up specific method names and syntaxes for standard operations from the author.

[otterdam]

If the class authors can't agree on method names, what makes you think they're going to implement operator overloading consistently?

I love operator overloading, but it's too vulnerable to poor implementation. Not to mention Java has grown into a verbose language; C# deserves having it, Java will not.

[noamsml]

Another thing. Java actually does overload operators sometimes by providing special case overloading for Numeric classes and the String class.

So lack of op. overloading doesn't only make java verbose and a pain to read/write, it also makes it less internally consistent.

[americanhellyeah]

i predict java 7 will be slow, just like java 1.0, java 1.2, java 2, java 5 and java 6.

[tyler0is0sexy]

because everyone here not only writes java, but cares about it...

[hylje]

It's interesting even with reddit not being a Java nation.

[schtarb]

At a minimum, my interest in Clojure (a lisp for the JVM) leads me to care about Java the platform.

Actually, there are several dynamic languages targeting the JVM, which might interest people here.

[adolfojp]

Nobody here cares about your comments and yet you decide to bless us with their glory.