The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Scott Delap on Apr 17, 2007
s := "String";
A second from Peter Ahe and Christian Piesner Hansen makes use of the final keyword:
final s = "String";
Both proposals have the side effect of making the local variable final. A number of developers have spoke out against such a feature however:
Type inference actually makes some sense in languages like JavaScript and PHP that are built around this, and had this feature from day 1. It makes no sense in a language like Java that’s built around the opposite. It makes Java look weakly typed, but it isn’t. In fact, if anything this is now more strongly typed because, for example, you have to type a Map variable as a HashMap or a TreeMap rather than just a Map ... It’s time to call a halt to new features in the Java language. I am not saying that the features are wrong, just that they don’t fit into the language any more. It’s already too bloated. I am not saying that generics, type inference, closures, compiler created factory methods, and other kitchen sink proposals are bad. They’re not. I am saying that they simply don’t fit into or with the current core language, and every one we add makes the language worse, not better.
Such discussion raises the question of whether Java 7 should keep Java the language in its current form or add additional language constructs such as type inference and closures.
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Monitor your Production Java App - includes JMX! Low Overhead - Free download
18 agile and lean practices for effective software development governance
I think its a major misunderstanding to say that type inference is limited to scripting languages. Type inference and strongly typed languages can go very well together.
However, I think the value of type inference is much more useful in functional programming languages. I guess the real benefit comes from putting together closures and type inference to start doing more functional style coding in Java.
Paul
However, I think the value of type inference is much more useful in functional programming languages.
I don't think that is true. Type inference makes sense any language where you have to write the same type name twice on the same line. In fact, I would go so far as to say that languages like C# and Java have a design flaw in that the programmer has to repeat himself dispite the compiler being perfectly capable of understanding what is being asked for.
I agree that many of the new features won't fit well in Java. Instead of fixing something that isn't broken, they should put more effort into supporting higher level dynamic languages like Groovy and JRuby. Help make them so they can easily be used side-by-side with Java code.
Then you'd simply write the needed portions in whatever dynamic language, and it compiles to standard JVM bytecode and works transparently with the rest of your Java code. Easy cheesy.
Type inference is just a case of complete laziness and is brought to us by the same sort of people who think that typing is the most time consuming part of the exercise.
Are there people who really think that the problem with Java is that there are too many characters in a .java file? It would be great to see some efforts focused around making Java a better language for support and professional development. Things like contracts on methods and classes (ala Eiffel) would be nice.
Saving 5 characters just because you think that will be quicker? Complete and utter muppetry.
God to know I'm not the only one thinking we should focus on the stuff that matters.
We humans are very limited. Our brain capacity is limited. If you sum up all you have done in a day it doesn’t amount to much. If one should focus on any idea coming along we wouldn’t get far. We have to ask ourselves, what do we gain? With modern tools you seldom write more than half the words any way. The argument is like saying one should go back to 4 character variable names to get more productive.
What about spending the energy on stuff that matters?
1. Design by contract. (Also with better access levels, not joust private, protected and Public)
2. Object oriented databases.
3. Could there possibly be any improvements that would aid Object Orientation? Is java realy a perfect OO language?
"Type inference actually makes some sense in languages like JavaScript and PHP that are built around this, and had this feature from day 1."
Am I the only one who think this assertion is totally false?
For me, Javascpript and PHP never have had any kind of type inference. Haskell and Ocaml for example have.
Scala has local type inference, and it doesn't seem to bring some sort of problem: the type sys tem is not less strong.
Of course number of caracters to type doen't matter too much, but readibility does. And I dont know about you, but even with auto-completion and so, I'm getting nervous when I have to type ctrl+space, or crtl+1, just to complete a type that I already have typed one second ago! I'd rather go to the following line, like in languages that have type inference, or dynamically typed languages like Python or ruby.
And when I think at languages with time inference, like Ocaml, or Haskel, I thing they are at least as safe as Java.
For me type infererence is a gread thing, combining some avantages of dynamically typed languages, and statically typed ones.
Information Technology is full of smart people. Why are people even entertaining such a silly thought? People need to stop trying to add bells to Java that don't have any ROI and start focusing on things that really matter.
This posting and thread of responses makes me wonder about the member base of InfoQ. Are you guys really that stuck up? May I propose a better topic that could spark some real interesting lines of thought?
How many ways can you screw up job with the use of Code Monkeys?
What ever changes are in the Java 7 core language, I'm sure it'll be incomplete or screwed up. Look at Annotations!
a) You can't extend another annotation - In the background, Annotations are really java.lang.reflect.Proxy objects that implement your interface. Or is being verbose with annotations OK?
b) You can define an attribute as null - E.g., public String name() default null;
Let me stop wasting my breath and start learning Ruby. method_missing!
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
7 comments
Watch Thread Reply