Andrew, I understand your position (indeed we have enough problems to solve). Let's see what others think...
Perhaps a solution : http://retroweaver.sourceforge.net/ Though if you have not the souce code and only jars this is not a solution :( What Sun says : http://java.sun.com/javase/technologies/compatibility.jsp (sources shouln'd be a problem) Using release mechanism for such a change is surely a good idea. Yes it's a little bit faster, on POS it's significant (I think because of the bug I reported below) Jacques From: "Andrew Sykes" <[EMAIL PROTECTED]> > Jacques, > > My concern would be that once you introduce these features the code is > no longer going to compile unless you use 1.5 > > I remember there was a big problem for us between 1.3 and 1.4 because > the WorldPay libs we were using were not compatible with 1.4. > Fortunately we were able to just continue using 1.3 for a while, but of > course that would have been a real problem if there was suddenly > incompatible code. > > I don't know of any issues like this with 1.5, but I'd hate to discover > one 5 minutes before home time on a Friday! Hence my cautious attitude. > > Perhaps we could introduce a single 1.5 code instance somewhere which > would enforce an upgrade. This would mean that we could watch for > feedback on the ML for a while and offer an easy fix for anyone who was > experiencing problems. > > Alternatively perhaps it would be a good idea to wait until the upcoming > release, then if someone has problems, they can simply revert to that > release. > > What do you think? > > You make an interesting point about speed, I've not run ofbiz with 1.5 > yet - is it noticeably faster? > > -Andrew > > On Tue, 2006-10-03 at 11:40 +0200, Jacques Le Roux wrote: > > Hi Andrew, > > > > My comments inline. > > > > From: "Andrew Sykes" <[EMAIL PROTECTED]> > > > Jacques, > > > > > > What features do you have in mind? > > > > C# like (notably foreach like loops but also autoboxing, enum type and > > varargs) > > For more please see : > > http://java.sun.com/j2se/1.5.0/docs/guide/language/index.html > > > > > Stuff like autoboxing and foreach loops would probably reduce the > > > overall code size, but would also stop people from using an older JDK. > > > > Yes, one day or another we will have to do it anyway, why waiting ? > > It's not difficult to switch from 1.4 to 1.5. > > They are some bugs solved (notably this one which was annoying in POS > > (block debugging in Eclipse, ok in NetBeans) : > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6330496) > > And last but not least it's faster :o) > > > > > Removing support for 1.4x might mean people's proprietary modifications > > > or libraries cease to be compatible. > > > > Yes that's might be a *problem*. Are you already aware of such cases (or > > anybody else of course) ? > > > > > Are you suggesting this change for existing code or new code? > > > > I was thinking primarily at new code. When refactoring old code (bug, > > improvements, etc.) 1.5 new features may be also used. > > > > Jacques > > > > > > > > On Tue, 2006-10-03 at 07:56 +0200, Jacques Le Roux wrote: > > > > Hi Developpers, > > > > > > > > Now that JDK 1.5 is no longer a problem I propose to vote on using 1.5 > > > > new features. What do you think ? > > > > > > > > Jacques > > > -- > Kind Regards > Andrew Sykes <[EMAIL PROTECTED]> > Sykes Development Ltd > http://www.sykesdevelopment.com
