- No primitives. No ints, bytes, chars, shorts, floats, booleans, doubles or longs. They are all evil and should not be in the language.
- No primitive arrays. Javas primitive arrays are not typesafe and are evil. With generics there is no real point in having them, especially since they interact so badly with generic collections. This point would mean that certain primitive collection types can't be implemented in the language itself. This is a price I'm willing to pay.
- Scala style generics, with usage-defined contra/co-variance and more flexible type bounds.
- No anonymous inner classes. There is no need for them with the next points.
- First class methods.
- Anonymous methods (these obviously need to be closures).
- Interfaces that carries optional implementation.
- No abstract classes - since you don't need them with the above.
- Limited type inference, to avoid some typing. Scala or C# style is fine.
- Annotations for many of the current keywords - accessibility specifically, but also things like transient, volatile and synchronized.
- No checked exceptions.
- No angle brackets for generics (they really hurt my eyes. are there XML induced illnesses? XII?). Square brackets look so much better.
- Explicit separation of nullable from non-nullable values.
måndag, maj 19, 2008
Break Java!
As some of you might have noticed I am not extremely fond of everything the Java language. I have spent some time lately trying to figure out how I would change the language if I could. These changes are of course breaking, and would never be included in regular Java. I've had several names for it, but my current favorite is unJava. You can call it Java .314 or minijava if you want. Anyway, here's a quick breakdown of what I'd like to see done to make a better language out of Java without straying to far away from the current language:
Prenumerera på:
Kommentarer till inlägget (Atom)
31 kommentarer:
"devil spawned", yet you're banishing evil from it :-)
As for angle brackets: they come from C++ template syntax, not XML.
Very good list, makes me want to wish even more that Java will be forked into a new state-of-the-art JavaNG/Java 3
I would add object and collection initializes to your list as well as anonymous types.
I think you might have just described C# 3.0 :-)
Eddy.
Well, I DO like Java the language even in it's current implementation as you know Ola, still, I'd love to see that in Java 3000, non-backwards compatible Java7, or whatever you want to call it... mm, with the possible exception of checked exceptions. Still, I can live without them if I get the rest on your list.
:)
I don't see how the combination of these 2 points is any different from asking for multiple inheritance support, is it?
# Interfaces that carries optional implementation.
# No abstract classes - since you don't need them with the above.
I think what u have just described as unJava is a subset of Scala =) ..
Debasish
Yeah...it does sound a little bit like Scala, as Debasish says. I guess Scala's syntax isn't as close to Java's as it could be, and Scala includes a bunch of features like pattern matching and implicit conversions.
Suppress static typing ?
It is often not really usefull in Java's case, just a very simple form of unit tests, and it is a bad friends (type compatibility does not mean same semantic !!! it is ? ok sorry...).
Maybe the essential part of checking can be performed in compilation ?
About half of them could be accomplished by convention. (Of course, there's the standard library you'd still have to deal with - but it could be reimplemented.)
The default implementation reminds me of Objective-C interface + category. You can slap methods on Object (or anything else) all day long.
I think that functionality would considerable alter the internals of the language.
Yes, XII can make you go blind.
What are you afraid of? Why the hesitancy to embrace Scala? You could also have Scoped Implicits, Traits, First Class support for Matching, and DSL friendly Block structures.
Absolutely +1.
What people don't understand about "breaking Java" is that it's not like Java would have to die that day!
Java classes could easily be imported similar to how JRuby and/or Groovy do it. Even if this "super Java" were statically compiled, I'm sure that there would be a fairly simple way to achieve language level support for legacy Java imports, without sacrificing the new language.
Clarification: NO this wouldn't be like embedded assembly or C. Importing a Java class would yield a first-class representation native to "Super Java".
It would not be totally unlike how C# has access to VB code in .NET, but I prefer the Groovy/JRuby parallel.
Clinton
Smalltalk + traits is not a bad combo either.
Manual trackback.
I really think there is something to this Java 3 idea. There is much to be gained from a good cleanup, and if the migration/backwards compatibility story gets compelling, this could actually have an impact.
I mostly agree with the points, but I tend to think that closures are not needed, the BGGA propasal is enough (more Java way).
I want structural typing though, this would increase reuse a lot. Better have every Class automatically implement an Interface if the Interface methods are a subset of the Class.
Peace
-stephan
http://stephan.reposita.org
I like your list, I was thinking of a few more things to include:
1. remove static from the language
2. remove for (can be done with closures)
3. remove if, encourages polymorphism as the solution for type differentiation, and use some rules system for complex expressions.
"No checked exceptions." - I love checked exceptions! Please keep it! :)
Not a language problem. But I would also have to vote for the java standard library to be extensively reworked.
1. To take advantage of the new features.
2. Get rid of the old cruft: really bad implementation inheritance (stack -> vector), things that the new features eliminate, I think the closures will lead to massive improvements (getOrCreate instead of putIfAbsent, internal iterators)
3. Reduce the thickness of the APIs, I am not quite sure of the obsession with monolithic interfaces in the java libraries.
4. Break the dependency between language and API upgrades (and if necessary remove things from the standard library and add to optional independently versioned libraries). The use case for this is things which evolve independently of the JDK, specific case is the SecureRandom class which is designed around one pre-conceived idea, but now more modern random implementations (see DRBGs) just can't shoe-horn into the old API.
In terms of language features, instead of allowing nullable vs non-nullable. Just kill the 'null' keyword. It just causes too many issues, and I am not convinced that annotating (or similar) the fields will help. As it will just become a syntactical mess, and as far as I can see you are likely to end up with null poisoning (a la const poisoning)
"No primitives". "No primitive arrays". So don't you need performances?
"Interfaces that carries optional implementation". Not sure about what you mean, but I think that you can do this with the ScriptEngine API and JavaScript, for example.
"No abstract classes". No comment...
"No checked exception". So you are not interested in reliability?
I don't share your points, probably because my usage pattern is VERY different than yours. But this is Java, a language good for (almost) everything.
These change would really "Break Java", but IMHO not in a good way...
@luca I think you underestimate the power (and potential) of the JIT, because the programmer does not have to concern himself with primitives, does not mean that the JVM can't execute inlined calls on Integer in the same manner - and perform just as well.
Ian Phillips wrote:
I don't see how the combination of these 2 points is any different from asking for multiple inheritance support, is it?
# Interfaces that carries optional implementation.
# No abstract classes - since you don't need them with the above.
That is only multiple inheritance if you allow object or class state in your "Interface", if not, and all computations are made locally (funtionally) and the multiple definitions problem is avoided, it is like a nerfed abstract class.
Also : non nullable values by default. Something in the api like the scala parsers library.
Independently of the rest, getting rid of anonymous classes would be a mistake in my opinion. I use them fairly extensively, even in Scala, and they have a lot of uses not covered by first class functions and method handles. e.g. I usually make specific widgets in a GUI their own anonymous subclass and use it to encapsulate and define custom behaviour. They let you nicely create and inherit local namespaces.
Checked exceptions should stay IMO. It's the java way :) that doesn't mean you can't go nuts with closure constructs, using, a better thought out interface exception and tree, etc.
Also something else. The phyton list comprehensions can replace for usefully, with maybe closures for the rest. Just keep it readable.
The only problem here is the compatibility issue. If that door is ever opened, I'm sure every one of us would have a personal set of features to include.
Anyway, even without language changes, cleaning up the different APIs is really needed, and even more if closures are ever added.
This looks a lot like scala and ruby into java :-), no primitives and arrays, first class and anonymous methods etc. (ruby like) and Interfaces that carries optional implementation +
No abstract classes (traits/mixins from scala)..
hmm, I'm OK with Scala type generics, first class methods, anonymous methods for example, but I don't agree for: no anonymous classes (they are simple to understand for me, and can be very useful without having to learn things like closures, etc...), no primitive types (I think they are necessary to have a decent performance for non scripting languages - but maybe I'm wrong), no abstract classes (hmm a LOT of languages already have abstract classes, why getting rid of them ?) , no checked exceptions (I'm not sure the advantages will outweight the problem it will create)
This is also interessing.
http://blogs.sun.com/ahe/entry/factory_methods
no equals, only eq for reference equality and == for value equality
Scala deprecates int .. etc types in favor of Int, Double etc. It want have _any_ impact on performance. Compiler knows to translate them to primitive.
Something Eric Meijer mentioned during his Fundamentalist Functional Programming talk at JAOO Australia last week made me think that checked exceptions might not be that bad when you think about the way they highlight more of the contract and the possible side-effects of the called function.
Almost :-)
Skicka en kommentar