How irritating. Strings in switch is in but not improved exception handling.
I even proposed outside of the time limit a not very well thought idea i couldn’t implement for the life of me.
Final interfaces, that is interfaces that are public, but can’t be implemented outside the package. They were supposed to assure the originator of being able to add methods to all implementations so the std api wouldn’t have the glaring holes it has now in the future.
The overlap with abstract classes is obvious, but this scheme would possibly have some advantages right?
I see very little advantage “final interfaces” have over abstract classes.
Interesting project though. Java definitely needs some expressiveness.
Automatic Resource Management sounds really lame. Honestly I can hardly follow the spec on how it would look, but from what I see I think it sucks. This can be done in a much cooler way if “generator” support was added. In Java this would look something like this:
public Generator<String> readLines (File file) throws IOException {
BufferedReader reader = new BufferedReader(new FileReader(file));
try {
while (true) {
String line = reader.readLine();
if (line == null) break;
yield line;
}
} finally {
try {
reader.close();
} catch (IOException ignored) {
}
}
}
.
.
.
for (String line : readLines(file)) {
System.out.println(line);
}
// No need to close!
Note the “yield” statement is where the magic happens. This statement returns a value, then when the generator is asked for the next value execution continues from the yield statement. Only downside is you have to remember “i” comes before “e” in the word “yield”.
If you want to be sure it closes if not all lines are read, then maybe introduce a block statement that cleans up a generator. Admittedly there are some other issues with generators in Java (exception handling for Generator#next()?) but they can probably be worked around.
Improved Type Inference for Generic Instance Creation is also lame because Java generics are lame. Are ClassCastExceptions really such a problem that we need all this sh!t? No. I simply turn the warnings down so that this compiles without warnings:
Map<String, List<String>> anagrams = new HashMap();
Tada! No need to waste my time on the RHS typing “new HashMap<>();” and there is functionally no difference. I guess many people are both too lazy to turn down warnings and anal/OCD, so fill in the right side. Personally, I don’t think using RHS generics, <?>, and whatever other crap is worth it just to avoid the dreaded ClassCastException.
Simplified Varargs Method Invocation… this made it as one of the top improvements? Really?
JSR 292… cool.
Improved Exception Handling for Java… cool.
Language support for Collections… hallelujah!!!
An omnibus proposal for better integral literals… what?
Elvis and Other Null-Safe Operators… this is OK I guess. The “?.” syntax is OK, not sure how I feel about using “?:”.
How about a verbatim string? I like the idea of using backtick (`), but heredoc or whatever would be acceptable.
No you didn’t see correctly. Its not cool. Its not in. You can see my comment there. I’m darth vader. Neither is elvis in btw.
What are the implications of JSR 2.9.2 - are we finally going to see typesafe method handles (without strings, numbers or other lame forms of indexing)?
Agreed about the uselessness of the <> operator. They didn’t do it that way for a specific, backwards compatibility reason as always. Some nonsense.
I’m sure i already saw a continuations library somewhere, but the closing always part is what strikes me - i don’t know if it would work only in the last time.
Actually even though Joshua Bloch sent me the proposal by email* because of my incessant bitching in the openjdk mailing lists, the closing resources thing is much more a problem of consistency than difficulty for me.
After all i use this method
try{
}finally{
static varargs close(Closeables){
}
for ages. I once saw a whole 5 pages thread in artima of pseudo designers masturbating over closures and other language specific keywords to solve this “problem”. It’s mostly a problem of consistency though. Did you know Sockets are not closeable … not to mention the SQL classes wtf? Thus the whole part in the spec about a closeable superinterface with a Exception instead of IOException in java.lang.
The main problem with using abstract classes is the conceptual burden for both the user and the creator. Many interfaces in the jdk just don’t have a corresponding abstract class, and even if they do, the supporting methods elsewhere must receive the interface (for obvious reasons).
Dang, it i know it smacks of fascism, but sometimes I wish that library designers would have a rollback button for obvious stupidities they did, even at the cost of extensibility. The obvious stupidity is in this case is not to be able to add methods in a public supertype for a api.
Did you know that CharSequence has no getChars method. Simply shocking i say. And making string the default read-only type in all of the jdk instead of a interface is a epic fail in my opinion. Arrays turn into StringBuffers/Builders turn into Strings turn into arrays (with the copy fors). Pathetic.
I don’t think allowing dynamic methods in a statically typed language is a good idea.
Final Interfaces don’t sound very good either. Interfaces are the public face of an object, so why allow them to have package private methods? Perhaps I just don’t get it, but abstract classes already allow this and the name is misleading. The advantage of doing this in abstract classes is also that you can keep the interface public whilst it’s implementation details (and how it communicates with classes in the same package) is hidden away in a separate class.
That said I’d like to see something along similar lines, the ability to implement a class as well as interfaces. It would allow multiple inheritance from multiple concrete and abstract classes. The sub-class would be required to implement all public, protected and package protected methods of it’s super-classes itself. This solves a few corner cases that you sometimes get into.
Why was the new exception handling syntax not allowed? It was one of my favourites.
‘Improved resource management’ is basically using/disposable from C#, except they’ve fucked up the language syntax. They should have just copied it directly IMHO, but it looks like a bunch of language geeks got hold of it and decided that they had to come up with something different on principle.
‘Allow String in switch’ is equally crap - if it’s just going to be resolved down to String.hashCode and String.equals anyway then why not open it up to any class? We’ve got enough special-case handling of String already.
Well, with strings you can have string literals as case labels, and with custom classes it will look a lot less clear, so I can live with not having that freedom.
The whole point is them being a weakened closure / simplified anomynous callback - they should not be dynamic in the language itself. In the JVM … who cares.
Not private. Just not implementable outside the package. So if the library author wants to add a method to the interface in a later release he controls all implementations. BTW this is Sun’s excuse for missing methods in interfaces. Simple example: sort in List. Actually i never expected the final interfaces idea to be accepted, simply because it is so fascist. After all disallowing all List implementations (even if only temporally) is extreme. Extension methods OTH, were thrown out with the closures bathwater.
The exception handling syntax was dropped because it would need to mess with the type system and i assume the JLS. Also, if the comments there are anything to go by, because whoever proposed it didn’t have the skillzz to implement a prototype sigh.
As far as the final interfaces go I gues I need more examples somehow I can’t grasp it’s value. Also don’t the modularisation proposals already provide you with that? Simply not expose the interface outside the bundle (or super package or whatever they are going to call it.) - oh wait what your proposing is providing visibility just disable implementing it. hmm Somehow it sounds like ducktape beeing applied to a faulty design - sure the end result will function but it still ain’t that pretty.
elvis well null handling can be annoying but somehow feels like a itchy shirt. Also it is kinda high impact. not that, that is such a bad thing but as far as blogging goes it seems very underdiscussed. It felt like it was going to be squeezed in last minute. Perhaps on the openJDK list it has been discussed in length but mind you not everyone reads that list.
@i30817 isn’t that approach to generics going to break all your code in the future when we erase type erasure? (cause we are gonna :D)
Strings in switch - I couldn’t care less tbh currently I just convert strings to enum’s(typesafety, yey.) currently and it’s painless and I haven’t seen it pop up in my profiler.
Closures wise BGGA is great, sure I wouldn’t want the end product that rolled out of there anywhere near the JDK but as far as research goes it’s pretty darn good. As outlined before I favor CICE. But I was working towards ‘Improved resource management’ or ARM’s implementing this a language construct is just going to be screwy. Perhaps I’m biased because I’m working on a proposal for user defined control structures that allows you to define ‘using’ or ARM’s yourself. Mind you I’m going about it a different way then BGGA as I believe it doesn’t need to be metacircular around a closure (this is because a control structure is executed in place; you can simply rewrite stuff instead of going to the difficulty of capturing the lexical scope) But regardless of my bias: in Joshua’s initial proposal he already highlights problems with using closable etc: “What interface should we use for automatic disposal? Much as I’d like to use Closeable, many existing types (such as java.sql.Connection, Statement, ResultSet, etc.) could not be made to implement it, as they throw other unchecked exceptions.” He also highlights how concurrent locks and the similar construct don’t really mix in.
[quote]The exception handling syntax was dropped because it would need to mess with the type system and i assume the JLS. Also, if the comments there are anything to go by, because whoever proposed it didn’t have the skillzz to implement a prototype sigh.
[/quote]
‘Improved Exception Handling for Java*AUTHOR(S):*Neal M Gafter’
I’m pretty sure that Mr Gafter wouldn’t have any problem whipping one up, but I’m not sure what a prototype would add. I though the official statement was that they lacked sufficient resources or something.
It’s an odd duck of a ‘feature’ but i don’t see anything else that resolves that need - Extension methods i think require no-class-state-bodies (outside of methods offcourse).
Nowadays in my libraries i use a abstract class and no interface. This doesn’t work well when the rest of the codebase expects a interface. In fact i’m left wondering if interfaces weren’t a mistake to being with, and just having abstract classes and one of the proposed mechanism for choosing clashes in multiple inheritance preferable (traits).
They just assume perfection from designers.
I guess they are hoping they can use the annotations @null and @notnull and someother ones project instead. Makes sense since it doesn’t introduce runtime overhead, but i think this will not work, since there are a lot of codebases that return null, just in the jdk alone. The features are more complementary. Even elvis, will normally have a null check at the end, after the short-circuit happens.
What do you mean? My closeable finally? No generics there. The method is:
/**
* Close closeables. Use this in a finally clause.
*/
public static void close(Closeable... closeables) {
for (Closeable c : closeables) {
if (c != null) {
try {
c.close();
} catch (Exception ex) {
Logger.getLogger(IoUtils.class.getName()).log(Level.WARNING, "Couldnt close Closeable", ex);
}
}
}
}
With other variations for the more offensive variants. BTW the closeable interface not always being used is another instance of the designer not being perfect.
Agree completely, but just the fact that it is there means that some moron will use it thorough some codebase i will have to look at.
I will expose my inflexibility, but one of the reasons i don’t like scala, and one of the reasons i don’t like the closures prototype is that they invert the traditional order of a method in java (totally intentional) first arguments then return.
Other is one that ofcourse Neil already mentioned countless times as on purpose to give flexibility to the eventual implementation (no inference). I also puked when i saw exceptions there.
Overloading is for that. It’s a pity we can’t do multiple multiple arguments (heh).
close(Closeable … a, Socket … b, … )
Also if you look at the automatic disposal proposal, he proposes adding methods / retrofitting the exceptions in the affected classes. Classes that already have a close , but a different exception would implement a closeable extended from another “raw” closeable that only throws exception (in java.lang). I agree 100% with this. Ofcourse adding a close method to a interface if that was the supertype affected doesn’t work (again!).
Didn’t remember the author. So … laziness? Hope that Sun wasn’t completely braindead? Who knows.
Oh, you meant using
HashMap<K,V> m = new HashMap();
instead of
HashMap<K,V> m = new HashMap<>();
that would break then.
I would applaud if they did that. It would mean they finally stopped obsessing about backwards compatibility.
But if they did that, i would appreciate the extra mile: NO raw hashmap. All type inference. When used in methods
HashMap returnAMap() would translate in current java to (i think) <K, V> HashMap<K,V> returnAMap()
There wouldn’t be a raw type anymore. When the compiler couldn’t decide, it would require you to clarify.
Which would really break compatibility.
But i actually don’t believe they have the balls to break anything. Maybe now it’s Oracle.
//edit ah I see you got it already. - well balls or not someone at sun must have had the vision they where send out with the requirement of backwards compatibility yet managed to deliver a implementation that doesn’t block forwards compatibility(erase erasure) somehow I don’t think that happened by accident.
There are other area’s where the human factor poses problems, but wouldn’t modularisation simply allow you to replace the module as a whole so it frees you from backwards compatibility, at least in theory.
yeah I hate having to bring that up every time someone tries to argue something along the lines of “if you don’t like it then don’t use it.”
I think they where afraid of wonkyness with types that are castable to both types. I would have to look it up - though that information might not be available development wasn’t that open back then.
Personally, I don’t think using RHS generics, <?>, and whatever other crap is worth it just to avoid the dreaded ClassCastException.