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!
posted by omahaprogrammer at
1:52 PM
4 Comments:
"JSR 296 Swing Application Framework
Yay! Now if we can get everyone passed this misconception that Java is slow."
Honestly, when Java stops being slow, everyone will get past that "misconception." As it stands, I have yet to see a Java UI application that isn't notably slower than a different language implementation would be. Don't get me wrong -- Java's getting better, but it still drags sometimes. Some things aren't too bad (see Openfire, the XMPP server that I've got going at work) and some still make everyone cry (see OpenOffice). It might just be the overhead of starting up the JVM, but the loading time of a Java app is still really terrible. I'm not saying that fast Java applications don't or can't exist, but Java's unlikely to live down its repuation before most Java applications are fast. Besides, "fast" and "slow" are relative, and an interpreted language simply isn't going to be able to match a compiled one, so I suspect that Java will always be regarded as "slow."
"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"
PHP supports the use of strings in switch statements, and while it contributes to the "laziness" of the language, it's really handy. No more needing to use odd single characters or strange enumerations for options which obviously should be represented by strings. I don't know how useful it is in a full programming language, but it's pretty invaluable in a scripting language. Parsing user input works much better when you can feed the input directly into the switch, rather than having to preprocess it heavily.
I wouldn't call PHP's ability to have strings in a switch statement to be lazy. PHP doesn't have a distinction between strings and numbers. There is such a difference in Java. One could call that a criticism of Java not being a true OO language, and I'll accept that. If Java did not have such a distinction, it would be a severe problem if the language did not support switch statements on all types.
Actually, PHP does differentiate between types. It's just a loosely-typed language, so the language tends to do the best it can when presented with one type or another; and sometimes the implicit casting simply can't do the job. For instance, you can't ceil( 'XYZZY' );. You'll get an error about "received TYPE_STRING, expected TYPE_NUMBER," or some such. Essentially a type mismatch. I'm not surprised Java is adding support for strings in switch blocks because everything in Java is just an "object." You aren't ever supposed to even believe that there are such things as pointers. Pointer arithmatic is why (to my knowledge) C/C++ doesn't support strings in switch statements. Considering the invisibility of pointer logic in Java, I'd be surprised if that was seen as a valid reason to keep the construct out of the language. I'm sure using true primitives is still faster, but we're reaching the point in processing that it becomes less of an issue.
buy ativan ativan alcohol withdrawal protocol - ativan for norco withdrawal
Post a Comment
Subscribe to Post Comments [Atom]
<< Home