Can anyone explain to me why they didn’t remove primitives and make them Objects? Seems to me that would be a much better feature of the language (All OO, no exceptions). The compiler could still look at them as primitives, but they should fit into the paradigm…
Just my ¤0.02
I don’t get why everyone wants everything to be an Object… “when the only tool you have is a hammer, every problem looks like a nail” etc.
Cas 
[quote]Can anyone explain to me why they didn’t remove primitives and make them Objects?
[/quote]
Because without them java performance is “worse than you could possibly imagine”.
Unless someone spends a significant amount of time rewriting the JVM to efficiently convert every object into a non-object (or to use lightweight objects everwhere).
PS: when I mentioned “step backwards” I was thinking of the whole thing rather than one specific aspect (there are major unresolved flawd with each of the new additions) and the fact that some of us acutally maintain code (shock!) and appreciate the hell that we’re being set up for by those crusaders for making java into VB. I have a horrible fear of myself turning into a reactionary project manager who dumps on anyone in the team who ever uses generics in any code, with me having to throw the baby out with the bathwater becuase generics causes so many problems we (as a team) can’t afford to use it in the project (where you could have 10% of your team not competent to touch it, and a further 50% who will be slowed down in their productivity every time they encounter it and have to work around it’s horrors).
The vague, ill-defined ideas behind generics are fine. That someone [1] chose to plough ahead and implement these vague wishy-washy ideas before really working out a good spec, and then hacked together a load of crap to make it sort-of-work the way people sort-of-expected-it-to, is a disaster [2]. Generics as implemnted in java 5 is a train-wreck. You can use it effectively, it can save you time, but … it also can f*** you over and open a whole can of worms on your previously clean, sensible, cheap to maintain code.
[1] If it actually happened this way, then the JCP needs massive reform. But…the end result looks just as if this did happen. We have a system whose veyr name is completely misleading, and most of the documentation and press in the months leading up to release were equally misleading, with most people misunderstanding what it was going to be, and then being very surprised by what it turned out to be.
[2] Well, unless you wanted to program in VB anyway. As noted above, in that case you don’t notice that your code has become vastly expensive to maintain - all VB code is like this anyway. You probably only see generics etc as good, in this case. Which is why lots of people like it.
[quote]I don’t get why everyone wants everything to be an Object… “when the only tool you have is a hammer, every problem looks like a nail” etc.
Cas
[/quote]
Maybe they subconsciously realised that java is only 90% OOP language (until java 5 and covariant types, which take it to perhaps 95% or maybe more?), and wanted subconsciously to try and “fix” this.
Or, alternatively, because OOP so revolutionized the maintenence and re-use costs of program code that it became a juggernaut whereby many people entering the industry since 1990 no longer realise that OOP == way to deal with “data with complex methods”, and so don’t appreciate that sometimes you have “data that is merely data” (hence a waste of time to put it into objects), or even “complex methods that have nothing to do with data” (hence if your language only does objects, you get screwed over. c.f. java’s poor function despatch, which can’t really cope with the situations where you don’t have any data, but just a vast sprawling collection of methods [1]).
[1] i.e. it becomes grossly expensive to manage the codebase. This is a PITA to anyone trying to develop a large RPG, because you have thousands of small code fragments and it’s simply too expensive to maintain in java.
blahx3 wrote:
Sorry to keep pressing on this one but I really want to know why you dislike generics. I confess I’ve only scratched the surface so far and only a few days ago discovered the difference between List and List <? extends Fred> so want to know what pitfalls await me.
Generics and Java have after all been around for quite some time with Pizza back in 99 (later renamed Generic Java hence probably the 1.5 name for this facility). This was written by a team at INRIA who certainly understood their type theory - and was AIUI a counter-response to a request from Siemens for templates in Java. So I would have thought there had been plenty of time to thrash out the issues. Pizza seemed well thought out and I nearly used it in our massively multiplayer game engine of the time but went my own route instead. How does 1.5 and Pizza/GJ differ in this?
Dave
[quote]But I’m surprised that noone has mentionned the abomination that is varargs…
[/quote]
I’ve completely blocked them out. Preposterous, absolutely preposterous! As far as I can see, varargs were included solely to allow the creation of a C-style printf statement. What a mess.
I actually kinda like varargs Saves me from writing myObject.myMethod(new Type[] {obj1, obj2…}) all the time.
[quote]blahx3 wrote:
Sorry to keep pressing on this one but I really want to know why you dislike generics.
[/quote]
I started writing it up a couple of months ago, and got to 8 screensfull of pure text, and still hadn’t finished. I put it aside, intending to finish it off and put it online somewhere once I had time - but I’ve had no time since then.
One of the simple things that spring to mind is that generics breaks arrays. Try mixing the two, and discover what bugs it introduces into the language. It’s nasty: generic types are IIRC the only thing that don’t work with arrays transparently
The story-engine one, yes?
See? See? You’ll get there eventually: Java 5 is an abomination that should have been strangled at birth ;D.
Or, more literally, “has JCP additions that should have been vetoed and prevented from making it into core java”.
Modulo my previous comments outlining the people who actually benefit from them…
Heh I think programmers are like players in a game. Nomatter how carefull you implement new features, someone will always complain
Middy wrote:
[quote]Heh I think programmers are like players in a game. Nomatter how carefull you implement new features, someone will always complain Smiley
[/quote]
How right you are - they’ll certainly find every exploit.
blah^3 never answered this question; Others said D, but D isn’t cross platform yet is it? gnu D could exploit the ubiqity of the gnu tool chain, but you still need libs like sdl and opengl (ie lwjgl).
Just curious.
Well, well, … just comments on Tiger? The heading says Tiger, Mustang, Dolpin.
One comment about Tiger’s features hit the nail on the head: you needn’t use them. There are cases when static imports are very handy (I admit it’s good to use it rarely; as Tiger’s readme states). Still it’s up to you to use or not to use it. Same applies to autoboxing. And so on. How many of you have to read the source codes of other people intensively? Very few I guess. So… I don’t think Tiger’s features are the reason there are so few nice Java games around… 
What I liked most about the interview has been this sentence:[quote]I suspect that the Java language will be good for another 20 to 30 years if we manage its evolution carefully.
[/quote]
20 to 30 years would be nice. Even our children could learn the Java platfrom from us then. That would be great.
[quote]How many of you have to read the source codes of other people intensively? Very few I guess.
[/quote]
You think? :o
At least 90% of my job involves reading other people’s code, and I expect that’s true for many others here. Green-field projects really aren’t the norm in business development, you’ll almost always be modifying or integrating with someone else’s code. And even if you are writing something new, there’ll be third-party libraries you need to use to get things working.
No, good source-code readability is vital for any language in today’s market.
Cannot. Emphasize. This. Too. Much.
Java games I meant.
Most games (in general) I’ve seen the source code of, have been green-field projects.
Well, scripting languages are all crap today. They’ve hit the point of being quite nice to use, but performance is beyond god-awful. Give them a few years to all move to running on JVM’s, and…
But, for now, that leaves only two options: C++ and C#
I used to be a professional C programmer, so long ago that I can barely remember it, but at least the adoption cost of C++ would be relatively low for me (I did do some C++ as well, just not for long).
C# would pain me to use, psychologically, because I’d keep thinking “that’s inferior to java”, “java does this bit better”, “java does that thing faster”, etc. But … it does have some good points, and at least I’d retain some x-platform ability.
But, realistically, I’d be moving to C++. D is a complete no-hoper for me, for the myriad reasons I’ve mentioned before when it’s been suggested (in brief: non-existent levels of usage, debugging, and support; retains the worst bits of C and adopts some of the poorer parts of other langs too; almost nothing significant to recommend it over java).
I don’t know where you’re coming from here. The fact that you can interface directly with C is one of D’s strengths. JNI is a nightmare, and potential performance killer. D is compatible at the binary level with C, which makes creating bindings to existing libraries like the various Win32 dlls, OpenGL, SDL, etc… a snap. Sure D supports pointer syntax, but it’s only used when interfacing with C code. Structs are passed by value by default, while classes are treated as Java treats them - passing them by reference. Pointers are supported only for C compatibility, and when writing pure D code there’s no need to use them. The function parameter modifiers in, out, and inout can be used instead.
I don’t want to come off as a D evangelist, but if you spend any significant time with it you will find that it combines many of Java’s best features with many of C++'s most useful features quite sucessfully. Like Java, the spec aims to leave nothing as ‘undefined behavior’. You’ve got a GC that you can turn on and off at will, you can manually delete anything the GC allocated, you can allocate from your own memory pool outside of the GC if you need to, all class objects are references, arrays are bounds checked, all arrays are passed by reference, it has structs that are the same as C structs (which is a good thing), pointer arithmetic is not supported (another good thing), Java-style interfaces (no C++ style multiple inheritance, a very well implemented template mechanism, yadda, yadda.
There are other features that have been borrowed from other languages, such as array slicing, associative arrays., delegates… There’s a lot there that I wish Java had, or had implemented differently.
I agree, from what I’ve seen so far D looks very nice (delegates, arrays, classes, interfaces, templates). But the success of the language will depend on the developer tools. To compete with Java (even in games programming) you must have a nice IDE with refactoring, debugging etc. This is the area where D needs to improve.
OK, so what’s so bad about JNI?
It certainly is NOT in general a “performance killer”. In most cases where it might be you just have to use batching - which is often what you need to do anyway e.g. when rendering anything.
Pointers == bad thing from C.
You say “no need”, but c.f. above one of my problems is that java is introducing “no need” stuff but IN REALITY I can assure you people will.
There was never any “need” to write crap incomprehensible massively op-overloaded C++ code. But thousands of people did it anyway.
I think you simply fundamentally disagree with me what “java’s best features” are. That you say it lacks pointer arithmetic (one of C++'s best features, albeit also something I’d prefer to be without) suggests we also disagree on C++'s best features.
Your list, once stripped of feasibly useful but, in pratice, largely irrelevant things (who cares that I can allocate outside of the GC’s control? If I wanted to do that, I wouldn’t be using a GC at all), sounds like “it’s much less safe than java, and lacks all the big runtime advantages, yet it also lacks some of the most fundamentally important aspects of C++”.
Which pretty much sums up my previous evaluations of it. I’m well aware I may be missing the point here, but D has never seemed anything more than a toy project where some people wanted a few minor alterations to java or C++ and couldn’t be bothered to provide the whole of either (that would be impossibly too much work) but couldn’t be bothered merely to customize either (could have been done from either end).
If you try to judge D by the standards of C++ or Java it falls laughably short. If you try to judge it by the standards of Ruby or similar it probably does OK - except that it has terrible syntax (C-esque) by comparison, and so it still loses out.
I don’t have anything against it, I’ve tried (really) to find something useful there to me, but all I can see is a mish-mash of ideas that is neither one thing nor the other; trying to be many things but being second-class at all of them.
PS out of pure interest I’d like to know what use-cases it’s ideal for, if you’d care to suggest some.