I'd be relatively opposed to switching everything to jdk7. Java 6 is the current lowest common denominator and using java 7 at the moment will just alienate somebody I don't know the back story. Is libvirt compiled for jdk7? I'd be perfectly fine with compiling just the KVM driver with jdk7 as any distro that has a usable KVM implementation also has java 7.
So here is what I propose (which I think is what is already being proposed, but I'm just being explicit). We keep the maven settings to keep building 1.6 byte code. Only the KVM driver do we set it to 1.7. This means that we would then have to switch to using JDK7 for jenkins, eclipse, mvn cli, etc. As the majority of development is done in eclipse (i think), eclipse still sets up the projects to compile against the JRE 6 library (except KVM will be JRE 7), so that will help prevent people from accidentally using a JRE7 API in a 1.6 byte code format. And as a totally random note, OpenJDK7 on CentOS is way faster than OpenJDK6 on CentOS. Regardless of whatever we compile against, everybody should try use Java 7 at runtime. Darren On Wed, Sep 18, 2013 at 9:29 AM, Alex Huang <alex.hu...@citrix.com> wrote: > I don't have much problem with switching to jdk1.7. My eclipse is running > with jdk1.7 as the builder and it can't find any problems in cs code. The > main question I think will come from the Linux variants. Are all of them > shipping with jdk1.7 now? > > --Alex > > > -----Original Message----- > > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers > > Sent: Wednesday, September 18, 2013 5:10 AM > > To: dev@cloudstack.apache.org > > Subject: Re: [DISCUSS] Java 7, tomcat 7 and further upgrades > > > > Hey all, > > > > Sorry for the threadomancy, but the discussion have become relevant again > > with the current issues with the libvirt library. Of course this could > also be > > solved by updating the libvirt library with a jdk6 version. Still it > might be good > > to revisit this topic. > > > > It appears not to be possible to switch code style to 1.7 and produce a > 1.6 > > compatible binary. I remember this working with olders versions, but > didn't > > dig to much into this. > > > > So the new question in this thread will be, should we switch CloudStack > to > > jdk 1.7? > > > > Cheers, > > > > Hugo > > > > On Jul 1, 2013, at 12:45 AM, Prasanna Santhanam <t...@apache.org> wrote: > > > > > On Thu, Jun 27, 2013 at 04:18:40PM -0400, John Burwell wrote: > > >> All, > > >> > > >> I am +1 for Java7. However, I would like to propose ridding > > >> ourselves of Tomcat entirely and embedding a network stack such as > > >> Netty (http://netty.io) with a servlet bridge. We have one JSP in > > >> the system that generates JSON resources. It could be easily > > >> eliminated with a simple servlet that generates JSON from a > > >> ResourceBundle. Outside of this JSP. I don't see any other > > >> requirements for a JEE container besides hosting a servlet. We would > > >> gain a far simpler, self-contained deployment model (a single jar). > > >> Additionally, we would gain greater control of the startup and > > >> shutdown lifecycle, as well as, threading dynamics. If there is > > >> interest in this approach, I have thoughts on how to achieve this > > >> embedding and create a lightweight daemon framework that could be > > >> used for all CloudStack daemons. > > >> > > >> As an aside, I also think we should replace our hand-rolled NIO code > > >> with Netty as well. > > >> > > > > > > John - could you break this and other thoughts down a little more in > > > what's involved? Perhaps into its own thread. I don't know Netty. And > > > my J2EE is shaky at best. > > > > > > It's been a previous wish on this list to have the packaging of > > > cloudstack into a single easily deployable war instead of all the > > > complicated packaging we do. So I'd like to hear more of that and > > > other issues you describe. > > > > > > -- > > > Prasanna., > > > > > > ------------------------ > > > Powered by BigRock.com > > > > >
