Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (806)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (868)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Project Coin  (Read 5539 times)
0 Members and 1 Guest are viewing this topic.
Offline i30817

Junior Devvie





« Posted 2009-08-29 23:47:58 »

http://blogs.sun.com/darcy/entry/project_coin_final_five

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?
Offline Nate

« JGO Bitwise Duke »


Medals: 167
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #1 - Posted 2009-08-30 01:42:53 »

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:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
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". Wink

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:
1  
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. :p 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.

Offline i30817

Junior Devvie





« Reply #2 - Posted 2009-08-30 02:18:39 »

"Improved Exception Handling for Java... cool."

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.


*still feels important
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline i30817

Junior Devvie





« Reply #3 - Posted 2009-08-30 02:48:44 »

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.
Offline Nate

« JGO Bitwise Duke »


Medals: 167
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #4 - Posted 2009-08-30 03:01:04 »

I guess I do see the usefulness of "final interfaces". I'm not sure it is the best solution though, at least it feels a little awkward.

Offline i30817

Junior Devvie





« Reply #5 - Posted 2009-08-30 03:13:36 »

One of the alternatives (only for static method i think?) is actually nicer from a user perpective (not from a maintainer though).

Extension methods. I know Neil was messing with as part of the closures work that is (oh god i feel bad) thankfully, not going in.
Offline JL235

JGO Coder


Medals: 10



« Reply #6 - Posted 2009-08-30 04:56:35 »

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.

Offline Orangy Tang

JGO Kernel


Medals: 57
Projects: 11


Monkey for a head


« Reply #7 - Posted 2009-08-30 08:28:50 »

'Improved resource management' is basically using/disposable from C#, except they've f**ked 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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Mr. Gol
« Reply #8 - Posted 2009-08-30 10:37:22 »

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.
Offline i30817

Junior Devvie





« Reply #9 - Posted 2009-09-01 13:31:01 »

I don't think allowing dynamic methods in a statically typed language is a good idea.
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.

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.
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.

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.
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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mr_Light

Senior Devvie


Medals: 1


shiny.


« Reply #10 - Posted 2009-09-01 20:41:02 »

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 Cheesy)

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.
'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 harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline i30817

Junior Devvie





« Reply #11 - Posted 2009-09-01 22:22:57 »

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.
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.

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.
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.

@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 Cheesy)
What do you mean? My closeable finally? No generics there. The method is:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
    /**
     * 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.

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.
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.

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)
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.

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.
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!).

'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.
Didn't remember the author. So ... laziness? Hope that Sun wasn't completely braindead? Who knows.
Offline i30817

Junior Devvie





« Reply #12 - Posted 2009-09-01 22:36:38 »

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.
Offline Mr_Light

Senior Devvie


Medals: 1


shiny.


« Reply #13 - Posted 2009-09-01 23:26:15 »

What do you mean? My closeable finally?
ne
I simply turn the warnings down so that this compiles without warnings:
1  
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.
Wink
//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.
BTW the closeable interface not always being used is another instance of the designer not being perfect.
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.
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.
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."
Didn't remember the author. So ... laziness? Hope that Sun wasn't completely braindead? Who knows.
tis sad that it didn't make it

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline i30817

Junior Devvie





« Reply #14 - Posted 2009-09-01 23:31:46 »

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.

I sincerely hope you are right (but somehow doubt it).

Also, my trolling in that thread seems to have started a recrimination fest.

It's good for them.  Wink

BTW do you know the reason for we not being able to put multiple-multiple arguments in functions?
Offline Mr_Light

Senior Devvie


Medals: 1


shiny.


« Reply #15 - Posted 2009-09-01 23:46:23 »

BTW do you know the reason for we not being able to put multiple-multiple arguments in functions?
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.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Pages: [1]
  ignore  |  Print  
 
 

 
Riven (589 views)
2019-09-04 15:33:17

hadezbladez (5541 views)
2018-11-16 13:46:03

hadezbladez (2422 views)
2018-11-16 13:41:33

hadezbladez (5802 views)
2018-11-16 13:35:35

hadezbladez (1234 views)
2018-11-16 13:32:03

EgonOlsen (4669 views)
2018-06-10 19:43:48

EgonOlsen (5688 views)
2018-06-10 19:43:44

EgonOlsen (3206 views)
2018-06-10 19:43:20

DesertCoockie (4105 views)
2018-05-13 18:23:11

nelsongames (5134 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!