Just wanted to make sure that you all know: it’s there, finally 
I’ve wanted Generics into jME for so long (curse you type casting!). There’s tons of places where Generics and Enumerations can help. Plans to put this in?
While I like 1.5 features, I’m not sure if dropping 1.4 compatibility is a good idea. Think about all people who won’t be able to use webstart to check out jme demos any longer.
If we did go to 1.5, we can still compile the lib to a 1.4 target, generics and all. shrug Evidently the .92 lwjgl jar release was done this way.
Of course, it would mean everyone using cvs would need to switch to 1.5… Personally, I’m not sure if everyone is ready to do that.
"renanse" wrote:
If we did go to 1.5, we can still compile the lib to a 1.4 target, generics and all.
Not so easy for enums, which are for sure one of best parts for jme (all these setSomethingMode calls could take typed enum as parameters instead of random int).
Retroweaver is supposed to allow backporting even enums - has anybody used it ?
Why not ready to switch? Any strong IDE will have 1.5 support. There are lots of 1.5 features that will make jME much easier to use. Basicly, what do you loose by switching?
Their setup for working in their real jobs? hehe. Actually my IDE doesn’t support 1.5 waiting for the chorus of “switch to Eclipse”
My Eclipse doesn’t support 1.5 (3.1). Must need to upgrade.
Regarding using 1.5, we’ll hold off for a while to let it settle.
queue singers
Not saying switch one way or another, but with IntellJ I can choose from 1.3 to 1.5 support per project I’m working on with a tiny radio button inside the project configuration
Waiting on 1.5 is fine. A little time for it to catch into the main stream of java development.
Just my 2 cents as a non-developer of jME. I consider jME to be somewhat of a cutting edge technology. I feel the longer jME, and many other developers, put off 1.5 as a requirement, the longer it is going to take for 1.5 to go mainstream. Thus, the longer it is going to take for jME to feel it can take advantage of 1.5. If 1.5 can in anyway improve jME and possibly speed up development time, I say go for it.
I wonder if jME’s user base is really large enough for moving to 1.5 to be an issue?
Again, just an outsider looking in on the issue.
1.5 is definately in the near future, but I don’t want to jump on it and make it a requirement after 1 day of it’s release. I’d like to get opinions of it on larger projects, so watching it for a month or so shouldn’t hurt.
heh, jbuilder also has such a project based config, but when I try to compile a 1.5 project it complains about class version numbers… I figure they are forcing ppl to pay another 3k to upgrade or something stupid. (as much as I love jbuilder, who can afford that??)
"renanse" wrote:
heh, jbuilder also has such a project based config, but when I try to compile a 1.5 project it complains about class version numbers... I figure they are forcing ppl to pay another 3k to upgrade or something stupid. (as much as I love jbuilder, who can afford that??)
IDEA is the only way to fly. ;)
Well, in my project team we’ve chosen to check, whether our framework will run under 1.5, but we’re not yet using its new features - mainly since we cannot make sure that all our customers will migrate to 1.5 in the near future.
I think for jME this restriction does not count, most of the developers, either those developing jme and those developing games with jme, could switch to 1.5. On the other hand, mojo is right about waiting 'til this thing has settled a bit. DotZero version from Sun/Javasoft are believed to be the real release candidates… 
Waiting a bit is probably a good idea, but there probably won’t be much need to wait too long. Sun has really focused on quality with this release.
One other small note… Some of the new features are just compiler-candy. That is, the byte code will not really be affected… it just gives you compile-time checking. I believe this includes generics and auto-boxing/unboxing.
Basically… it still does the type casting and/or object creation under the covers… It’s just supposed to make writing the source code a bit easier, not improve performance.
Just FYI.
That being said, I’m pretty interested in trying out some of the new language features, myself. Heck… people even seemed relatively up-beat about the release on slashdot, which is just inconceivable. 
–K
i cant wait for it to be integrated properly into eclipse, so I can get the AI stuff ported to it
DP
"Shmooh" wrote:
One other small note.. Some of the new features are just compiler-candy. That is, the byte code will not really be affected.. it just gives you compile-time checking. I believe this includes generics and auto-boxing/unboxing.
They have done it in they way to preserve as much compatibility as possible - and at the same time broken it in few other cases (increasing major number of class files and using StringBuilder instead of StringBuffer).
IMHO they could as well implement some of the changes with deeper jvm changes instead of staying 'mostly compatible' while not allowing running it on earlier versions on jvm anyway.
There’s a very good chance that LWJGL will have Mac OS X support before Mac OS X has Java 1.5 (based on the length of time before it supported 1.4). Therefore, we won’t be doing any 1.5 updates until it’s on the Mac, for our new Mac owners out there… Renanse.
It would be fun to have Mac support… I’m now all setup with Eclipse and java 1.4.2 on the mac… jME compiles too… Now we just need a mac compliant lwjgl.92+ and we can start addressing mac input issues and the like. yay!