 Okay, so we are letting the most interesting talk we have been waiting all day to hear for the end Tom Marble has been a contributor to this Benjava for many many years now And we really look forward to hearing about this exciting thing Thank you Pablo So You know, I know it's really a hard slot to be kind of the last slot at the end of the day So I really appreciate you coming out To hear about jigsaw and Debian This is really what I wanted to to talk to you about and just to give you a sense of what I want to cover I want to give you a sense of what I am and what I'm not going to talk about today for regarding jigsaw and Some of the background that we've actually already covered in terms of jar hell and and so on and how jigsaw is hoping to address that And in particular what it is about Debian that makes it a really good fit or there's a real good opportunity for us to leverage the work that's being done in upstream and then Some links and hopefully an opportunity to have further discussion about this and how we might how we might use it in the project So just a little bit about me for background I've actually got a master's in electrical engineering and that means I like hardware as well as software and I spent most of my professional life doing software and I spent A little over 10 years working at Sun Microsystems initially I was actually in technical sales, which was a strange Way to get into Sun, but it was pretty interesting and I learned a lot from that experience and as soon as I could I transitioned into Java R&D and Had a position in the Java performance group Which was a really an eye-opening experience really? Really interesting one of the things that we did was to automate performance testing for the JVM itself You heard Stefano talking about automating testing for for Debian earlier today, and I am a huge fan of that and then I you know I Actually started using Debian in around 2003 and in 2006 Sun had realized that Java was not very well integrated on Linux platforms and Decided to do something about it, and so I got involved in relicensing Java For redistribution, so this is only point one of the DFSG and is obviously non-free But represented an enormous amount of work within Sun to change the attitude and actually get the legal Team on board with relicensing Java So this was kind of controversial, but it was really the first step on the path to open JDK Which was a fully free implementation of Java and One of the things that's bringing me back to Java is I'm interested in a couple of different things one is software transaction Management Yes, yeah memories transactional software transactional memory Sorry and for large-scale systems, and then also I'm interested in embedded development and Java seems to be a really good platform for those two things so what I want to talk about is really just specifically about You know kind of what the goals are for the jigsaw project and a little bit about it and Really focus on what's relevant to Debian or what I think is really appropriate to discuss with Debian But but that's only a part of the story of jigsaw I'm not even going to try to Cover all of the technical elements of jigsaw It's it's fairly involved. I'm also not going to try and talk about open JDK in general but modularizing the JDK involves touching many many parts of the platform There are language changes VM changes class file changes compiler changes and Mark Reinhold gave a really excellent talk at Devox, which is linked off of the jigsaw website that gives a great overview of the project and Some of the approaches that were taken and in particular one that I found really interesting was discussing refactoring the JDK and Some of the struggles that they had in doing that As many of you know the JDK brings along with it a whole bunch of stuff like Corba and XML and all sorts of things that you know your application might never use and yet It's we're stuck with it and so there's some really good I'd really recommend that presentation to get some more detail another thing that I I could be tempted to talk about but I'm not going to our earlier efforts towards modularizing the Java platform notably JSR 277 and Related JSRs and I also don't want to get in too much to debate about OS GI although we talked a little bit earlier about how OS GI is really an approach to handling modularity above the platform and The idea of jigsaw is to actually make it a first-class citizen inside the platform All of you know what it's like to be in hell Jar hell is a particularly nasty flavor of hell And you know in Debian we've enjoyed being Elevated away from hell for a long time, but for Java unfortunately it remains I was actually amazed to find that there's a wiki page that explains jar hell But there is and you know just to recap some of the highlights There's this problem of have if you have multiple versions of a jar on a class path You may get some from one or some from the other or a little bit from both and that of course causes a lot of problems It's quite possible that your dependency graph has a mismatch somewhere where you know dependency a requires You know c and dependency B requires c prime and c and c prime were conflicted so that that causes a problem But the thing that we're most familiar with in trying to package Java is this darn thing about how People seem to be comfortable sticking binary blobs in their upstream And that is of course the source of a lot of refactoring trouble. So what is jigsaw? This is a mercurial forest which is based off of open JDK trunk So open JDK along with a number of other Sun now formerly Sun open source projects chose mercurial as the version control system and So there is a mercurial forest of jigsaw that you can get from the open JDK website and the idea is that the JDK is handles both mod modules and versions as You can see so that we never get into the situation where there is Ambiguity about which version of a module is being used and in short The goal is to get rid of the class path so The approach that jigsaw is taking for these requirements is implemented in the following features. So one of the one of the challenges about Speed and also predictability of which version you're going to get is going to be handled by resolving some of those issues at install time Using a kind of registry system Feature subsets as I mentioned your application may not need all of the apis that are in the JDK so it's really doesn't make sense to drag them all along and Multimodual packages will allow you to select just that part of the dependency graph that you actually need and By the way, the idea is that this will apply not just to the JDK, but also to user applications as well Substitutability, I'm not even sure if that's a word, but I took that word from Mark Reinhold Is this idea of having a virtual module or you know what we might say in Debian as it provides? So this is really a completely uncontroversial concept for Debian But it's kind of new for Java as is having optional modules And the idea of self applicability is that this actually applies to the JDK itself So I'm stealing a slide here from Alex Buckley's presentation about jigsaw I don't want to go into too much detail about you know the technical implementation of jigsaw for the most part. You still have directories like comfoo, you know my compilation unit dot Java and Organized in a tree the difference is that you have some magic Java files called module-info dot Java or Package-info dot Java which are in your tree that give the metadata that you would otherwise get from let's say OSGI and So what this slide is showing you is a way of handling multiple versions of modules and explains that Java C may have its own version of a particular module and it has its own resolution system for choosing which one is The right one and the one they refer they refer that to that as the magic class path, which is actually inside the running JVM One of the tricky points and I'll just make this aside now about about Leveraging the modular JVM is that the heuristics for the JVM doing this Resolution of which is the right version may differ from the heuristics of P package So that's something that we will have to to to watch carefully But here's the promise right today if you just take open JDK 6 You know on disk It's 136 megabytes if I have a hello world application I can you know just a very simple hello world application 425 bytes I end up with an enormous amount of consumption just around hello world But if I was I took a stab at trying to Build hello world with jigsaw with just the essential base package and I'm guessing that it's 30 kilobytes And I'll you'll become obvious later why I don't have the exact answer here But the idea is that you know we can cut down our on disk space and in memory space Significantly in fact performance is a huge huge motivation for jigsaw so the whole idea and I have to give a lot of credit to upstream because they they have looked at Debian as an example of Why this packaging or this modularity would would be applicable and how it would integrate with an operating system And their idea is very deliberately that there would be a one-to-one mapping between Java jigsaw modules and Debian packages So you have this sort of idea and this is what the kind of Syntax that you might see within a module dash info. Java file is My module with a particular version provides a virtual provides a particular version and has a certain number of depends Or as they say requires There are other constructs that are in the Description of a module there's one that I Understand why they did it, but I think it'll be really difficult to to map that carefully into Debian And that's this idea of a permits statement and the idea permits is that they're basically saying that My module will only permit The specified set of modules to depend upon it it's as if it's controlling who can have an art depends on it and The idea is that that way you could conceivably have a secret module somewhere and that concept doesn't map particularly well into Debian, but I just thought I would mention it So this is obviously a complete abuse of trying to map jigsaw to Debian So I just picked one job application at random which is free mind And at the bottom you see some excerpts from the control file and at the top I tried to put in you know sort of roughly what you might see in a jigsaw module declaration Obviously, there's there's a there's a couple of things that you notice right away In in Debian, there are a lot of different expressive ways that you can Did talk about version relationships? We had a really good discussion earlier about what does it mean to have backwards compatibility and again? One of the great things about Debian is that Debian packages have a version string And it's very well-defined and you can do a compare on two version strings and find out which one is later and my understanding from jigsaw is that they're kind of leaving that version string to be completely free format which means that comparison is going to be very difficult and You know understanding what what's compatible or expressing the kinds of things that you can express in these operators here might be very difficult that being said I think that there is There's something to build on and this is just in one way of highlighting the mapping between jigsaw Debian So one of the things that comes up a lot with upstream in particular is Deploying a solution is or deploying new functionality in the Java platform is rarely done or is it well Isn't done unless it can be done in a cross-platform way And this is where Debian has a really I think unique opportunity to leverage this work of modularizing the JVM There's all these benefits that we talked about for modularization But if you think about it, there are very very few operating systems that can actually do this, right? Debian obviously has all the infrastructure to handle this and do it really well Other good new Linux systems could do this a bunch who obviously could inherit this very easily Fedora probably could as well although as I mentioned there will probably be some fuzz as any of you who've tried to harmonize the Fedora dependency graph at the Debian dependency graph. It's not exactly a one-to-one mapping. So there's a little bit of fuzz. I Don't know a lot about BSD. I know that there are various approaches to packaging in the BSD world So there that might be possible I Just had I just I just met someone interesting the other day from Nexenta who pointed out to me that there is going to be an announcement tomorrow That might have an impact on People that are passionate about open Solaris. I don't know anything about it I don't know what it means if you want to know more go to alumos.org and get the announcement of that Obviously open Solaris or Solaris historically has suffered from a horrible system 5 packaging system And there's a new packaging system called IPS Which is hopefully a little bit better and if those of you have seen something like Nexenta Which really leverages Debian packaging you see how much even better that is but there's an opportunity for jigsaw to work with that I don't know a lot about Mac OS development But my experience with it is it's kind of wonky and I think it'll be there isn't really this there isn't really the the discipline of Decomposition and interdependency that we have in the Debian world and of course windows is completely a nightmare as there's no Infrastructure for handling this and it would have to be almost developed from scratch So for that reason Debian is uniquely qualified. I think to handle to handle Modularity in the Java platform So one of the neat things that that upstream did is they created this this Program called j-package and it's really nifty. It's sort of like It you know, it's sort of like Java helper if you could imagine that being upstream And what it does is it takes all of your all of your Java class files And it does something magic and out the end you get binary devs What yeah, right? I mean, it's really cool, you know, um Except there's a couple of little problems, which I'll get into in the next slide One of the things that I appreciate is that they included a demonstration of how this works And I wanted to highlight the path for you because you might not you might not stumble across this in the tree in the Source tree for for jigsaw It says it's in this directory that says Solaris But then in the make file down below it says this will only work on a Debian system, which is I think pretty pretty funny But you run me I didn't actually do this because you look at the code and you run make and it runs this shell script Which ends up doing a bunch of d-package Installations and removals and some other things that are you know You might feel a little bit uncomfortable trying to do on your live system I actually tried to do that in a charoot and had some trouble with that as well and Right here. You'll see why I went to install the base module from jigsaw on my shiny New Debian charoot and you'll find out that just something trivial the version number doesn't comply with Debian policy And so that makes our tools barf And we can't install it Which is really a shame And I think that their idea and I you know mark says in his talk that they want it to be very flexible about version strings But the trouble is we can't be flexible about version strings without breaking Debian So we have to we have to handle that problem And of course the one that I knew was going to be a problem is all the other parts of Debian policy I couldn't even run lintian correctly because of the the version string thing, but already you know You see there's a whole button. This is just one of many packages So there's a lot of stuff to do to get if we want to get this packaged correctly so you know What's neat about what jigsaw has done is it's broken the JDK up into? 126 different depths And That's really neat and here I've from Mark's presentation. I've stolen a graph I actually created an actual dot file from for graph is of the 126 packages But I knew you wouldn't be visible at the resolution on this screen And maybe I'll do that in SVG and publish that so you can play around with it, but Here you can see big chunks of functionality that I'll show you big sort of clusters of functionality and jigsaw so that if you really only need the base Module you don't have to get all this other junk or if you're doing just a gooey client You don't need all of this other junk and which is which is really really nice I Hear I don't know exactly what precedent there is in Debian for having a source package produce 126 or more binary packages, but I'm guessing this might be a little bit awkward And we might need to think carefully about how to do it Should just work okay Well, that's that's what I love about Debian is stuff just works So Why do you want jigsaw? Well part of it is smaller download size smaller size on disk Obviously smaller memory footprint and because of that you get faster startup time Most importantly is that we'll get you know module versioning that matches Debian and hopefully Have a basis for solving jar hell in all of our upstream packages that were we're packaging So there's a lot of reasons why it would be nice But I realized when I was sort of talking to people about this and thinking about it That this is actually part of a larger issue that I want to bring to your attention And that is what do we do about Java free Java and Debian going forward a long time has come has You know has gone since you know JDK 6 came out JDK 7 hasn't come out And I'd like to speculate just a little bit about what is the future of upstream because I think it might have a bearing on What we decide to do You'll notice for those of you that have been following the Java community process that there isn't a platform 7 JSR Which is kind of the upstream approach to deciding what is JDK 7 and this is Due to the long-standing among other things probably the long-standing debate between the Apache software foundation and formerly Sun about the field of use restriction and in Java and As a result the JCP has basically been stalled and so the question That I think we all can ask is what does it mean for? Sun Java 7 or what what? Can we make any reasonable prediction about a release and make any release kind of decisions around that and I Think that it's very hard to know I've pressed my friends at Oracle a lot for answers to this on and off the record and They basically can't tell me anything so I don't know what we can infer from that I know a lot of work has gone into this you'll see on the on the open JDK website There's a whole calendar of milestones that has been followed But that calendar of milestones doesn't list any milestones after September of this year So I don't know if that means that they would plan to release at that time or they'll make more milestones or what would happen That being said a lot of cool development has gone into JDK 7 alpha if you will end up stream and I think that Debian is in a position to consider packaging that There are a lot of features that are in JDK 7 and I put a link here in the slides and I'll show the slides Couple of things that I really want to call out to your attention. One is jigsaw one is the modularity Another one is tail recursion is supported natively and this is potentially a huge huge performance benefits So the just to give you a sense of this If you have Function a that calls function B and function B that calls function C Every time you change that context you've got to push things under the stack change change your context and go to the new function And the idea of tail calls or tail recursion is that you can basically push things In such a way that you basically transition from a to b so that when C finishes it returns directly to a So if you have a recursive Function, you're not going to pay this huge penalty of bloating the stack with a bunch of return values That basically are sitting there that you don't really need all that stuff on the stack at all collapses at the end when the final call is done So I'll explain why that could be pretty interesting in a second Lambda expressions anonymous functions are supported in in open JDK 7. There's the invoke dynamic by code Which is been shown to have some huge benefits for interpreted languages like Jay Ruby and Jaitan That that's related to that you can garbage collect Dynamic classes or that's separate I think that it's separate Did that made it to JDK 7 or invoke dynamic? Yes, I know the garbage collection of dynamic Recreated classes. I don't know Another another thing is some of you may may recall from Java 5 one of the things that was a big addition There was the concurrency utilities from Doug Lee, which was JSR 166 and there's some new extensions to that and JDK 7 Called fork join which is just this idea that you can create kind of a pool of Subprocesses and then collect the results later so in terms of a different metaphor or tool for parallelism That could be a good one And so as we get into obviously more and more multi-core and multi-CPU systems doing concurrency I think is going to be really important So what are the applications of modularity? Well Obviously one of the ways that we could use this is or use JDK 7 in general is to support all the new features, but it's specifically for modularity. I think it could be very helpful for Things like mobile and embedded where you really need to have a small footprint You need to have short startup time and some of the other performance related features could be really important for other JVM based languages like Clojure and JRuby and Jython and so on and in fact one of the things that I mentioned about My interest here is Clojure in particular because you know I like you know working in a Lisp dialect probably even better than I work like working in the Java programming language And Clojure is a really interesting take on this. It's based on the JVM and it has a lot of idioms for concurrent programming and immutability and so on and it is getting a lot of attention as a software transactional memory Architecture so for high-performance systems I think it's a really interesting thing and wouldn't it be great if we could build Clojure to take advantage of tail calls and fork join and we could do that within Debian and Before all of the committees necessarily settle down and decide exactly, you know how they want to standardize that on the JVM language summit wiki there is a list of Requests to upstream for improving the JVM and Rich Hickey who's the author of Clojure has a number of things that he wants out of the JVM Some of which have been done some of which have been worked on some of which haven't been started yet One of the things that I'd love to do is I'd like to I'd love to have something like a shebang like been OJC Where oh is open JDK? J is jigsaw and C is Clojure where we could have let's say Clojure script In a text file and have the startup time not be completely miserable and have it handle things like standard out and centered Centered in right I mean it's possible that we could do that and have that be you know a Reasonable way of doing quick closure programming so I mentioned a little bit about performance a lot of the promise of jigsaw has to do with performance and You know one of the things that I've learned in my travels is that Especially with the JVM. It's really important to measure the impact and performance as opposed to just rely on your assumptions The JVM is really a remarkable piece of machinery and does some very very clever optimizations It's very difficult to predict how it will behave without actually trying it And so one of the things that I think this drives me. I interest in and I'm just mentioning this is into Performance analysis tools to help measure the impact of these different changes So and this is another sort of take on Stefanos. I think call for more automation There are like these four different kinds of things that we would want and I haven't actually looked through the archive to see how much of this Would be useful and especially in Java, but you know We need a benchmark harness that actually runs benchmarks collect statistics and so on obviously benchmarks themselves that Hopefully represent a workload that is that is meaningful It's actually very difficult to write a benchmark for the Java platform that does what you think it does because the JVM is doing so much optimization That you think that you write a loop inside a loop inside a loop and actually the JVM unrolls the whole thing and declares a dead It doesn't have to execute anything So benchmarks are important then once we get the data aggregating it storing it in a database of some form is Important and figuring out a way to share it and then also visualization obviously comparing the things that are comparable and Being able to draw meaningful conclusions from statistics is is really important one of the things that we did at Sun was leveraged a Pretty high discipline of statistics And specifically the students t-test before we would actually make a determination that some code change had a meaningful performance impact So what's next or you know, this is you know as they used to say in shot of Jack just the beginning of the conversation so we could consider Jigsaw is part of our Java policy discussions I think it's it's worth thinking of the pros and cons of what it would mean and in the large kind of what it what it might Mean to support Open JDK 7 even though upstream hasn't formally released Open JDK 7 yet and I have some links here for the jigsaw project and also The recent JVM language summit that has some really good slides from a notable a Java to engineers throughout the industry that you know I think you'd be interested in to see the kind of work that's going on In upstream so with that are there any questions? so on the the j-package stuff that you'd mentioned earlier the I'm I I would tend to shy away from those sorts of tools Mostly because they have a tendency to reinvent a bunch of things that are in Debian But they usually be if upstream is doing it they do it in a fairly static way Unfortunately, a lot of upstreams have a lot of experience with RPM packaging where the RPM most for the most part RPM packages And how they're done mostly don't change they haven't really changed that substantially in quite some time So they they treated as something where okay, so I generated an RPM RPM installs I'm good and I move on to the next project and look at something else Debian packages actually change a lot and so anything that's not using something like Deb Helper At the bottom level to do the actual package assembly has a tendency to break when policy changes and I don't know how they put all that together But for example the the bit there where they're using Sudo d package dash I to kind of to build an environment. They're sort of reinventing that was just to do That was just to do a particular Demonstration, but it's the kind of thing that you You would not want to just start that script and let it rep because it'd be very uncomfortable with that Yeah, I mean if we can encourage them to You know what what helps a lot is if if they if we can try to sort of work with them to provide You know here's a Debian directory and then we can patch that Debian directory They've got a Debian directory that they can sort of run Debian rules build on and then but we can contribute back You know here's the changes you need for the next version of policy for the next thing that's changed I actually think that they would really welcome these kinds of proposals You know just say you know gently that you know your version string actually does matter You know we we can't have underscores in it and Also the you're absolutely right I mean absolutely you know because Debian policy is going to evolve and one of the things I want to call your attention here is that they have They have a lot of module names that are of the variety JDK base or JDK boot or you know those sorts of things And then that becomes the lead part of the Debian package name using the J package tool Well, we probably don't want to do that I'm guessing we might want to prefix this with something like jigsaw dash seven dash module or you know something like that Right or you know look maybe looking at X the way X org does it is a good inspiration for How to how to handle it? I wonder what happens During the Debian creation, I think most of this metadata is just written into the job manifest or what does the tools do You mean you're talking about the I can probably can use jigsaw without Debian So it Spreads the data somewhere into the job. Yeah So so it becomes the module dash info Java turns into a module info class and that just becomes part of the jar And then but but it but it's a good point because because Obviously the class loader in the VM have to be smart to know that to know that they're dealing with a jigsaw module system And to read that class and then to you know behave appropriately Okay, so what do people think does it? Do you do you like the idea of getting some of the new JDK seven features including modularity or is it biting off way too much? Hell yeah, I Mean I was hearing what you were mentioning that the JDK seven is a little bit in the limbo that sounds a little scary Well, it is a little scary But you know, I think that I Wish we could get I wish we could get Oracle to make a definitive statement about you know You know, this is what we're gonna do and this is when we're gonna do it But in a lot of ways because of the Java community process, they can't unilaterally make that decision anyway So they could express their intent of well, we plan to go to the JCP and propose a platform 7 JSR But I actually wouldn't expect them to make that kind of declaration either So we kind of have to view this as a little bit of a risky you know upstream trunk that is a moving target and as I mentioned there are some if we go down this path there are some subtleties like the way that The jigsaw VM resolves Dependencies versus the way d-package does and we'll have to we'll probably end up tripping over some weird bugs as a result of that But there might be some really interesting upside in in doing it too. So might be worth giving it a shot One of the one of the things that I was speaking the other day with Matias about the issue that you bring up Pablo which is all the different architectures and and so on and one of the challenges that we have is that the Hotspot compiler doesn't build on some of the some of the minor architectures And so, you know, one of the questions is is it good enough to have a jet on those architectures? You know, how violently would people complain as opposed to using GCJ? That's one of the one of the questions that we'll have to ask As someone who knows very little about Java because all the disconnects that we've been talking about and you just sort of go I can't be bothered. I'll disinstall it again This description makes it sound very tempting Because you can just install a little bit of it and I if we were to package the version 7 stuff What do you think the chances in 10 years time that Debian will be upstream for Java? Well, I think it's a really interesting question and you don't even have to qualify it with the 10 years time because the The challenge is that the other operating systems simply can't Do what Debian does very easily Especially especially windows So if we figure out how to crack this nut and answer all the issues that everybody brought up today Matthew and Torsten and Pablo and Nielsen We figure out a way of solving these basic issues and then we can do the modularity right in a clean way We will absolutely be the upstream Because Yeah, I just Well really say plus one I recently changed jobs and I have to work with some CLR nuts And they give me all kinds of grief about Java is completely stagnant It's falling behind it. I mean during your presentation here. I'm thinking wow, you know, we get this into experimental We may actually start attracting Developers just to Debian just the distribution itself because we have it and no one else does Right. Just imagine if we actually get closure to work with fork join and tail recursion on you know God knows a 64-way system and it totally rocks over, you know, what you get out of the box That might cause people to say wow, what is this Debian thing? I think I want that Yeah, and then just a question I guess maybe for the for you in the room at large then this what what kind of risks do we see? I mean, I understand we'd be building off the upstream Trunk it's not actually really released yet Would we be perceived perhaps as the group that you know, if they change direction radically then They see it that Debian waffled on this whole thing or I just curious that I don't know I think that there's a much more practical concern Which is that this is really complicated stuff and I don't want to minimize the fact that There are changes in the VM and the class order and the files and all this and I I don't claim to understand it I mean, I know some of the engineers that that work at Oracle that are super smart that has spent a long time working on this and The the risk that we run especially if we become the upstream is that then we need to maintain Kind of the inner inner workings of it, which is a pretty tall order You know and me, you know, so I think it's I think it's it's tempting, but it would be a huge challenge, too I mean the reward that I see is one of the things that we five have to fight all the time is people who don't feel like Debbie is a viable platform for doing, you know, heavy Java development I think that's something that we've had out there for a while because of the Sun Java not being in the archive for a while and So and just that perception that's built up and this I mean the reward that I see here is we could reverse that overnight I mean if if Debian is the one that embraces what becomes open JDK 7 and really understands how to do the packaging properly and Solves the dependency problem, which is I mean, there's a bit of a fight You have to convince a lot of Java developers that they have a dependency problem because they ship more files But I think that if you can convince them that of that and kind of point and having a working system That it really does it right is a great way of showing what you can do when you've got a full function dependency system that we could It could leapfrog basically I mean it's a lot of work and that's the question is can we find the people who can do this stuff and get them to work in Debian well And maybe if we can take what Nielsen and Matthew were talking about of automating things and building more into Java helper, you know maybe we can reduce our cost of Bringing stuff into the correct level of dependency stuff and really show that you know It's a best practice kind of environment and and get to that that level you're talking about I know at Stanford we're facing we've got a bunch of five applications in Java We're taking over from another group and we're looking at you know Basically a bunch of war files and you know 47 copies of one particular internal Stanford jar and you know 20 different versions And you know this is what the package manager solves for you And if you can introduce that concept into the Java community and show them how it works I mean that would be huge and I love Java's it's I've talked to so many people who say I love Java's a language Java's a great language the deployment mechanism from a system administration perspective is horrible and I you know Because it doesn't work with that kind of level of tool and you have these war files over the place They're opaque and then you get a security vulnerability in one of your dependency jars and And this could resolve to me the biggest issue that everyone faces with Java Well, and you're sitting at Stanford and you look at this 47 different copies of the same thing and you're saying There's a better way exactly yeah, and you know and this is stuff that's already using Maven to do to do builds and It's just if we can hook into that system and then sort of get closer into the way Java developers think about this stuff I mean one of the things that was huge I that happened recently is having eclipse in Debian in Debian unstable you install it and it works I mean wow that was great and You know the more steps we can take down that path I really do think we have a huge opportunity here to pull a bunch of mind share Because you know if you look at the stuff that's out on the web Or they try to analyze you know who's who what people what are people writing code in you know What what's the most popular language is what do people talk about what where they people writing books? Java's Way up there at the top if not at the top almost all the time. It's become sort of the You know I don't take this wrong But it's become sort of the the Fortran of web programming in the sense that everybody keeps claiming that it's dying or going away And yet if you look at the actual install base of the code it is what everyone uses we could have talked about it It's the cobalt you know which is a little bit more derogatory similar sort of idea I've come from a more scientific background than a business processing background, but yeah you pick your analogy I actually you know all admit. I really don't like the job of programming language But I I have come to appreciate the power of the JVM and what it can do on a multi-threaded You know kind of environment and how much work has gone into performance tune that thing and you know I might want to do my high-level programming and something like closure But that is going to be based on a really powerful foundation and you know I challenge you to find something better than the JVM to do that And you know and even even you know one of the things one of the comments that came out earlier was one I just use GCJ instead of MVM. Well, you know in a number of cases we were seeing and you know some of this data Is getting old now that dynamically optimized Java outperformed statically compiled Java because of all the clever optimizations that are going on you pay a little bit of a penalty up Front to warm up the hotspot, you know Compiler, but then you get those those that you know that additional benefit back And the other thing you know which is interesting you hear you'll hear Keith and Bdale talking about is you know If you want to do a cross-platform GUI You know Java makes that pretty easy Well, the other thing that is you know the huge issue everybody's talking about right now too is mobile app development And well some of the mobile platforms are pushing people away from Java Some of them are embracing it as the language to do mobile app development And if you can prototype on Debian and deploy on to a mobile device That's a really appealing story to tell people about why they should use Debian why Debian is interesting right? And so for example, what if there were you know, maybe as a result of the Lenaro project some really nifty very powerful hand-helds that could run Debian natively and let's say the module system and you know have a very Powerful result and very low footprint. I mean that'd be pretty cool You had a question You mentioned the long or extended JCP process and I wonder if I'm talking more about the engineering side And has that given the Seven line a little more chance to mature So I wonder what your opinion is on the status of the completeness and our stability of seven That's a great question and I was trying to answer that question for myself in preparing this talk and I was looking at the The page on open JDK about all the features in JDK 7 and they list some of the things that got Descoped and that aren't going to be part of it at the bottom, but for the things that are in flight You really don't get a sense for how mature they are I think it's very difficult to know really what the answer that question is so What I can say is that that that son, you know I presume Oracle now it has had a very very highly disciplined and methodical release process and As they get close to a release they're very thorough about bug triaging and Because there isn't an eminent release. I'm sure that that process hasn't happened yet Which would cause features to either get solidified or ejected so That's a little bit of the uncharted territory that would be going into One of the one of the sites that would be interesting to reach out to about this is Google Because they have extremely heavy Java use inside inside Google and they're also extremely heavy Ubuntu shop So there's I think there's a lot of potential there It's you know to contact some of the devian developers inside Ubuntu some of the devian developers inside Google and ask them if You know sort of start circling the idea inside Google and see if Google is interested in you know in some of these features And if they might be able to volunteer some time of the of Debian folks inside inside Google or an Ubuntu folks inside Google to help make some of the stuff happen. Oh Well, if I was playing devil's advocate, you know, maybe if I was Google, I would look to you and say well we've already got the Dolphic VM and Your idea is really nice, but you know show us the working code. I You know, I don't want to poo poo that idea. I think you're absolutely right and and you know to the point about You know large-scale distributed processing. I mean who else is doing that kind of scale of Processing and if they really are using it internally then You'd think that that even even so it's not the mobile device that they might be very interested in it Well, it's true that a lot of the senior Sun engineers would eventually go to Google I know many many of them did so It's it's it's an interesting thought and Yeah, it's a good idea I had a conversation with a friend of mine at Google a while ago Who was telling me how much work Google was putting into making GCC better and I asked him why? Just sort of on a business sense. Why are they doing that and he said to save electricity? Because their operational costs right now the amortized cost of a machine per year is about equal to the cost of electricity For that machine per year and so that just kind of got me thinking in general about you know, if there are ways that Kind of an innovative business case can be made for some of the stuff too. I don't know just throw something out canonical You know is there's some economic argument that could be made for that If people have ideas regarding that business case frame of mind That might be a little bit weird sounding at first like like the electricity thing Well, it's not I mean I'm actually you know one of my other passions is around smart energy in the smart grid And I think that we could do a lot with free software to save the planet So I think there's there's a really great there's a really great tie-in there But from a just I hear today practical business point of view Yeah, if you do if you can take some performance optimizations out of running our application You could save potentially a lot of electricity a lot of heat And ultimately a lot of money by doing those things Yep, okay Let's thank the speaker