Java 7
Alex Miller - Java 7
The above link describes several possible features of the new Java 7 platform coming out God knows when. There are a great many ideas out there, and I feel it necessary to comment on some of these. Starting at the top.
JSR 294 Improved Modularity Support (superpackages)
I think something like this is always a good thing. I don't know how it's going to be implemented, but it seems like it's going to be part of the JAR manifest. Neat idea.
JSR 277 Java Module System
Anything to aid deployment of a Java application is a good thing in my book. (I should probably read up on Web Start.)
Java Kernel
It's still on this page, and it doesn't need to be. I laugh.
JSR 203 NIO2
I've wanted to write my own Java Zip utility (including TAR functionality) in 100% Java, and it's not easy to do that without access to file attributes. I'm a little leery about escaping to filesystem-specific APIs, as that breaks run-anywhere paradigm. But everything else seems good.
JSR 310 Date and Time API
I don't really get this one. While the idea of describing date without time and time without date and having well-defined types for units of hours and such is interesting, it doesn't seem useful enough to justify yet another time system. Maybe it's useful for intervals and durations. I don't get it. Maybe it's just too early to tell and they just haven't finished it yet.
JSR 275 Units and Quantities
This one's really interesting. This can make a lot of scientific programs easier to create. I made a system to describe prescriptions and did something like this, but this might make things easier. I'd like to know how precise the conversions would be. If they can support BigDecimal as well as double, that would be a good thing.
JSR 107 JCache API
Seems OK to me.
JSR 166 Concurrency Utilities
I'm always in support for improving something that's already good and useful to make it even more useful. There's probably going to be new queue concepts and implementations going in there for a while so that every useful possibility is allowed. Plus, I think this would support multi-processors better, too.
JSR 225 XQuery API for Java
XML good.
JSR 284 Resource Consumption Management API
It's got to be useful for someone.
Miscellaneous Library Changes
Huh?
JSR 296 Swing Application Framework
Yay! Now if we can get everyone passed this misconception that Java is slow.
JSR 295 Beans Binding, JSR 303 Beans Validation
I don't know enough about Beans, but I probably should.
Java Media Components
About time!
JSR 255 JMX 2.0, JSR 262 Web Services Connector for JMX
It's enterprise something or other. I dunno.
JSR 260 Javadoc Technology Update
I think it's a good thing... I don't know though.
Reified Generics
I don't think I like the idea of making code not compatible with older modules running in a newer JVM, especially if it's something in the language that would cause this incompatibility.
Type Literals
Yes. Why isn't it? Well, it's implementation class "Class" is generified... If it's not done, maybe they think it's overkill. I don't think it is.
JSR 308 Annotations on Java Types
This is a really interesting idea. I like it.
Type inference
This seems to be a way to support lazy programming. I don't like lazy programming.
Closures
I do not like this idea. You're creating a completely new programming paradigm within a well established language. I'm not sold on the idea. The problem isn't well defined, and the solution is even less so. It seems that it's a bunch of people who like their old language and want to turn Java into it.
Automatic Resource Block Management
Anything to improve resource management in the JVM is good. Not saying it's bad, but if there's room for improvement, it should be filled.
Language level XML support
Bad idea. It's introducing another language into Java. I hate that paradigm. I have to deal with Objective C enough, I don't want two syntaxes in one language.
JavaBean property support
Another example of people wanting to turn Java into their language du jour. This is Java, not C#.
BigDecimal operator support
If Strings didn't have an overloaded operator, I'd say no. But since it does, there's precedent. The method calls already exist for everything, I'm pretty sure, so the implementation wouldn't be bad. But do we want to overload more operators into Java? The String + operator isn't exactly what we call "clean" anyway.
Strings in switch statements
It could work if the switch statement automatically internalizes the variable it's given. But a switch block is defined in terms of primitives, and when you do it with strings, it smacks of pointer logic. I'm kinda ambivalent on this one
Comparisons for enums
I really don't like this. At all. An enumeration is a discrete set of values that don't necessarily have an integer value. They want enums to work like they work in C, and there's a reason why they don't.
Chained invocation
Another example of supporting lazy programming. Void returns nothing, not "this".
Extension methods
Not only lazy programming, but also trying to make Java into something else. This isn't JavaScript.
Improved catch clause
The pipe operator is bitwise or. Using it with classes seems wrong just on its face. The second half doesn't make much sense to me.
invokedynamic
Is the future of the JVM to support multiple languages? I'm not sure if it should be. But if that's where they want to go, so be it.
Tiered Compilation, G1 Garbage Collector
I like enhancements to the JVM.
More Script Engines
Sure!
The above link describes several possible features of the new Java 7 platform coming out God knows when. There are a great many ideas out there, and I feel it necessary to comment on some of these. Starting at the top.
JSR 294 Improved Modularity Support (superpackages)
I think something like this is always a good thing. I don't know how it's going to be implemented, but it seems like it's going to be part of the JAR manifest. Neat idea.
JSR 277 Java Module System
Anything to aid deployment of a Java application is a good thing in my book. (I should probably read up on Web Start.)
Java Kernel
It's still on this page, and it doesn't need to be. I laugh.
JSR 203 NIO2
I've wanted to write my own Java Zip utility (including TAR functionality) in 100% Java, and it's not easy to do that without access to file attributes. I'm a little leery about escaping to filesystem-specific APIs, as that breaks run-anywhere paradigm. But everything else seems good.
JSR 310 Date and Time API
I don't really get this one. While the idea of describing date without time and time without date and having well-defined types for units of hours and such is interesting, it doesn't seem useful enough to justify yet another time system. Maybe it's useful for intervals and durations. I don't get it. Maybe it's just too early to tell and they just haven't finished it yet.
JSR 275 Units and Quantities
This one's really interesting. This can make a lot of scientific programs easier to create. I made a system to describe prescriptions and did something like this, but this might make things easier. I'd like to know how precise the conversions would be. If they can support BigDecimal as well as double, that would be a good thing.
JSR 107 JCache API
Seems OK to me.
JSR 166 Concurrency Utilities
I'm always in support for improving something that's already good and useful to make it even more useful. There's probably going to be new queue concepts and implementations going in there for a while so that every useful possibility is allowed. Plus, I think this would support multi-processors better, too.
JSR 225 XQuery API for Java
XML good.
JSR 284 Resource Consumption Management API
It's got to be useful for someone.
Miscellaneous Library Changes
Huh?
JSR 296 Swing Application Framework
Yay! Now if we can get everyone passed this misconception that Java is slow.
JSR 295 Beans Binding, JSR 303 Beans Validation
I don't know enough about Beans, but I probably should.
Java Media Components
About time!
JSR 255 JMX 2.0, JSR 262 Web Services Connector for JMX
It's enterprise something or other. I dunno.
JSR 260 Javadoc Technology Update
I think it's a good thing... I don't know though.
Reified Generics
I don't think I like the idea of making code not compatible with older modules running in a newer JVM, especially if it's something in the language that would cause this incompatibility.
Type Literals
Yes. Why isn't it? Well, it's implementation class "Class" is generified... If it's not done, maybe they think it's overkill. I don't think it is.
JSR 308 Annotations on Java Types
This is a really interesting idea. I like it.
Type inference
This seems to be a way to support lazy programming. I don't like lazy programming.
Closures
I do not like this idea. You're creating a completely new programming paradigm within a well established language. I'm not sold on the idea. The problem isn't well defined, and the solution is even less so. It seems that it's a bunch of people who like their old language and want to turn Java into it.
Automatic Resource Block Management
Anything to improve resource management in the JVM is good. Not saying it's bad, but if there's room for improvement, it should be filled.
Language level XML support
Bad idea. It's introducing another language into Java. I hate that paradigm. I have to deal with Objective C enough, I don't want two syntaxes in one language.
JavaBean property support
Another example of people wanting to turn Java into their language du jour. This is Java, not C#.
BigDecimal operator support
If Strings didn't have an overloaded operator, I'd say no. But since it does, there's precedent. The method calls already exist for everything, I'm pretty sure, so the implementation wouldn't be bad. But do we want to overload more operators into Java? The String + operator isn't exactly what we call "clean" anyway.
Strings in switch statements
It could work if the switch statement automatically internalizes the variable it's given. But a switch block is defined in terms of primitives, and when you do it with strings, it smacks of pointer logic. I'm kinda ambivalent on this one
Comparisons for enums
I really don't like this. At all. An enumeration is a discrete set of values that don't necessarily have an integer value. They want enums to work like they work in C, and there's a reason why they don't.
Chained invocation
Another example of supporting lazy programming. Void returns nothing, not "this".
Extension methods
Not only lazy programming, but also trying to make Java into something else. This isn't JavaScript.
Improved catch clause
The pipe operator is bitwise or. Using it with classes seems wrong just on its face. The second half doesn't make much sense to me.
invokedynamic
Is the future of the JVM to support multiple languages? I'm not sure if it should be. But if that's where they want to go, so be it.
Tiered Compilation, G1 Garbage Collector
I like enhancements to the JVM.
More Script Engines
Sure!