[quote=“Riven,post:59,topic:34557”]
You’re correct, but I was thinking something like
this.vec = (v add v2 mul v3 div 2).normalize();
for the sake of his argument. In a case like that one instance does escape.
and the few objects that do escape are going to get mopped up by the increasingly sophisticated garbage collection going on. It’s all good stuff 
Cas
It does a lot of optimisation but I wont say it does it soooo well (a simple exemple is arrays bounds check where it just doesn’t do any (enought) even
if you acces array in a stupid loop (for i<a.length), you cannot rely 100% on it (or without thinking of what’s going on in the background)
abstracting more will just make it harder to get rids of certain bugs.
I used (just few tests) it too some years ago, dont remember wich release, and in fact it was making application a bit faster : but as I remember it also
allow strong optimisation as arrays bounds check remove and also take age to compile. EA ofcourse will optimize ( it is its first goal no ? ) but above optimisation is just sometime impossible.
I really think that complexification of the language is not requiered ( wont really change our life or make java more simple / readable ) and is not a good way and that it wont serve Java (and I already think that Generics just sucks too…)
some primary goal was to be … Simple & have High Performance : http://java.sun.com/docs/white/langenv/Intro.doc2.html two things that are going away with all thoses new features added every days.
I wonder why at first they only overload one operator (+) for the String cast ? anyone know ?
are you really going to forget abut object pooling ? in any case ?
EDIT: just want to add this one … :’( as I see Jave & JRE becoming every day more and more bug full and there is so much entousiasme/support around this … that’s too sad
I got in their 5.0 beta a couple of years ago and tried it with Snowman Village, and performance seemed about identical (although obviously there wasn’t any JIT warmup, which is a big plus). Although it wasn’t a particularly CPU hungry game so I’m not sure how fair a comparison it was.
A big thumbs up for their tools though - they’ve got a nice gui app where you point it at your jars and set a few config flags and it’ll spit out an exe that pretty much worked straight away. It’s a shame it’s so pricey ($1200 for the basic version) since it seems like a really good product.
arrrg, you’r crazy ! dont do that
operator overloading is nice sometime but I think that it maybe confusing in many many case.
I find pretty nice to use somthing like the following that let me write easy undertadable code :
public Vector add(Vector v)
{
x+=v.x etc...
retur this;
}
public Vector mul(double m)
{
x*=m etc...
retur this;
}
//then you can write things like below wich I found are less confusing, and with one you are not limited by the number of operators :
v.add(v2).mul(v3).div(2).normalize()
you simply have to read from left to right (no operator priority problem)
[/quote]
Yup, I personally use that style and find it works great. “c = a.plus(b)” is just as readable as “c = a + b”, BUT it has the added bonus that when I see it, I know that ‘a’ is a class, ‘plus’ is a method and I know where to go to find the definition. With overloading as in C++, when I see “c = a + b” and I can’t tell if these are classes, primitives, or indeed what the line means. Without reading all the code to find out whether something has overloaded this operation, I can’t tell what the lines means (or even where to go to find out)
cool
and not to mention it is homogeneous (between unary opertors or multiple one)
I can do :
vtmp.copy(v0).rotateX(0.5).rotateY(0.1).add(v2).normalize()
and continue in the same way :
vtmp.copy(v0).rotateX(0.5).rotateY(0.1).add(v2).normalize().add(v3).mul(2).rotateXYZ(0.5,0.5,0.1)
EDIT : and also that you get each operator in code completion every time you type “.” in the above line
EA’s in java 7 and Sun have said it will be backported to java 6 too. It’s already been included in the JRE 6 u14 distribution (http://java.sun.com/javase/6/webnotes/6u14.html) and can be turned on using an optional flag. I tried it and saw a speed up of about 15% in my app. I don’t think it’s in the latest JRE 6 u17, hopefully it will get re-included soon.
@C#:
In the beginning they had added a lot of stuff from the community wish list, thus my comparison with C++.
Though I have no idea how stable (feature change wise ) it is ATM.
@ operator overloading:
+1 against operator overloading (or -1 for operator overloading ?)
While it is a nice feature, it can introduce a lot of headache when that + does not really do what you think it does.
Naturally this is just a question of misusing the feature, but sadly people can and will, so I’d rather no see it.
It is kinda like the defines in C/C++.
A great tool that can really be helpful, but Evil when people start misusing it, as in my example above.
(actually, both are features I miss in Java, but they do not belong in Java)
As someone mentioned before, the nice thing about Java is you can just look at the code and know, that it will exactly what it states.
No hidden defines, no overloaded operators.
Yes, operator overloading sucks, but what about being able to define operator methods as per my suggestion…? Easily readable, minimal syntactical update, no confusion, all the benefits…
Cas
A compliant ahead-of-time compiler may not perform transforms across compilation-units. Transforming wrapped primatives would have to happen at runtime. And even inside a CU these types of transforms are hairy. One cannot statically know if some other CU may call the method in question. Therefore any transformed method would have to be replicated…and potentially multiple time depending on the number of wrapped primative parameters.
WRT: Operator overloading
To be clear, I’m not advocating adding operator overloading to Java. I simply find the “bad programming” argument very weak.
To quote myself:
All the examples given are trivally short and easy to read. When I really want operator overloading is for things like: implement a higher precision float library and build basic operations of top of that (vector analysis, linear alg., ortho-polys, etc) and/or multi-element algebras. When a given method has hundreds of algebraic operations, readability becomes a real issue.
this.vec = (v add v2 mul v3 div 2).normalize();
Add some colons and flip the normalize to the front and you have SmallTalk. 
[quote=“Roquen,post:71,topic:34557”]
If operator overloading is added then ITSM that it should be reserved for algebraic objects: not full fields (as then it wouldn’t be usable for matrices) but at least structures in which all four of the overloaded operators (±*/) make sense. Modulus doesn’t make sense except for numbers, so isn’t included.
I think you’d have to use F-bounded polymorphism, though, which might make it unpopular. Sample interface, so that people can complain about the generics 
public interface OpOverloadObject<T extends OpOverloadObject<T>>
{
public T add(T addend);
public T subtract(T minuend);
public T times(T multiplicand);
public T divide(T divisor);
}
The F-bound is kept simple deliberately. The method names are spelt out in full to avoid changing the parser. It should probably be in the contract that (a+b)-b = (a-b)+b = a algebraically (although obviously error is permitted) and similarly (a*b)/b = (a/b)*b algebraically unless the division results in ArithmeticException.
@Bad programmer code:
Let’s be honest here. Every code not written by oneself is ‘bad programmer code’.
You’d be surprised how people can really butcher a language.
Though I did not find DzzD’s version hideous, it could be cool.
I also see how this could still be messy if you have, say two different Vector classes.
Say Vector2d and Vector3d (an example, don’t taze me, bro ).
Then you’d have to be more exact again.
(v Vector2d.add v2 Vector2d.mul v3 Vector2d.div 2).normalize();
or?
Not to mention the icky VB.net feeling I get when looking at it.
(ye olde, is that a comment or a method call with parameters?)
I see what you mean, but I honestly do not really see the benefits.
Yet I’d still prefer DzzD’s version. If not for the only fact that no changes would be needed.
@pjt33: Limiting the set of operators doesn’t make sense to me. This ignores non-primative scalar types for instance. Nor does requiring certain algebraic properties…besides it couldn’t be enforced.
@cass: Seriously, your suggestion would require an extra ‘token’ to denote an operator, otherwise:
a add (b+c)
where ‘a’ is some user-defined type and ‘b’ & ‘c’ are prims AND type-of ‘a’ has both operator add and method add…which is it? Whereas:
a add: (b+c)
must be the operator.
There needs to be a clean compile-time way to check which operations are supported. I suppose you could have an interface per overridable operator if you want maximum flexibility.
Consistency between compareTo and equals or between equals and hashCode can’t be enforced. That doesn’t stop consistency being in the contract.
I prefer DzzD’s approach too Though as I use official javax.vecmath API I have to have it on different lines… but I’m sorta used to it already. Many things are really just about habit. And operator overloading doesn’t match Java’s goals such as simplicity. If you prefer these things use different language, eg. Scala or C++
Well written pure C++ can be pleasure to use too, unfortunatelly C++ allows so many things so that every programmer uses different subset of the language and different libraries are totally inconsistent between each other.
As for closures… I was quite against them in Java even if they’re handy for me… if it’ll look much like the FCM it’s still very Java-like and simple so I would use that without problem, but I hope not much more radical changes will be made to Java in next (at least) 5 years.
official response from Mark Reinhold’s why closures are in java 7
How is it ‘fake’?
I assume by fake you mean it’s syntactic sugar, and there is nothing wrong with syntactic sugar IMO.
Do you also prefer to define Iterators instead of using the for(Obj o : collection) loop?
-Ido.
Oh, great… :
Aw hell, let’s just turn this into J++ and make sure no lazy ass programmer need not write a single friggn character to much.
S.o.p I’m even to lazy to wri …
Just look at the (currently) last entry in the blog what some people want … with pushovers like this, how long until this is added?
Though maybe someone can explain to me what closures have to do with parallel programming.
I mean it seems like the justification to add them.
Not to mention the lame arse ‘ohh I have the best idea and if you do not like it, you still live in the past’.
‘Move forward’ you only hear from people either trying to hide their past or get something through asap under people’s noses (like those mid-night bills).
Seriously, if it is added it will NEVER be taken out again, no matter how much people will complain.
‘oh, we cannot remove it now, people have already used it in their code and removing it would break it’
Though I doubt people could complain enough, seeing as the people who wanted to add the feature will be the ones that will have to decide if it stays in or not.
How do you convince a person who is convinced of something that they are wrong?
And if that were not enough, yes, let’s open up language design to popular demand.
Yeah, that should REALLY help.
(wow, are we talking Bush politics here or Java?)
Java is going down the drain because they are trying to press in new features to make it look like they are not lagging behind (as has often been a point of critique).
They do not want to add some kind of function class that just might make more sense, but closures… ah fine, let’s also make sure the code is nicely obfuscated while we are at it.
I rolled my eyes when I saw the foreach but it was not THAT bad.
And, depending on the situation, I even use it quite often.
But seriously, we are not talking about just a foreach loop (a minor change) but a big friggn feature similar to the generics.
And this should not just be taken lightly.
I’m all for features that can reduce the amount of boilerplate code needed in Java.
I like the simplicity of Java and was skeptical about the changes made to Java 1.5. But now I use more or less all the features that was added. The enhanced for loop is just fantastic. The engine I’m developing uses a property system that could not have been made without autoboxing. I use generics for some simple things like this:
for (Sound sound : world.getComponents(Sound.class)) {
sound.stop();
}
So I can’t wait to get closures. I’m sure it will make Java a better language.