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.  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.


Couple selfie goes viral, then they realize something's off. The couple wasn't in use to their photos gaining attention. They had a large presence online and quite a following. That is why it was so strange that this one particular photo was gaining so much attention. More than any other. The main difference however, was that the attention it was getting was not from their followers, but from the general public. It was even being picked up by news outlets. They baffled couple didn't understand what was happening, so they started to read the comments on the photo in the hopes of discovering the source of this popularity. Then it hit them. Wendy Joseph and Dan Hennessey hadn't always been such an internet sensation. In fact, there was a time when almost no one on social media even knew who they were. The irony being that this was a large part of what started the story of their success and their love for each other. This would ultimately lead to their online success. It was in 2006 while they were both college students that their story would begin. Dan hoped to make more friends. This choice would lead him to cross paths with Wendy in a rather unusual way. Dan, then an 18 year old sophomore, was studying exercise science while Wendy, who was only 17 years old at the time, freshly graduated from high school, was hoping to pursue a career in public health care. Dan was outgoing. He loved to party, socialize and meet new people. He heard about a new online tool called Facebook. Back in 2006, this behemoth of a platform was still relatively unknown. It was only used by students and mainly used to meet or date new people. It was on Facebook where Dan first met Wendy all those years ago. Dan had decided to use Facebook in an attempt to meet new people and make new friends. It was there that he found a friend of his named Daphne. They shared some friends so he sent her a message. She didn't respond but this didn't stop him. He scrolled through her friends list. Suddenly he stumbled across Wendy's profile and was instantly smitten by her. He immediately sent her a message. At the time it was quite understandable for Wendy to be careful and worry online strangers. Rather than replying to him, Wendy told Daphne about his message and she took Dan to task over it. Daphne mentioned to Wendy that he had messaged her too, so she decided not to answer him. After a few weeks, Dan decided to try again. Wendy was curious so she decided to view his profile. It was there that she discovered they knew some of the same people. She felt safer with this knowledge and decided to answer him and a friendship was born. Dan decided that he wanted to meet her so he invited her and some of her friends to a party at his apartment, but there was a problem with that idea however. Dan had made the invitation, assuming Wendy would decline. She didn't. Suddenly, Dan needed to plan a party and fast. He reached out to his friends and managed to arrange a party at very short notice. When the night finally arrived, the two met for the very first time. They immediately hit it off and spent the whole night chatting and dancing. Even after the other guests had left, Wendy stayed behind and spent time with Dan. It was clear that there was a spark between them, but would that be enough? Wendy had recently had her heart broken when a long-term relationship had come to an end. She was understandably scared of getting hurt again. Dan enjoyed his single life and the party life that it brought with it. They decided to stay friends even though it was clear there was something more there. They kept in touch and messaged each other regularly, and six months later they decided to give things a try as a couple. Little did they know what trouble was waiting for them. Happy with her love life, Wendy started to pay attention to things that she had neglected for some time. She plunged into her studies. Dan however, continued to party and socialize as he always had. Years flew by. Wendy was still trying to get her master's degree when she discovered a message in Dan's inbox that would change everything and leave her reeling. Wendy had always had some seeds of doubt in her mind. These seeds continued to grow along with the friend's list on Dan's still active Facebook profile. She became very suspicious. Dan had found her on Facebook. Who's to say that he wasn't finding other women on Facebook too? What also troubled her was the fact that while she had to decline many party invitations due to her studies, Dan began to go out without her. Even though Dan had grown up and become much more mature, he still loved to party as much as ever. The actual message itself was innocuous enough, but it plagued Wendy all day. Dan hadn't logged out of his Facebook and his inbox was open which is how she saw the message. Wendy was studying when the message popped up. She knew that it was wrong. If she didn't trust Dan, it meant that their relationship was in terrible danger. As much as she tried to resist, her curiosity overcame her and she clicked. Her world seemed to crash down around her when she saw that the message was from a girl. Wendy gave in to it. It was easier now that she had done it once. She began to go through all his messages. All his private Facebook messages passed before her eyes. There was nothing incriminating that she found other than many messages from other women. Women who were successful had finished studying and young just like her and Dan. Dan had met them at the many parties he attended alone.  There was nothing Wendy could do however. She was young and as a result, she had very little experience in either life or love. To Wendy, it felt that her life was falling apart. Small arguments escalated into huge rows. All fueled by Wendy's fears. Dan also refused to compromise on his lifestyle. They argued over who should do what. Should she set aside time to spend with him? Should he stay home more often? What if he met someone new? All their arguments ended up there and Wendy couldn't help but wonder if he already had. Everything would have to give. But what? Back in the present, Wendy couldn't believe her eyes as she watched the likes on their photograph pass the 60,000 mark. Thousands of comments and shares flooded in from all over the world. Everyone wanted their opinion and comment to be heard. Even news stations were approaching the couple about this photo. But what was it about this specific photo that caused such a huge reaction? Wendy decided to break things off with Dan. It seemed like a logical course of action all those years ago. She was becoming very unhappy in their relationship and she wasn't getting what she needed most from Dan, validation. They were young at the start and people change a lot in seven years. Even so, making the decision broke her heart. Now, looking back at that photograph, Wendy is sure that it was the best possible decision she ever made. Even though it had broken her heart to think of a life without Dan, she knew she had to put her head down and pursue her own interests. She didn't like the person she had become when she was with Dan insecure and needy. She needed to find out what kind of woman she could become. So she renewed her efforts and without the constant distractions and worries that came with her relationship, she went on to eventually receive her master's degree in public administration. She had done it for her own good. But staying away from Dan had proved much harder than she could ever have imagined. But there was one thing she hadn't considered. Dan hadn't been happy with Wendy's decision far, far from it. He wasn't ready to give up the love of his life. He understood what part he had played in their breakup. He had taken her for granted. But now, he missed her terribly. The only thing he could do was message her every day for the entire year and a half that they were separated, so that's what he did. Just like in the beginning, he hoped that his persistence would pay off once again. But Wendy had finally found her true calling. Though it was an extremely difficult time for him, Dan eventually realized that Wendy was right. After she achieved her dream of completing her master's degree, Wendy decided to set her sights even higher. With social media on the rise, she saw an opportunity. She started her own YouTube channel, called Wendy's Curls, where she posted beauty tutorials, and gave hair styling advice for girls with unmanageable and naturally curly hair. She shrugged off her old look and began to embrace her own natural beauty, and her followers loved it. But then, fate decided to intervene in her life once more. But it was inevitable that Dan and Wendy would meet again. One day, the couple bumped into each other after months of not seeing one another. Dan was amazed at the transformation that Wendy had made. She had embraced her natural beauty and just wasn't the same girl he knew from all those years ago in fact, she had thrived while they were apart. The strong, beautiful, and confident woman he saw before him made him fall in love with her all over again. But would she take him back? Naturally, Wendy had her reservations. Things needed to change. Wendy had decided to break up with Dan so that they could each find themselves and discover who they were as individuals. Their relationship had stagnated. They had just been too young. Dan hadn't been mature enough, and Wendy wasn't secure enough in herself to be able to handle it, although that kind of security would only come with age. Though it was an incredibly difficult time, she knew it had been the right thing to do. During that time spent alone, Wendy had become a YouTube star with thousands of followers, and she had her confidence back. Had Dan changed so much in such a short time? Had he finally grown out of his party-going lifestyle? And was he ready to settle down? Wendy thought so. He'd been relentless in trying to convince her that they were meant to be together, and he made good on his promises. Surprisingly, he hadn't dated anybody else during the time they had been apart. He was only interested in Wendy. She knew that he'd proven that he was in it for the long haul, so she decided to give him another chance. Little did she know, their antics were about to go viral. Dan started appearing in Wendy's videos, and they discovered that fans really liked seeing them together. So they began posting videos giving relationship advice and talking about their life as a couple. Dan also created an Instagram account, which quickly amassed over 25,000 followers, although not nearly as many as Wendy's 105,000. Then, in December 2017, they celebrated their 10-year anniversary. But they had no idea this milestone would become a viral sensation. To mark the occasion, Wendy posted a side-by-side picture on her Facebook and Instagram pages. On the left was a picture of them when they first started dating, on the right was a current photo. Though it may seem like a normal thing to do, the post exploded. In a matter of weeks, it got over 60,000 likes. It got picked up by major news outlets like The Independent, The Sun, and The Daily Mail. But why had this photo gone so viral? Seeing the photos side-by-side, people couldn't believe how different Wendy and Dan looked especially since they appeared much younger now than 10 years ago. Do you both age in reverse? asked one commenter. What fountain of youth are you drinking from? said another. But, it turns out, there's a reason for such transformation. They go on to explain exactly how they managed to become so healthy and happy. Even before they met, both Wendy and Dan had a strong interest in health and fitness, which was reflected in their choice of careers. So it's no surprise that both of them worked hard on their bodies. When Wendy's YouTube channel hit it big, they realized going into the fitness space was a natural progression for them. They started posting workout tutorials and nutrition advice.  Together, Dan and Wendy founded True For You Fitness, a fitness coaching company where they give nutrition and exercise advice to their clients. They also opened a wellness-focused YouTube channel, though once in a while they also talk about their life and relationship. And in September 2016, they made a huge announcement. In September 2016, Wendy and Dan were on holiday in Paris with a couple of friends. But the day they visited the Eiffel Tower, Dan had a surprise prepared for Wendy. With his friend recording everything, he got down on one knee, pulled out a diamond ring and asked Wendy to marry him. Naturally, Wendy said yes. She was so excited that she even forgot which hand the ring should go on. It was like a fairy tale. But the couple's life was about to become even more magical. After their trip to Paris and their engagement, Wendy and Dan were not done traveling and living their dream life. They were able to save enough money to do something they'd always wanted, travel abroad for months at a time. Dan and Wendy managed to earn enough money from their fitness venture to travel to Thailand, Costa Rica, Panama, Colombia and many other places. After returning to the US, they went on a domestic trip to Las Vegas and are now busy planning their wedding. But what else does this power couple have planned? Although both Dan and Wendy are originally from New Jersey, they decided to move to the warmer climate of San Diego, California. With the stunning weather, sun and surf, this could be the perfect place for the couple to settle down. What else does this mesmerizing pair have on the cards? The couple's Instagram and YouTube fitness pages have grown from strength to strength, recently branching out to include a website. Their main goal is to help people from all over the globe reach their fitness goals and transform their lives just as they did. After all, the couple who trains together stays together. Wendy and Dan's story of love and success seems like a dream come true from the outside. But sometimes, if someone's life appears to be too good to be true on social media, it probably is. She took a closer look at the photo. Now that it was pointed out to her, she couldn't believe it. She had been deceived for over a month, and she couldn't fathom what they were telling her. But why would her daughter do this? And then the truth of it all sank in. Zilla van den Born from the Netherlands had entered the world of modeling at the tender age of 16, and soon, she was enamored by the way her photographs were manipulated to portray her in a different light. The photo editors would work tirelessly to ensure that her shoots were picture perfect, but she didn't always agree with their modifications. Zilla was 25 years old when she decided to pursue a career in the arts, and she enrolled at the Art Academy of Utrecht for a graphic design course. Her friends and family were aware of her dreams to travel the world one day, so they were unsurprised when she announced a solo five-week trip to Southeast Asia. Little did they know, Zilla's photographs of her trip were about to stir major controversy. Layden with her heavy luggage, Zilla arrived at the airport in April 2014 and promptly posted a photograph of her send-off on Facebook. Soon, comments flooded in all her friends and followers were awed, and a little envious that the young girl was about to set off on the adventure of a lifetime. But nobody could have dreamed what was really going on in Zilla's life. Zilla continued to post photographs of her adventures in Thailand, Laos, and Cambodia over the next five weeks. She posted snapshots of herself posing in the sapphire blue waters of Asia's idyllic beaches, silhouetted against the iconic skyline of Bangkok, as well as enjoying local cuisine. She had no idea how much backlash she would receive for these seemingly innocent photographs later on. Zilla added photograph after photograph on social media, to the envy of her hundreds of Facebook friends. In one album, titled Thailand, The Land of Smiles, she even poses with a Buddhist monk in the beautiful temples of Bangkok. Her rabid followers waited with baited breath for each snapshot of the young woman's seemingly perfect life, and she never disappointed them. She partied with many new friends she had made, when scuba diving in the crystal waters of the Thai island of Phuket with exotic marine life, and even posed with the local children. On the surface, it appeared as though she was living everyone's wildest dreams and adventures. But this was far from the truth. Zilla, despite her busy days of adventure, managed to keep her loved ones updated, and would video call them on Skype from her various hotel rooms throughout her stay. And she did an excellent job of maintaining the facade she had built so elaborately around herself. He parents never suspected that anything was amiss with their daughter. When Zilla's five-week vacation drew to a close, her parents were eager for her to come home and show them all the photographs of her trip. They were proud of their daughter and happy that she had been brave enough to embark on such a journey alone in a foreign country. But when Zilla revealed what she had really been doing during her vacation, everyone was left reeling. She had set up some exotic props in her apartment when she staged the Skype calls to her family. And all it took to make everyone believe that she was in Asia were a few paper umbrellas. When her loved ones had dropped her at the airport, she had disguised herself and returned to her Amsterdam apartment. You see, instead of going on a five-week vacation, Zilla had decided to perform an elaborate social experiment. She had never left her apartment in Amsterdam for the entire five weeks, instead carefully photoshopping herself into believable scenes from her imaginary vacation.  Zilla had even studied Asian cooking videos, and had recreated them in her own kitchen to give her posts an authentic feel. She had also successfully faked the shots of her snorkelling in her very own backyard swimming pool, and then edited the exotic fish into the shots with photoshop. The hoax was risky, and she had been careful to make sure there were no flaws in her plan. The most difficult aspect of the five-week long operation was convincing people of the fake friendships she had made on her travels. Zilla even went as far as creating fictional identities for each of them, and staging Facebook conversations to make her experience more believable to her friends and followers. Zilla spent weeks creating her elaborate ruse, and had successfully fooled everyone. She transformed her everyday surroundings to create the illusion that she was off on an incredible adventure. The entire process was painstaking, and she had told nobody about her secret. But her revelation baffled her friends and family. Why would she go to such an effort? The experiment was a project for her university course. Zilla had set out to prove that social media is a powerful tool that many use to distort other people's perceptions of their lives. She wanted to prove how easy it is to portray yourself in a specific way on social media.