I know rhel6 has jdk6 as the default and jdk7 is also available. Seems silly to target 1.7 for a redhat project. If libvirt can just target 1.6 I think that would be ideal and then we can just not change anything on our side. Somebody can correct me if I'm wrong, but I see the vast majority of projects targeting 1.6 unless they really need to use a 1.7 API, which isn't all that much. Java 8 is going to be the next real jump that most projects move to as, similar to 1.5, it has real language features people want.
Darren On Wed, Sep 18, 2013 at 4:02 PM, Wido den Hollander <w...@widodh.nl> wrote: > > > On 09/18/2013 06:51 PM, Darren Shepherd wrote: > >> 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. >> >> > A new version of libvirt-java was released, but the RedHat guys compiled > it with jdk 7. > > I already got a patch in at libvirt-java to set the target version to 1.6: > http://www.libvirt.org/git/?p=**libvirt-java.git;a=commitdiff;**h=** > 26efdef08b0d34b75fcd5930b6510d**acc14f6637<http://www.libvirt.org/git/?p=libvirt-java.git;a=commitdiff;h=26efdef08b0d34b75fcd5930b6510dacc14f6637> > > I hope to get the 0.5.1 release soon which is 1.6 compatible. > > > 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. >> >> > As far as I know both RHEL/CentOS 6 and Ubuntu 12.04 have JRE 7 in their > repos, so it's no problem on the packaging side if we target those two > platforms. > > Wido > > > 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 >>>>> >>>>> >>> >>> >>
