Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
2014 - Java 3 platform?
At 9:36 PM on Oct 7, 2007, Daniel MD wrote:
Fresh Jobs for Developers Post a job opportunity
Scala is one of the most talked about languages to replace Java as the main language on the JVM. Some people are even calling it the Java 3 platform. However, this thought disgusts many Java developers.
Lately many API/Library developers have complained about shortcomings of the language , and questioned some of the early design decisions like the lack of operator overloading.
Other developers are pushing for the addition of language level support for features like Proprieties, Continuation, Self-Type, a new Generics model and many others. Adding new keywords like propriety , or immutable .
Usually Java's shortcomings can be "Worked Around" thru "creative design" which usually results is weird syntax, and allot of head scratching.
Despite the availability of workarounds for most of the issues, there are a few language level improvements to be made. Currently there has been an incremental addition of these features with Java 5 generics, annotation, etc... However, some of the necessary changes require a revolution not an evolution.
Clearly, the Java 2 platform is showing its age. The recent boom in programming languages has made all of us "sofa" programming language designers. The web has made academic language research that used to be considered esoteric, available to a large developer audience.
Do we need to start working on a Java 3 platform? After all Java is now GPLed and we have projects like Kitchen Sink Language that facilities testing these features.
Do we need a revolution, or can all these features be gradually integrated into the language?
What would you like to see in Java 3? I for one have always missed C++'s operator overloading, and self-types are very appealing.
The year is 2014. How would you Design Java 3?
53 replies so far (
Post your own)
Re: 2014 - Java 3 platform?
I think the future Java Platform should not bring too many new features. (I am quite happy that we do not have operator overloading so that I know exactly what a '+' does when I see one.)Peeking into the future I just hope for a healthy diversity of languages, all running on top of the VM. Groovy, JRuby, Scala, all of them are great steps toward a bright future.
Bottom line: we don't need to change Java, we just need more languages on the VM.
Re: 2014 - Java 3 platform?
Perhaps this isn't the place to engage in the (usually flakey) 'debate' over operator overloading, but...> (I am quite happy that we do not
> have operator overloading so that I know exactly what
> a '+' does when I see one.)
Do you know exactly what 'x.plus(y)' means when you see it? If so, why is 'x + y' any different? Or if not, why not ban methods as well as operators?
Operator overloading was much abused in other languages, possibly because the feature was made too general. The same does not have to be the case with Java. Nobody who advocates operator overloading in Java is advocating the same implementation as in C++.
Re: 2014 - Java 3 platform?
In 2014 we will be not "sofa programming language designers" but Domain Specific Language designers and Java will be main platform for most of DSLs.This will make big difference in language development. As only senior programmers and architects will use Java the opposition to evolve Java language (platform) will be not very strong. It will not matter if people who just finish university understand it or not, because they will work with much high level and much more specialized languages.
It will be again time when only passionates are using Java, and they will welcome any new addition, as it was at first years.
parallel block
how about a new keyword - parallel. All statements within a parallel block, can be optimised by allowing them to be executed in parallel. Somthing like:bean b = new bean();
parallel{
b.seta(val1);
b.setb(val2);
b.setc(val3);
b.setd(val4);
b.sete(val5);
}
// when parallel block exits, all statements within the
// block have run.
business.processbean(b);
Re: 2014 - Java 3 platform?
> Peeking into the future I just hope for a healthy> diversity of languages, all running on top of the VM.
> Groovy, JRuby, Scala, all of them are great steps
> toward a bright future.
>
> Bottom line: we don't need to change Java, we just
> need more languages on the VM.
Does that mean that you pan to stop using Java in determent to using other languages?
Would this not make the Java programing language "die"? What I am asking here is not if the Java platform has a future. What I am asking is: does the Java language have a future? If so, what would you like that future to look like?
Do we need to break Java to fix it? Like we did with the Java 2 platform? Why is Groovy or JRuby or Scala better than a Java 3 designed Java?
Re: 2014 - Java 3 platform?
> In 2014 we will be not "sofa programming language> designers" but Domain Specific Language designers and
> Java will be main platform for most of DSLs.
Ah the DSL trend. Somehow i don't think DSL are a silver bullet to all programming needs. Will the developer world really move to a paradigm with no general purpose languages? Somehow i doubt that. I have yet to see any examples of the scalability of a DSL.
> This will make big difference in language
> development. As only senior programmers and
> architects will use Java the opposition to evolve
> Java language (platform) will be not very strong. It
> will not matter if people who just finish university
> understand it or not, because they will work with
> much high level and much more specialized languages.
> It will be again time when only passionates are using
> Java, and they will welcome any new addition, as it
> was at first years.
Hum... my spidey senses tell me that the DSL movement is more hype than substance. Several reasons, each DSL requires proper tooling and while companies like JetBrains have dabbled in this area, their solution is still somewhat lacking.
Beyond that i have my doubts about the scalability of DSLs and the end of general purpose languages, that have huge library stacks.
So do you think there is no revolutionary changes to be made in the Java platform?
Re: 2014 - Java 3 platform?
> > (I am quite happy that we do not> > have operator overloading so that I know exactly
> what
> > a '+' does when I see one.)
>
>
> Do you know exactly what 'x.plus(y)' means when you
> see it? If so, why is 'x + y' any different? Or if
> not, why not ban methods as well as operators?
Granted: both are basically just names for some kind of logic. And it is also easy to use a silly name for a method, but I want to force the developer to actively think of a name instead of just picking one of the available operators.
Re: parallel block
Yes, the request of parallel /concurrent processing is also high on my list of nice to have features for a Java 3 platform.Re: 2014 - Java 3 platform?
Java is great as it is. Why do you think it needs to change to keep living?There is no point in forcing others to use new features you would like by changing the language for everyone. Use some other language and leave Java alone - these changes are much easier to implement in a new language and they wont break existing code for anyone there... That is what all the new JVM languages are for
I'm sick of people judging quality of a language by the number of characters they have to type in Hello World.
Go play with http://en.wikipedia.org/wiki/Brainfuck
Re: 2014 - Java 3 platform?
> Do you know exactly what 'x.plus(y)' means when you> see it? If so, why is 'x + y' any different? Or if
> not, why not ban methods as well as operators?
>
> Operator overloading was much abused in other
> languages, possibly because the feature was made too
> general. The same does not have to be the case with
> Java. Nobody who advocates operator overloading in
> Java is advocating the same implementation as in C++.
I have to agree with Jonathan here. Just because operator overloading was abused in C++, does not mean a similar implementation in Java. This is a topic that divides, and there are some good points from both fields, however i don't think a proper Java operator overloading in Java would hurt anyone that is against it. In the end you can still use x.plus(y); if you choose to do so.
Re: 2014 - Java 3 platform?
> Java is great as it is. Why do you think it needs to> change to keep living?
Due to the high amount of people voicing that opinion. And also due to personal experience, with Java vs other languages.
> There is no point in forcing others to use new
> features you would like by changing the language for
> everyone. Use some other language and leave Java
> alone - these changes are much easier to implement in
> a new language and they wont break existing code for
> anyone there... That is what all the new JVM
> languages are for ;)
Why reinvent the wheel if all you want to do is make it bigger and better? Yeah, i want to break Java, in a similar way that Java 2 was a break from early Java. Most of the features requested have a good point, and rise from practical needs. Even though most of the time there are work arounds, why should a language enforce itself and not adapt? Adapt or die! I for one would like to see Java language adapt, not die.
Re: 2014 - Java 3 platform?
I doubt I will ever stop using Java, but I may be using more other languages in addition. For example: Java for technical framework stuff and other languages for business logic? Different languages have different strengths as a tool and I think it pays to have a large toolbelt.Java was originally designed to be safe and easy to learn. Whatever we add should be easy to learn as well. Whatever we do... lets make it easy to grasp. And keep the static typing
> Do we need to break Java to fix it? Like we did with
> the Java 2 platform? Why is Groovy or JRuby or Scala
> better than a Java 3 designed Java?
Break Java? *shudder*
I am taking the conservative standpoint here and actually wouldn't change much. I personally would like to have some kind of closure support but can also live without it.
To get ideas what Java 7 might bring: http://tech.puredanger.com/java7 is a great start
Re: 2014 - Java 3 platform?
I would like to see a way to specify access beyond just 'package' access. I separate the foundation from my UIs, so some way to enforce that in the API would be helpful. For example: I want the foundation to be able to call function X but the UI should never call it. This would help developers using an API know which functions are applicable to them (based on where they're calling it). Simply shoving everything into a single package because of access is not only ugly, but offers no granularity. I am reluctant to call it this: but an improved 'friend' keyword.Removing C++ features
I for one would advocate removing C++ features in Java3. It made good sense to have them in the original Java design because most people were migrating from C++ but it makes less sense nowadays.I would advocate removing or retrofitting constructs such as switch where the default behavior is to leak through. Requiring an explicit leak-through statement would be less error-prone in my view. Also someone published a paper recently that suggested that method arguments should be assumed to be non-null by default, whereas right now they are assumed to accept null and users have to explicitly through IllegalArgumentException if this isn't the case. If you examine 90% of code out there the opposite is simply the case.
In general I would advocate revisiting every single feature in Java and asking whether it would be possible to clean it up or remove it altogether if it was really bad. I suspect you'd end up with 90% of what we call Java today but it would be even nicer to use
I'm in favor of adding new features to the platform, but only once we take a more serious look at cleaning up the base. I would especially like to see Generics cleaned up to improve readability and flexibility.