i finally put jme sources into eclipse and i got a lot of warnings about generic data types
my questions is, what is the future plan in using generic data types?
i think, i could correct all jme sources, if u want it
let me know
Or you can configure eclipse not to show the warnings.
I think for now, jME will stay 1.4.2 compliant. There's no speed advantages as far as I know, and all the code that uses this is not exposed to the user. At least as long as there are still a lot of people with 1.4.2 out there (espc. Mac users, though 1.5 is becoming more available for them now) and there are no clear advantages…
Aren't generics compile time only? I mean, can't we utilize generics in our source code and then compile 1.4 compliant still? I was under the impression it was just for the beautification of code like auto-boxing/unboxing?
I understand the reasoning to still maintain 1.4 compliance if we don't want to force any developers that want to pull over from CVS to upgrade to 1.5 if they don't want to, but if they're going to be running games you should really hope people to be running 1.5 as it is drastically faster than 1.4.
darkfrog
ok,
i turned off these types of warnings.
i found 24 never used imports, it should be removed, i think 
While theory you could probably write a compiler that compiles some 5.0 source (like generics) to 1.4 class files (indeed, the 5.0 bytecode does not have any enhancement for generics afaik, thus, like I said, no speed ups). However, Suns compiler (specs) do not permit this, only with 1.2 and to 1.3 source compatability can you compile to a lower level (1.1) of class compatability. With 1.4 and 5.0 this is no longer possible. Wouldn't know about 6.0 to be honest :lol:
In any case, like I said, there's very little benifit in it for jME that I can see in the first place.
And while you can expect developers to run 5.0 (or at least both 1.4 and 5.0), the same can not be said for all the potential users.
I agree about not necessarily all users having 1.5 and after doing a quick test I proved that you are correct on the other point as well. :-p
I thought perhaps you could use -source 1.5 and -target 1.4 and it would work…apparently not. :o
darkfrog
maybe there could be some little project to make both possible.
i would like to get a version build for 5.0 if kokoth can give it to me.
there are differences between 1.4 and 5 performance, i thinks it has much to do with the way you prog what version fits better.
if u try to support both theres no real update lag between the upcoming changes if theres time to really change to 5.0
Cream,
Llama is correct in stating that there really isn't a performance difference for using generics and such in your project. What you are thinking of is RUNNING under 1.5…the project can be built under 1.4 and still run under 1.5 without much difference at all. You may seem a slight loading difference as they've changed some things about the way class files are written in 1.5 but that's about it.
darkfrog
Change sources to 1.5 is not problem (only a few houres). But now, it is not clever to have both 1.4 and 1.5 versions, i think (my opinion only).
Yeah, it doesn't make sense to maintain two copies of the code.
darkfrog
In general I would say java 1.5 support right now is very nice for MMORPG for instance, with hibernate 3.0 support and the upcoming J2EE standard. Anotations can be used for a lot of things 
Same for code readability and so on I prefer 1.5 before 1.4. So my MMORPG project is running 1.5 at this time. When will jme be fully compatible with this?
I havent started with the graphix yet so I don't know what problems lay ahead and where the problems are so I feel a tad on thin ice asking this … Currently to get a decent clustering option for the registry servers I run last jboss stuff and for the instance servers (which I obviously did not start on yet) I was hoping to do my own server code in 1.5 together with the client code, not only for running the latest version but to get cleaner code, hence generic data types and a few other options that I like with 1.5.
Would be fun to get a quick rundown to know if I have to do any changes and if its a lot of work that has to be done. 1.4 is not really an option since I refuse using Hibernate 2.x code in the servers.
You can make your project 1.5 compliant while jME is still 1.4. It doesn’t matter for Hibernate since you’re not going to be persisting jME objects, right? Even if you are, I’m not a fan of Hibernate, nor the ideology of annotations being used to contain database specific information. I think that’s just bad.
In fact, I’m such a non-fan of Hibernate that I created my own project a while back as an example of how an ORM should be and to prove what a bear Hibernate is:
http://www.javarelational.org
I’m always up to constructive criticism. The code is still maintained and if you are trying to do something that is not supported let me know. It doesn’t have quite as many bells and whistles as Hibernate, but it’s a lot freakin’ easier to use and more logical in my opinion.
darkfrog
Ok here is the deal.
By jME being 0.4 compatible, it allows users of 1.4 AND 1.5 to run it without problems. Believe me, there are a lot of people not migrating to 1.5 (5.0) yet because of serious bugs that break their code. However, if we move to 1.5, it is not backward compatible, so we force the users to upgrade as well. Something I'm not willing to do with 1.5 being so young.
From a developers perspective, 1.5 gives you nothing. You get a few poorly designed syntactical sugar (some things are nice, some are not). But that's all it is, syntactical sugar. Therefore, it is not a priority to move to 1.5.
This should affect you in no way. You are a user writing an application using jME, right? Just include the jar in your app, and it will be no different. My concern for supporting Hibernate and J2EE is very minimal at this time.
So, when will jME be 1.5 compatible? I wouldn't count on that happening for awhile, at least until a later version is released.
In case anyone’s not aware of this, you can use Retroweaver to code using 5.0 features but then compile down to 1.4 bytecode. Might be a good solution for those itching to jump onto 5.0 but still needing to support 1.4 clients.