The Java community has been debating the concept adding type inference to Java 7 the last few weeks. Remi Forax has a blog post detailing a javac patch for two popular proposals. One nicknamed Algol from James Gosling uses := syntax to identify the declaration:
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.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/how-to-manage-full-stack-java-development-with-hilla/en/smallimage/manage-full-stack-java-development-with-hilla-small-1686055303315.jpg)
/articles/open-source-java-profilers/en/smallimage/unleash-power-of-open-source-java-profilers-small-1681206807197.jpg)
/articles/rapid-startup-of-your-cloud-native-java/en/smallimage/logo-1680293937095.jpg){kind=logo}
/presentations/java-compiler-intermediate-representation/en/smallimage/chris_seaton-s-1679038354209.jpg)
/presentations/jfr-observability/en/smallimage/Ben Evans-s-1675024642432.jpg)
/articles/graalvm-java-compilers-openjdk/en/smallimage/small-image-jdk-2023-1671096273181.jpg)
/articles/java-jvm-trends-2022/en/smallimage/InfoQ-Trends-Report-small-1670863712433.jpeg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/rmi-to-websocket/en/smallimage/migrate-a-RMI-based-legacy-application-to-WebSocket-small-1680106723513.jpg)
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
/articles/series-apache-kafka-streams/en/smallimage/apache-kafka-article-series-logo-small-1673455781546.jpg){kind=logo}
/articles/secure-kafka-cluster-strimzi/en/smallimage/securing-a-kafka-cluster-in-kubernetes-using-strimzi-small-1671647644310.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/presentations/doordash-event-system/en/smallimage/allen-wang-small-1685003811186.jpg)
/presentations/technology-change/en/smallimage/lisa-gelobter-small-1685003217738.jpg)
/articles/debugging-beneath-trusted-abstraction/en/smallimage/debugging-outside-comfort-zone-diving-beneath-trusted-abstraction-small-1685961994992.jpg)
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
Community comments
Type inference doesn't imply weak typing
by Paul Fremantle,
Re: Type inference doesn't imply weak typing
by Jonathan Allen,
leave the new constructs to a new language
by Thom Nichols,
Yet another dumb "optimisation"
by Steve Jones,
Re: Yet another dumb "optimisation"
by Arnt E Berge,
Re: Yet another dumb "optimisation"
by Richard L. Burton III,
What?
by Jean-Baptiste Potonnier,
Type inference doesn't imply weak typing
by Paul Fremantle,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
Re: Type inference doesn't imply weak typing
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
leave the new constructs to a new language
by Thom Nichols,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Yet another dumb "optimisation"
by Steve Jones,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Yet another dumb "optimisation"
by Arnt E Berge,
Your message is awaiting moderation. Thank you for participating in the discussion.
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?
What?
by Jean-Baptiste Potonnier,
Your message is awaiting moderation. Thank you for participating in the discussion.
"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.
Re: Yet another dumb "optimisation"
by Richard L. Burton III,
Your message is awaiting moderation. Thank you for participating in the discussion.
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!