 Well, I can start it. Thanks for coming to the OpenJDK blog. I'm Tom Marble. I'm the OpenJDK ambassador. And so what I want to really do today is give you sort of an introduction to what's going on with OpenJDK as an upstream provider of source code to Devian. Then talk about what is kind of the big issues on the free Java packaging roadmap, and then talk about some issues with Java policy, both now and going forward. So I'm really excited to see you all here. I'm hoping as a result of this that the main thing is that Java can get to be an essential tool, possibly even part of the tool chain within Devian. Now that it's free software, it can get into main. I think it's really exciting for Java developers that have done a lot of work to package Java applications. And based on the work that people like Doko have already done on integration, I think that Java can work really well with the Devian system. So with that, just a brief recap of a timeline for the OpenJDK project. I'm sure many of you already know this. But back in November 13th, we announced the license choice for open source Java, which was the GPL. We use the class path exception exactly like the good and class path project, which means that if you're a library or application developer, you have complete free choice whatever license you want to have for your library application, which we thought was really important to give developers the most freedom. So what is OpenJDK? OpenJDK is JDK 7, which is the next release of Java. Today we're shipping JDK 6 on java.sum.com. And it's also shipped within Devian in the non-free archive. And November 13th, we released a code for just the hotspot virtual machine and the Java compiler and released that on java.net. So that was the first time we announced our license choice. Then recently, last month, we announced the full release of the source code that we have for OpenJDK. We did this on May 8th at Java 1 in San Francisco, which was just a few weeks ago. And with this, what we released was all the source code for OpenJDK that we could release under the GPL. It turns out that 4% of the source code we do not hold copyright for. And because of that, we could only release that functionality as binary plugs. We did that so that you could at least have a fully buildable OpenJDK that would function. And our goal is not that we would live with these binary plugs, but it's just a temporary measure until we can replace them with open source equivalents. Because it's very important, we know, for us and for you to have 100% open source implementations for Java. So what we have today is we have source tar balls and read-only subversion repository on the OpenJDK.java.net site. And as time goes on, we hope to build up that infrastructure. It's a little bit limited right now. We have basically some web pages. We have the mailing lists. We have the source code. And we're hoping to build up all other sorts of things. For example, we want to have more dynamic content. We want to have a host of Wiki. We want to bring back our OpenGrocks source code browser that we were using for Hotspot and Java C after November 13. We've decided on Mercurial as our distributed version control system. And we'll have Mercurial repositories available on that website, both for the mainline trunk and also for experimental projects. And we have a number of tools, both for building and for QA, internal to sun, which right now have a lot of internal sun network dependencies that we're hoping to get rid of and externalize. One of the, perhaps the most important, thing you'll see first is whenever we commit code, there's a code review process that goes through, we're multiple eyes can review a pass that's going in. We have this thing called a web rev, which basically is a series of web pages that shows you for each source code file that's changing the diffs for that file so that it's easy to see in one change set, all of the changes that are included. And we're working on a solution to, even though right now those are published internally, we're working on a way of making all that information visible on the outside, even if it means tearing up some HTML and posting it on the outside. But we'll get more of those tools on the outside as soon as we can. One of the things that you'll notice is that it's not in the source code right now, it turns out it's not part of the Java SE platform definition, is the plug-in code and Java Webster code. Together we call that deployment code. I know that this is very important to you, especially for those of you that run on AMD64. I'm very sensitive to the fact that the lack of a 64-bit plug-in is something that you want. This is RFP number three for all of Java. So I know that this is something that everyone wants and I'm pushing really hard at getting that code released as well. Many people, we've already talked this week a little bit about supporting new operating system and chip architecture ports. In the context of Debian, this really means Linux, PowerPC, Linux, Spark, Linux ARM. And so I think that you'll see new activity here. We do have some additional source code that we can release that I think will help in doing these ports. And I hope to get that released as soon as possible as well. On sort of more of the medium-term roadmap, one of the things that we're going to release is some testing code that's the testing compatibility at the TCK. The TCK is especially important because the TCK is the way by which a runtime can be certified for actually complying with the Java specification. So for example, Sun is very keen on Debian shipping 100% free Java. And we really would love it if we can have it pass the TCK so that it can get branded as Java compatible. As you know, branding is sometimes a tricky thing. And I'm exquisitely aware of a lot of the branding challenges that have gone in the past with other upstream software. But this is something that we really want to do. We know that the TCK has to be available free as in beer at least. And I don't think that we'll be able to release the TCK as free as in free speech, at least not initially, but at least free as in free beer. And figuring out how to get that done with Debian is one of my priorities. I just want to say a word about upstream source code. Java is an extraordinarily complex project comprising something like 6.5 million lines of code. And because there are hundreds of engineers that work on it, there isn't one trunk. There are these several major different code repositories that all have various integration points throughout a build cycle. And because of this complexity of the way the source code is organized, or the development flow is organized, we really had to have a distributed source code control system. And as a result, for a variety of reasons, I don't want to go into it right now, but I can later if you want. We've chosen Mercurial as the system that we'll use. And as I mentioned, we don't have Mercurial available on the OpenJDK site now, but we hope to do that very soon. One of the areas that is a really huge technical challenge for us is bug flow and bug tracking. Currently, we have an internal system that can't be open source and has all kinds of strange hooks into it, to various internal systems. I mean, you're familiar with that, actually, that the WNPTS was quite sophisticated and has a lot of interesting hooks in it. You can imagine that for the Sun BTS that's been built up over time, we have a lot of interesting hooks, too. And it's hard to kind of unwind from that. We're hoping to have some sort of gateway between a publicly accessible external bug tracker and any of those hooks so that more and more handling upstream bugs with OpenJDK can be easier. Right now, we have an external web page that there's sort of two-step process to have an incident that used to have been on that page turning into an actual Sun bug number. If anyone has some suggestions about either specific software or approaches to handling that, especially with upstream downstream integration for bug tracking, that would be great. So now let's talk about the roadmap in front of the big picture of what has to happen or what's going to happen with Java. First of all, to get started right now, there's a real desire to build from 100% open source without binary plugs. And then that's the ICT project that you've probably heard about. I'll say some more words about that in the next slide. But the goal is ultimately to replace those binary plugs or gaps with open source completely functional equivalents. And so just to give you an example, what we're talking about here, it's a graphics rasterizer, font rasterizer, color chooser, parts of the crypto code, and some of the audio engine. The prize for completing this when we get it done is that then open JDK can actually get into main and then be used as a build-up for other libraries and applications, which we know is really important. And as a result, what we're hoping is that this will revitalize developer interest in developing and packaging, distributing both libraries and applications. So now just a couple of words about ICT. So ICT is basically open JDK without the binary plugs. On ICT.class.bet.org today, what you'll find is there's a Wiki that's set up. There's Mercurial Repository and Moxiella set up. The Mercurial Repository is not, just so you know, it's not a duplication of the open JDK tree. It's basically all of the build code, the auto confiscation that's required to wrap around open JDK. There are some deltas to open JDK which are in this, but just so you know that this Mercurial Repository represents basically the build fixes to go around what comes out of stock open JDK and tar balls. Right now, today, the ICT Repository is based on our most recent build of open JDK, which is build 13. And we're hosting the mailing list for this project on the open JDK site, because one of the things that we actually have at works is mailing lists. The mailing list is distro package dev. You can get to that either on openjdk.java.net and up in the upper left-hand corner, there's a link for mailing lists. So those of you that prefer to use main, it's also a gateway to main, so you can use that as an easy way of getting access to it. A little bit more about ICT. It can be bootstrapped with the GCJ. It has to be a newer version of GCJ, though, however. In fact, you need to use the version of GCJ that's in unstable to build ICT. Once ICT has been built, then it can be used to bootstrap itself. Eventually, this open JDK or ICT will get into the archive almost certainly where the circular build depends. And ICT is really that provides a framework for doing the open source replacements. We realize that most of the developers that work in the free software world are not going to experiment with software that includes binary blocks. So that's why ICT is a great way to work on closing these encumbrances without having to touch any binary blocks at all. And the goal is that as the open JDK infrastructure gets built out and as we've had a chance to evaluate the alternatives from class paths and other places, that this code will get merged back into the mainline open JDK. Part of what we ask contributors to do with open JDK is sign the send contributor agreement. It's a non-exclusive copyright assignment, which means you keep all of your rights to copyright. We just give Sun the right to handle copyright, for example, if license version changes to come up. And I mentioned this on Sunday, for those of you that were in the talk on Sunday. I've been talking a lot with Mark Goudard of the class path project and a number of the developers about how to work with the FSF and the software freedom law center to ensure that we can do this legally and get the grant backs where appropriate for class path code such that it can be included and merged into open JDK. So we're handling this on a case by case basis right in the moment. And to give credit where credit is due, the ICD project was done by Andrew Haley at Fedora. And Andrew is here on Sunday, for those of you that were in the talk on Sunday. And his team were the ones that were behind ICD. So now what about ICD and Devian? So Bendy has already been working on some initial packages. He's got some initial packages for a meta package for all the build dependencies you need to build ICD and also ICD itself. I didn't put the archive URL up here because he's got a new version of these things that he hasn't published yet. So as soon as he does, I'm sure he'll send an email to Devian Java or to distro package dev possibly go up. So stay tuned for that so that you can get ICD and build it on Devian. Right now, there were a couple of source files within build 13 that didn't have complete headers. And Fedora has decided they want to wait until those are fixed before they actually upload ICD and the Fedora repository. And I think it's probably going to do the same with Devian. So build 14 is scheduled for the end of June, which probably means the end of next week, is when build 14 will come out. And so assuming those things get fixed, then ICD would be a candidate to be uploaded to experimental. And one of the things I talked briefly with Steve Lang, I just talked about was making OpenJDK a release goal for lending. And in the lending timeframe, I see no reason why we can't have OpenJDK be a completely free Java solution for lending that can go into main. Couple of things to keep in mind. OpenJDK is JDK 7 Alpha. So the really awesome news about OpenJDK is that it's free software and it's somewhat challenging news is that it's still under development. This is not, by any means, finalized. There's a lot of major changes that are going into the platform, including support for the Java module system. So there may be some breakers that happens along the way, just so you know. And I think that that's one of the reasons why there is some value for people that use non-free to keep the production Java 6 JDK and non-free. When are you planning to analyze Java 7? To release Java 7? We don't really have a firm schedule for releasing Java 7, however, it's probably 2008 sometime. So it's a couple of years away. One of the things that we will do once we have the TCK available is we'll have a build option for building OpenJDK to match the JDK 6 platform definition. I know this is sort of legal subtlety, but what's important to think about in this is that this way we can have OpenJDK 7, which is really the experimental, unstable, leading edge version. And with the build option for JDK 6, we can get a much more stable, yet free software version of Java into main. So that's sort of a high-level solution. So will the JDK 6, if it's built with JDK 6, will the resulting product be a special Java, a Java compatible or whatever? And also will that be suitable for, I mean, I understand there's no warranty on GYT or Java product, will that be suitable for production use? That's the idea. As I mentioned before, we are working on the specific details of how to get the TCK available to you so that we can confirm that it is, in fact, Java compatible and how to make sure the Debian project can use Java compatible branding so that we know that, A, technically it meets the Java platform specification, B, that it has the branding that you and Debian users can recognize. And then at that point, C, I feel pretty comfortable calling a production call. The TCK is frankly slightly incomplete in the commercial user interface testing area? No, it's absolutely complete. In fact, the TCK insists on pixel for pixel correctness. OK. So if it passes TCK, there is no question that it's going to be a stable experience. If it passes the TCK, it's going to be the same experience. Of course, legally, if I was a lawyer, I would say that passing the TCK is unnecessary but not complete guarantee that it actually matches the entirety of the Java platform specification. But between us kids, if it passes the TCK, you're done. So after all this work, what do we get? What's the payoff? And I just have one slide on this. I know I actually kind of what I'm really hoping to get from you is your ideas as to what we can do. And I'm really trying to encourage support from you guys to be packages for all these things. There's a lot of different things that we can package for Debian. Right now, NetBeans is not in Debian for two reasons. One is that it's under the cuddle today. And there's been some controversy about cuddle with the Debian project. I've talked to a number of people, the Debian legal people, about that. And we're making some progress. I think there's some interest in possibly considering cuddle, assuming we can address the choice of venue concern. The other problem, which is a more technical problem, with NetBeans is a lot of Java applications. NetBeans packages a lot of dependent library jars all on its big installer car ball. And of course, this is not the Debian way, which is really frustrating. The good news is, I've got the director of NetBeans on board with Linux and free software. He fully understands that NetBeans 6 has to be refactored into open source components. And he's told his team that this is part of the release milestone for NetBeans 6. So I'm hoping that NetBeans 6 has refactored, whether it's under cuddle or we get it licensed in there, another license will be suitable for Linux. As far as libraries go, I'm working on packaging Java Help library now. One that you may have heard of that was released a couple of weeks ago by Choltec is Jambi, which is the Qt bindings for Java bindings for Qt under the GPL. I think that will be interesting. I've also talked with a number of people like Andrew Cowey, who are working on Java bindings for GNOME or improved Java bindings for GNOME. That's another thing that I think would be helpful. There's all kinds of really great server application servers or server related infrastructure things that would be, I think, very useful for Debian. One is the Glassfish application server, which is the reference implementation for Java EE. Grizzly, which is just the fast web container part of Glassfish that's been broken out into its own project. You may have heard of Grizzly. In some sense, it's a functional competitor to Comcat. It has the advantage that it has some of the smartest people at Sun working on that using the new IO library and concurrency libraries. And this is actually our poster child for how or why Java applications with dynamic compilation cannot perform static compilation in C. The performance is really good with Grizzly, so I think that people will be excited to play with that. I've mentioned to some of you Wonderland, this is sort of the follow-on to Looking Glass 3D. Right now, Wonderland is published under a non-free license, but re-licensing is in progress. Wonderland is basically open source second life. It's a 3D world simulation. There's both a server component to it and a GUI friend client component to it. The main difference with second life is that in second life, all of your models are locked in the world. With Wonderland, you'll have full control not only the software, but also the things that you can put into the world. So obviously, this will require advanced OpenGL support, but I think that people will be really excited to see that. In terms of client tools, I just want to mention Jamakini and Orbit. In the past, you may have seen that Sun has been pretty religious about languages. The only language you're ever supposed to use is Java. But now there's some recognition that people might use other languages like JavaScript and that Ajax may actually be a popular framework for doing GUI development. One of the things that the team has done is this thing called Orbit, which is basically looking at the way people are doing Ajax and cutting in half the number of round trips that have to be done using some tricksting HTTP protocol. This is in Java. I think that when this gets packaged for deviant, people will be really excited to play with it. And then, of course, there's all kinds of applications. You probably know about more of these applications than I do. But I've seen an ITP for OpenStreetMap. Rafael was showing us the other night, PowerRock, which is getting things done in Java. How are you coming up? Yeah, yeah. Exactly, very popular. You may have heard of Danny Hill's new project, MetaWeb, or Freebase, which is basically, think of it as like, an open wiki-like, open encyclopedia knowledge base that they're working on. There will be a Java friend into that. So if you have ideas for Java applications that should be packaged, I even just love the name of the package, get extra credit if you know the upstream URL, and if you're willing to help package it, that'd be really awesome. So now, in order to make stuff work, in order to make Java applications just work in Debian, we need to, I think, take a good look at Java policy. You may need to tweak some things with Java policy, mainly because it's sort of complicated. And I think the payoff, though, in revisiting Java policy is that we'll end up with a really great experience for Java developers and Debian users. I mean, my personal success criteria for revising Java policy is that not only can we agree on how to do Java for Debian, but also for other free software distros like Fedora, and that Debian would become a premier place to do Java development, which then could be used in other, even non-free operating systems. So here's just sort of a grab bag of things that we need to handle or cover. A lot of these things are already covered today in Java policy, but just want to review them. One is handling the different runtime alternatives and the priority system. One of the issues about the alternatives is not every implementation has every binary. So for example, the sun implementations, the sun runtimes have things like Pac-200 that a number of the other ones don't. So we have to decide how we handle that if we have some sort of dummy alternative or some other solution. We need to figure out how to make man pages agree with the runtimes that are selected. Currently, we do that by an elaborate system of slaving alternatives, sitting on man pages with the alternative system. I did look recently at how Gen2 does their thing, which is very clever, and I'm going to publish something on Debian Java about how Gen2 does this. Basically, the short answer is what they do is they insert in the etsy profile that a path that they prepend to every user's man path that has a symbolic link in it so that basically whenever the user or the system changes the default version of Java, that symbolic link has changed. And because of that, their man path is up to date. And when they say man, Java C, for example, they just get the right man page. So I don't know if that could work with Debian Java policy, or Debian policy generally. But anyway, man pages have to be there and have to agree. This is a note to be aware of. Debian policy requires that all software and Debian work without setting environment variables. So you're setting that path which you cheated. Setting that path will be, at least in my opinion, cheating. However, there may be an option to add something to the man path in the man program. Going over more of a stream. OK. I mean, we're going to change the man path for everyone. Debian can function cool when they're out of this to put something new in the default path of man. Or the directory for man path. Yeah. But there might be an option. Yeah, which would make, which might possibly make some sense in this sort of context. I mean, we avoided that in the past because of the idea that we should really follow the FHS and install all the man pages in one place. And most of the reason why people do that is because they add software all over the place. But this is a much better reason for eventually having directors in the man path where you have more, I assume, the problem is you have a large set of development man pages. Not section one, but section something else. Yeah. Then you need to swap depending on what you give it. Debian is enabled. Exactly. And that's a hard problem that, right now, it's mostly solved with conflict, so it's not really the direction you want to go. Because it prevents you from installing more than one Debian at the same time. I had never thought of changing man like that. But that seems like a really interesting kind of problem. So thanks. So obviously, that's one thing that has to be done. The other thing is we need a way to select which runtime you're going to use. Today, we have the script that Doko wrote, which is Update Java Alternatives, which works pretty well. Although I'm a little concerned that for end users, using the command line might be a little scary. So I think it might be handy to have a GUI equivalent to this tool so that users that are not used to the command line can choose which alternative they want to use. One of the other things that was interesting about Gen to is they allow this idea of having a system-wide default like we do, but they also have this idea of having a user default, which could be different. And the tricky part again is map pages. But if we can figure out a technical solution to how to do that, that might be interesting so that each user in the system could pick their own. So here are some sort of miscellaneous things about integration. There's just other ways that Java can be better integrated with the Debian system. Obviously, there's desktop-related files that can be used. I don't know if people think that clicking or executing jars is interesting. In format miscellaneous, it's something that we should do or not. Some people feel strongly about it, others don't. There is a bizarre standard in the way that jars are packaged like an offset 36 or something. It looks like a zip file, and so you have to play some games to make sure you can recognize a jar file that's distinct from a zip file. One thing that we don't do right now, and since formerly it was the Java performance group, I'm kind of sensitive to, is we don't really have a way of doing command line tuning. So part of what we've done in the Java performance group is we've realized that customers don't like sifting through 800 command line options, and they do a kind of bad job of it generally. However, if you are putting stuff in production and you get experience with it and you actually understand what you're doing, you very well might want to set things like your initial heap size, various collector policies, your compilation thresholds. And so, especially for production use, command line settings are very important, and we don't have a standard way to do that. And to make things even more complicated, the way you do that and the exact arguments are going to be different based on which one time you have. So I don't know what the solution is, but it'd be really nice if we had a solution and policy that kind of abstracted that out in a way that was nice. I always found the command line option to be weird when it config file, where you can just specify minus F file, where you can config file, you can specify what you want, and it's not one long stream of random characters that nobody understands, but you could have a reasonable meaning option that would actually say heap size, column, variable, and so on. Yeah, that actually makes some sense, because what I do typically when I run performance benchmarking is I haven't had a separate file, but I usually have like in a shell script, I have like my heap settings, I have my compiler settings, I have my other sort of miscellaneous settings, then I can modify the one arcs thing, and so there's no reason that you could do that sort of thing in a config file. From a long time point of view, the problem is you have a very long option, I mean yes, what you get is you have a lot of options, but you don't even know which Java you run, and that's pretty annoying, especially on some areas where you have limits to the respect of the command line that is shown like yes. So if that could be changed by Java minus F, whatever your config file is for that particular Java. And maybe the pre-user system-wide, you know, pathing, it's got by load and you can see. Yeah, that's a nice thing about once you have the config files, then you can stack them too. You can have a system-wide config file, then you apply the users over to it, and then you apply whatever was given on the command line over to that. That's actually a good RFP for upstream. That may be a local config file, but it has to be config-available for each instance separately, because we have set of rules where we can't. You could allow, see what instances are. Yeah, you could allow system-wide per user dash F of this by one, and just arbitrary command line options. Yeah, and usually what they do in that kind of thing is that you, if you don't stack them at all, which case it reads whatever one you want, but the nicer one is that if you stack them by default, but you have an option that says, don't read any of the default files and only do what I tell you to do. Yeah, that's very interesting. I'm not going to remember all of this, so I hope somebody's taking good notes in the right video. So let's see. More Java policy stuff. So I think we can do a lot to help people that are packaging Java. One of the things that has been asked for is upstream watchers. Now, right now, we're releasing open JDK, not exactly on a regular frequency. It's sort of every two weeks. And right now, at least for a couple more builds, it's going to be tar balls, but as soon as we get over to material, I'm sure that there'd be a way to watch that for a new promoted build. The other thing that we need for packages is we need a way of expressing dependence on a particular runtime. For example, does your application or does your library need to have something that meets Java SE 5 or is it Java SE 6 or Java SE 7? So one of the ideas that I have is maybe we can define or provide, it's like Java 5 dash runtime or Java 6 dash runtime. I don't know if that's the right way to do it. That's one way to do it. One of the ideas that Doko had is maybe we should have, instead of just user bin Java for everything, we should have something user bin, like user bin Java 5, user bin Java 6. And then those would be slave as appropriate. You're probably gonna want both of those, I think. Okay, I think so. The advantage of having both of them is then you can make a definition that says Java 6 runtime provides user bin Java 6. When you think of user bin Java 6, it depends on Java 6 runtime. And then I can write a Lyntian check for it. Lyntian checks, yes. That's a great idea, Lyntian. I didn't put that in there, but gotta have that. And then the alternative would refer would like the user to what user bin Java is. Right, but in that way, only the Java runtime to provide Java 6 will provide an alternative for user bin Java 6. The user only gets the choice of the ones that actually work. You could also be done like Python policy with simple versions inside. Yep, I don't know enough about the good Python policy. It's sort of considerably more complicated and I don't know exactly how it works. So could you do something about Python policy? No, okay. Sorry, that was off topic. I think it's sort of complicated. Because Python, it has a user-lit Python number, Python 2.4, 2.5, you see. And all that library stuff. I mean, it means rather simple. So that's the thing you may actually want to borrow from speaking of Python policy is that one of the complexity that I was thinking of is the whole system for, if you have a random Python module, getting it installed with the version of the Python you have installed. You're gonna have the same problem with Java libraries. A lot of them are gonna work with various different runtimes. You're gonna want to be able to install the one library package and have it be enabled for all of the runtimes rather than creating separate dead end packages for each runtime version. And the Python experience may very well be given to copy there. You don't have the problem with Java because you don't have something like binary extensions for Java. So. Yeah. But there are certainly gonna be extensions that there's gonna be Java libraries that will not work with anything later than six or will not work with anything prior to seven or. Right, but that's kind of being solved by having a interpreter used which provides a certain level of Java compatibility. For example, Java five. So it, well, you can put all Java libraries into USR chair Java. But if you pick up the wrong library with the wrong interpreter, it's your fault. That's a good point. Yeah, I'm making an update. Simple is better, but what is it? Making it as simple as possible and no simpler. One thing, I just mentioned this thing about live multiple library versions. I think that because a lot of upstreams have had this really bad habit of including all their dependent jars that sometimes sort of the initial way out of this and just to troll you, I'll just mention the word made it. Some people may wanna have lots and lots of different versions of libraries in the archive. I think that we need to find a kind of a rational policy for having like different major ABI versions of libraries in the archive and maybe, but only one of those, one of each major ABI version or something like that. So there's a compromise between having different ABI choices but not having the archive filled with a hundred different versions of the XML processor. And people on the list, they've been to have suggested Dev Helper and CDBS kinds of support. Once we figure out and evolve Java policy, I think that it'll be important to have tools like this for packages. Part of the challenge too is that I did some research on the documentation of Java policy. You know, the Debian Wiki and other places and there's like lots of different places where the policy is written in a different time zone. It's going back to 2004 and I think we need to coordinate documentation on that to be included in the Debian policy package which is on the road. Okay, so drive better upstream library and application behavior. So part of the problems we have with Java are not unique to Debian or not even unique to Linux for that matter. Part of it is that, you know, well, you know, for whatever reason, some Java developers run on Windows. I have no idea why, but some of them do. And I think that if, you know, we collaborate with people, other distros like Fedora on dependency graphs for popular libraries and applications and also cooperate on bug flow, we may save collective community energy on dealing with upstream libraries and applications and hopefully drive better behavior to the upstream so that they are, you know, more sensitive to bugs and refactoring and those sorts of things. And also library dependencies. And going forward, this is not, you know, kind of an immediate timeframe but just sort of on the horizon. One of the things that's being discussed for Java 7 is the Java module system, also known as JSR 277, JSR 294 and friends. And really, this is something that's been missing the Java platform for a long time. It's kind of like APT get but within the Java class loader, which is really cool for Java to be able to get beyond a static class path and have jars that actually know something about metadata of other jars, which is really great. There's already some implementations of this with OSGI. The challenge is that we have to be really careful to make sure that whatever happens here, doesn't conflict with the deep package system. And so one of the discussions I had with one of the JSR 277 developers and son was how we could do that. And what he said is that in JSR 294, which is described among other things, annotations to class files, there's a possibility of having kind of a free format annotation. And so my thought was we can design possibly a synthetic comment for Java source code that specifies basically kind of what like the Debian library name would be for that. So that, and make, so basically when your Java system is installing or using that kind of a library, it can talk with Becky G to make sure that everything is in sync both with the Java module system and the Debian package repository. So that's an overview of free Java roadmap and kind of used up most of the time, but there's some type of questions. So please go ahead. The implementation, that's a few blocks. Yes. The list you made only includes client-produced sound words. Yeah, that's it's mainly client stuff. Crypto is a bit of a thing to mind. Crypto is the one thing and actually there's a lot of crypto code there. It was just, the code that's missing is something about combined. I mean, there's already message digest. There's one way encryption, but there's the thing about packaging it all together that is missing. And the good news is, I was able to introduce Casey Marshall, who you might know from the class path who's the crypto implementer in class path with some of the crypto people at Sun. And I'm hoping that we can get that stuff closed. But that brings up a really good point. And that is, would it make sense or would anyone be interested in defining a headless or server-oriented implementation of a runtime that didn't have, specifically didn't have all of the client-related stuff? Because there is a definition in, there's a TCK to define sort of a headless implementation of Java. I'm not really familiar with it, but I'm just wondering if anyone has any thoughts about a server runtime. Heather? Well, headless and server is not necessarily the same thing. For example, the bootchart graph drawer, it's a Java implementation to take a file and convert it to a G or a SVGA or whatever. And that's a command line tool that would be very useful to have, even with a X. At the moment, it fails if it is placed except with class path. That's really annoying, especially when you're doing a low-to-X test. The dependency on the platform libraries for X to the bitmap conditions, that's a major factor. Well, it's interesting you guys mentioned that because one of the first, well, the first experimental project in OpenJDK is this thing called FB Toolkit. So one of the class path developers wants to develop basically a way of rendering Java client stuff from a frame buffer without having to use X at all. And so they actually have a lot of code that they haven't checked in, but I think that would be one of the interesting experiments is how you can run Java with a frame buffer and not without a full X. There's actually a free implementation. The problem is that it's GPLs and it's possible it's difficult when you start linking that together with the proprietary code. But now that Java is GPLs. Yeah, it should be great. Well, I see that we're out of time. I'll be around until Sunday morning, so feel free to come talk to me now or later on, Doko. Yeah, for further discussion, it would be nice if we could agree on one main list and maybe use an existing one, deviantjava at list.deviant.org. So if people do want to continue to discuss the Java policy for deviant, it would be nice if you could join this list. That's really good recommendation. Okay, thanks a lot. Can you think of me with this again? Oh. First pitch, yeah. Thank you.