 Welcome everybody to the Debian Java verse of a feather session We I Yesterday to the Debian Java mailing list asking for topics and throughout the day So So these are some of the topics that the people posted on the on the gobby page and the idea will be to Try to go through the room and select some of these topics talk a little bit about them and Then collect notes and their each topic here so we can have it as a document and well Then I think our gobby set a collaborative editor and we might have some people joining us by IRC okay, so A Person do you want to choose one topic to begin with? Yeah, I would just start with the first one Well, our plans for bigger packages the current state in Debian is that we have some bigger packages like eclipser but only the main applications the main application not all those nice and if he Plug-ins stuff like Hadoop Facebook Map reduce some stuff. I'm working on currently is getting J Ruby back into main It's quite a lot of work like getting some of the Java Enterprise Application servers into Debian. They have some core stuff the core libraries only not not any application server Have no web applications like life Then I think about these big packages that are really attract new volunteers into the team I joined for example to help Niels with eclipse It would be interesting from the audience So would you be willing to put some help on that Starting to use maven to build That's not a problem But they are don't use the central maven repository, so which is even a problem by itself They are using it their own maven repository with own binaries They're nobody knows where they come from how they are patched and everything else. So that's quite a horror Actually, I had a bunch of question Sort of a newbie in terms of pop Debian policies and Started noticing a couple of projects that were using the maven repositories for having all the primary location for all their stuff instead of the Java Area and just kind of looked around in terms of Debian policy. It's like well, where is Maven repositories as the primary location for stuff. It's sort of nowhere So I don't even know like well if I'm making a new package. Is it expected? I mean people gonna copy the example or what I don't know No, we can cannot any Use any external repositories If you want to package some package for for main, we have to resort to all Every dependency in main their dependencies and dependencies of the dependencies It seems as though on Many projects that I've worked on when a precedent is set and not actually corrected Very quickly what happens is the problem is replicated by people coming into the system saying well I here is this exemplar it exists. Therefore. It must be an okay way to do it. Okay, I'll copy that So it's more toxic than just its existence One of the things I've been working on is to get up a page of example Debian packages For Java and say if you have this sort of Package, this is what your packaging should look like at the moment. I have things using Antons Things where you have to roll your own build system, which Java help helps with I would be really nice if I could get because I don't actually know anything about Maven But you get some examples there using Maven and help that house how to do it properly The at the stage where I have several of them written I'd like to get a couple more and then actually try and stick it up On the package Java web page Logistic issue, can you introduce yourself the first time you get the mic so other people can know? Sorry, I'm Matthew Johnson. I write Java helper amongst other things. I'm Tony Mantel I'm going back to the packaging larger packages. I just had a Kind of comic question. So I'm not up to speed on Kind of how the big packages like a clips and J boss build things like that But how much do you think I mean the maintainers who have worked on these things? It seems like the problem is that when upstream goes Way out in left field then we end up paying the cost if you will Kind of long term and I'm just curious how much we might be helped by actually advocating saying or building taxes Back towards upstream because it happens with smaller packages to so the antler 3 2 is has crapped out job Ralph I'm gonna have to port old code kind of forward to antler Because there's all these jobs. There's all this Java software in the Java ecosystem that is simply I Pulled these jars it worked right then and that there's no view towards continuous library payments One of the things that's happened at Fozdem this year was that we did a talk in the Java track there Where it was like there's a whole bunch of people there who are upstream Java maintainers And we tried to explain to them all our point of view of trying to package that software why we do what we do I think being able to do that more would be good because yes, if we can get upstream to You know Working practices that make it easier for us then that's going to make it all easy to get all sorts of stuff packaged And you know, ultimately that's going to benefit upstream so Stanford University's Account management system right now is written in Java and we're taking it over in our group and Planning on hopefully releasing the whole thing open source did whatever extent we can But the so I'm kind of tackling all this from the perspective of I have a bunch of internal packages that we need to write And then hopefully eventually they become more generally usable stuff So one of the things that would be great along those lines is if you've got a document somewhere that says here's how you write a St. Java build system if you're an upstream maintainer of a Java package I mean we would start following it right away And similar to that is is there a policy already for how do you package web apps Tomcat style? I mean the things that would be deployed right now with a little as a war file Which is probably not a great way to deploy it in Debian Is there a policy on how that's done? I believe there is a draft web apps policy banging around somewhere, but not by a Debian Java so as to the Versioning of jar files. This is something that is just a real pain Recently, you know, I had a bunch of dependencies. I want to say, you know, I need to be a such-and-so version of jar file whatever and One of you know, just elementary problems in Java is that you can't actually easily make a sim link in Java, right? And then none of the or you can't really tell if something is a sim link in Java And so if you've got a Java based build system like ant, you know, and you look at the various Java based packaging Tools to make a deb file to make a binary deb. It's really sort of a nightmare well To actually build the dev you should probably not be building them directly the Helper tools mostly written in Python or Python Perl or shell scripts Which can get out right for you Sure, and I'm I'm would like to try and improve the documentation and say look here's the examples of how you do this properly Hi, I'm Wookie. So I don't know anything about Java But it said in the thing come along if you package a Java package and you're new to this and tell us what your problems were So I know about this cave survey software. So I know about that. I know anything about Java That's just what it happens to be written in But I looked upon somewhere and found a bit about Java packaging In fact, it was very easy in comparison to all the other things I've packaged. It was totally trivial I had to type Java C star class everything and it's better to think and so long as I used open JDK It worked. I used anything else. It didn't work So I made it depend on that. Now, I don't know if that's right or good or any of that stuff But it wasn't difficult, but I have no idea whether I've done a good job. It works We have a meta package called default Java on some platforms open JDK doesn't exist. So On those on those platforms, it's GCJ. You may find if your package is doing something Weird that it will only work with open JDK And in which case you have to open JDK We're gonna I'm gonna mention several that stuff in the next talk. It was simply a matter of some bits being missing in the Freer or non-sun class path stuff library stuff Yeah, I was gonna say something else, but I forgot Yeah, it's a 700k of Java. I've no idea it makes it a tiny package a medium-sized package or a huge package I mean, it looks complicated to me as an application, but I have no idea Where that comes on the scale of things Compared to things like eclipse, that's quite small Okay, so maybe we can choose another topic to discuss now Maybe something on the lines of An automatic build system and test cases doing builds that type of tooling I mean, we have plenty of tooling to build packages, but there are more toolings to be used by the whole team in this in the way of Run our test cases automatically and stuff like that What do you have in mind there Yes, it's Automatic nightly bills comes from here, whatever nightly means in deviant because we are so global Yes, the idea is that we find some API or LBI I break it early because we cannot fully avoid such breakages Earlier this year, I've uploaded 1.8 and Break some packages because it's such an important tool such a core tool So it would be nice to just have automatic builds at least of all Packages that are packaged by the Java team Once a day, so if something breaks you will get noticed And you can still remember what you have done If we can do something that's a good idea and Niles and I were work have just made a Not entirely trivial change to Java help and Niles has tested a bunch of packages, but it would you know Nice to be able to test all of them in an automatic fashion Attesting I think Yeah, the next point is close to this So I think we should start running the tests during builds time for most of the packages Even if you are If you will ignore test failures for the moment It might happen We will see the test failures in the big locks That would help with the nightly bills if something breaks you can check the big locks for test failures Okay Yeah, but I think that we should change The the nice thing about something like nightly built is that is something very easy to bring somebody new into the team that to work on that for example and You don't need to know so much about packaging for example I mean at the end of the day, you're just going to be running all these builds and finding when they break So if somebody wants to you know join Debbie and Java and give a hand this could really increase the Life quality of people running unstable Can someone explain why nightly builds is an issue? I mean you build the upload the stuff and it builds at the time Why will it break? I think it's to do with when you so One of the things I'm going to be talking about in one of the other talks is to do with Transitions and things like that and currently the story in Java is very bad for for those things And particularly also with the culture upstream people break stuff And you might not find out until you upload and find all your I depends break or some of them the ones you didn't test Or when we're changing packaging tool help it all some stuff doing a rebuild for that sort of thing is very useful I don't know that necessary should necessarily should be on demand or Whatever but having an infrastructure to do that would be useful. Hi Timothy so One of the things I've been struggling to package is Hudson the Continuous integration server and it uses lots of maven and I'm not doing very well, but Sort of last week I'm wondering whether we could plug Debbie and packages into that and Incorporate upstream. Maybe that would be an easy way to get started on that The downside is it's not packaged There are also issues with the Hudson and security, you know, sorry There are also issues with Hudson and security Yes, almost certainly here I'm Stefan one related topic to this nightly build and testing so to find out when something Unexpectedly breaks or even earlier is already up here from someone about API and API compatibility We had the same problem in my day job Where we developed some some core platform and other people can deliver modules Which are using of course the code of the core platform and those modules are sometimes not even published So we can't really test them. So I need to ensure in some other way That they don't break and then we use some free tools that call Japi tools to export the API for better the ABI so the symbols and do some API checks so someone developed this for example to comparing the glass libraries built by Gcj open JDK so class paths and open JDK and Sun JDK and this is quite a nice tool and should be I guess rather easy to implement Just for example when uploading exporting this API or even before uploading and then running this compatibility check So so they we are talking about the automated API AI compatibility checking. Yes Yeah, that seems to blend in fairly well with the current topic Do you have any Yes, drop it to this name I can look up the URL and put it on on the editor later nice This is a slightly different topic, but I just have a question So I'm not a member of the of the actual Java team in terms of team maintenance, but I may be soon But in terms of team maintenance I mean is would you like to see more packages team maintained or left cuz thinking about this automated build Right in one way to do it would be able to just get everything from the archive. It's maintained by the Java team I think moving things under teammates. This is always a good idea For one just because You know sometimes People don't have as much time as they need to and it makes it easier for people to fix things up But also because it allows us to use these sorts of Tools and it makes more easy versus we want to make you know sweeping changes to some of these things We're always happy for more people to join the team And even if you don't join the team if you just want to use the repository The only reason I ask is because that the other thing that happened is it's going to increase It's gonna increase the amount of mail right that so if it When bug reports for packages that are actually maintained by the team come through or is there some other practice that you'd like to Use because I don't want to just throw a bunch of small Java packages And then all of a sudden you guys have to read more and more mail well I mean we have a list this is a discussion list to to the Package I was maintained as this so I don't think that's particularly an issue I'd rather see more packages One of the problems we have in is MIA handling at the moment some people join the team bring their packages And then disappear and then you know, that's that's more of an issue You joined the team with a small package is fine, but stick around and maintain it So a couple of points related to that one is is it that one of the things that's worked really well for the pearl team is that there's They there's two separate Set of lists one which gets the bugs on pearl itself and the core stuff and another one Which gets the bugs on all the the the team maintained pearl packages because there's you know a thousand They're more of them at this point and you might want to consider that a long run if you get kind of overwhelmed by bug traffic on J random Java library when you're trying to maintain the core Java packages Um a quick note on something that was on here is a topic the the bind v6 only stuff I don't know. I don't know if this if everyone realized this, but that's that's been reverted So it's not the the version of that base that's currently in the archive does not set Does not set that and so it's back to the default kernel behavior Anyone who's actually installed netbase while it was setting that still has the old setting Because it didn't it didn't go back and change and remove the configuration file. That's already there and there's a further discussion about that but the At the very least anybody who's upgrading from Lenny to squeeze will not get that behavior Do you know whether that? behavior is true for K3 BSE K3 BSE That's a really good question, and I don't know the last that I'd heard that they had kept the current the default BSD kernel behavior Which is bind v6 only is one But they said it was a kernel parameter that could be changed Given that we just had a Debbie and technical committee discussion about all this and like lots of flame wars and Debbie and the bell and Everybody seems to have concluded that zero is the best default Probably somebody should go explicitly ask the BSD team. Could you please set this to zero for the squeeze release? They seem quite willing to do that if that's what we all decided we wanted to do Okay, I was a little lost So so you just said that we are going to go with that flag Switch to the way make job applications happy. Yes. Whoo. Yes So there there will be a problem for people who upgraded to the net base that was in Sid and squeeze for the period of time that was setting that flag those folks will get the the behavior which breaks Java But anyone who went who goes directly from letting to squeeze anyone who is installing it from now on will not get the behavior Which breaks Java? Okay The n-based languages like you question J. Ruby. Yes, yes, I'm toasting by the way Yes, I was wondering why we call every Violet package I think that's not appropriate for Other languages for packages of other languages. They just happen to use the JVM The Java virtual machine That's why I wanted to propose something that We are using the language name or the programming language name in the source package It's that useful. So lip something Java. It's a Java packages and it's something Scala if it's a Scala package and for the binary package, I would use the Virtual machine so lip something JVM if it's a classic Java virtual machine or lip something Gdj if it's native package If something J and I that's what we are actually use for native code and maybe lip something Dalvik if he ever starts shipping Dalvik I love that idea, but it sounds like a lot of busy work. I'm a hickory the Curious question I have about that change in naming scheme is how does it affect things like IKVM where we have one VM implemented in another Quick question about that. Oh, if you have some package written in Java or closure or whatever Are the binary packages all useful for the other ones? Can they all link against them? If I write my packaging if I write a library in Java, can this be used by closure or Scala or whatever? One thing that you may find I know as you mentioned closure up there, and I know a little bit about that You we may find when we get to that. There's a Similar problem. They're using starting to build their own build system. I think it's called lin engine and It's they also have another site called clojars, which I'm not all that familiar with maven and Java But I believe it's similar to that and maybe even based on it So it pulls a whole bunch of job closure jars from random places to build whatever package they're building like It's trying to remember the big web compogers one of the big web frameworks that does some of that said Anyway, that's something I guess you'll have to consider to Do you want to talk about or does it need to be here? Just a quick question you're suggesting that you wanted more Packages to be team-maintained what's required to make your package team maintain just add Java team to the maintainers list. Is that it? We have a we have a subversion and get repository and so If the source is in somewhere we can find it allows the team maintain, you know, if we try want to do any team Maintain a changes then we know where to find it. How does that link back to the upstream? What you just maintain the deviant part for It's very much depends on the packages the subversion. It's mainly just the separate deviant does I know there are some people using Get with pristine upstream branches and so on Okay, I'm going to throw shamelessly a topic. I Care about and I was told no on the mailing list. So why not keep insisting until I got people tired and say yes That is Having libraries with source code, you know, when you are debugging something on Eclipse, it's very nice to have the source code and The reason people say no is because of course you don't want to have a whole set of debug packages because it's just more packages and But on the other hand, you know, we are free software, so we want to have all the source code there So you can actually look at it and understand how the thing works Isn't that spelled app get source? That's the part where it's not the case because as you start having all these maven Build systems the sources is really much about of different folders So you I have been doing that for some libraries But then I have to you know get a class and fish around and then Changing Eclipse where the source code is located for different classes in the same jar That that's definitely suboptimal I'd have thought that's more a problem in Eclipse than with that package I mean all of our sources available if the the package makes it hard to just have to get source and see the source Then, you know, maybe that's a change we should make the package But I don't think we should necessarily be shipping source in all the binary packages I think the kind of the isn't the root of the problem there basically that Eclipse doesn't know how to find the source So I mean the problem with that get source is that it puts the source somewhere wherever you happen to be But if I mean if we clip ideally what you want to do is have Essentially the same behavior as you have in GDP when you start tracing through debugging symbols If you install the debug package it knows the debugging symbols are just right there If we had a standard path where we could install source our source jars, then in theory close We should be able to do the same kind of thing To repeat what I'm trying to convince is for us to include on our build system generating these search charts We currently don't have them. I think I don't think that's necessarily a bad idea But I definitely think it should be a separate package and not not installed by by default So debug package or or similar Yeah, our source package or whatever, but Is the main objection that you just don't want to have twice as many packages or that you don't want to have belowed in the archive I Don't have any objections. I want these stuff But do you have an objection to it being as debug packages rather than Shipped in them in the main thing. No, I want debug packages and Actually, you know even even just if you have in Java help or something that I can get this the source and turn build it again I have the debug packages built by myself and I can install that even that will be better than the carbon situation but when we have this discussion a while ago on the mailing list people somebody says something that Says oh, and you should only look at the API. You shouldn't look at the implementation and I'm saying yes That's true But this is you know, you hear you have all the source code So you want to profit from that and find the bag sense and fixes and all that stuff I'm not sure that we have anything like that at the moment So one of the things I'm going to talk about in the next Session which is slightly germane to this is that With C and other languages you have a dev package which you need to build against me Don't necessarily need that but there are some advantages in terms of handling transitions But possibly but what you'd essentially end up with is a package that just contains a single sim like but if we're Considering this as a sensible option. Maybe what we have a dev packages which contain a source jar And some of the other stuff set to build against And then we can combine those two things to not have so many Should those dev packages also register in class path so that the standard debuggers find them in everything or At somebody just added something at the end Yeah, I added that one as a developer of some non-packaged application where we have some wiki page telling people how to Install and set up the system so our build system and application works and for this application We have the requirement of Java home being set up and pointing to the JDK you're using to and Update Java alternatives already does a nice job of synchronized switching all the tools But I don't know the policy allows setting an environment where you will automatically in this job also I don't think we can have a set an environment variable But it may well be sensible to have a sim link which points to your current Java home so you say use a shared Java home or whatever we decide is the path and That will point to whatever your current update I think that we have already use a live JVM Something that's at least a generic one if you pick open JDK that you have at least not the version number in it What is close to your request is the Proposed a sensible Java I can paste the link to the wiki page there and I have already working prototype so maybe That's enough what you want We have a similar proposal a book report against Java common in Ubuntu for simple here about that. I don't know if you've read it One of the things I said is that it's a little difficult convince people to set this way especially because it has no meaning if we don't have Java on the system and many system works without Java so but Basically, I'm willing to implement the part of creating a sim link that could be updated with alternatives that could set your Java home I don't mind that But the part of setting Java home for our users is I don't know how to do that and and you're welcome if you have an idea to help us with it Totally different topic. I just happened to notice yet versus subversion and a whole lot of Java programmers use As well, so it might be nice to update that Oh Well, oops, so that refers to that currently on TV and Java we we have our team-maintained packages using JIT and SVN. I don't think we have Mercurial no and I For example, I myself am just starting on JIT. So I the stuff that is currently maintained on JIT There might be dragons. I wouldn't look at it or check things, you know stuff like that, which it's It's but I mean you want contributors to be able to contribute in I noticed the point of the boss and they're about JIT and non-JIT implementations. So for people who aren't aware At the moment we have essentially three different JBMs depending on your architecture. We have open JDK on an architect's way that has a JIT And we have open JDK on some others with but it doesn't have JITs about architecture And then on some others mainly HPPA. I think There's no open JDK at all I'm K3BSD at the moment, so there's only DCJ on that. So What I think would be a nice goal if we can manage it would be to have a system where basically we say We use open JDK in the same way that you know, there is only one implementation of Python on the system or whatever I don't know, you know, I don't know how feasible it is or what Things we want to do. The problem here with is it acceptable to only have non-JITs? Well, there isn't a JIT implementation. So what would you like to do? The That's I would like to tie it also with the topic of support in multiple JBMs It's kind of like we are setting ourselves to a much easier task if you only support open JDK But in the real world, there is all these proprietary JBMs which I suffer the IBM JDK JBM implementation But the nice thing about that is that it exposes a lot of new bugs on the jars So so it's not so bad to support multiple JDKs because these are real bugs on the jars Does open JDK include the the conducts on that security classes particularly KERP 5 login module and some of the rest of the stuff that's sitting in there. I Know there are some people who have issues around that area Related to open JDK and using the non-free sun for the sun JDK for non-free. I don't know if it's because they're completely missing or just because there are some bugs in the implementation Okay, it's that anything related to Kerberos going forward is it tends to wander into that territory fairly quickly I mean, there's there's a lot of stuff in the generic GSS API That's if you already have Kerberos tickets But if you need to obtain Kerberos tickets from scratch from a key tab then you're immediately into Coms on security stuff Sadly, Tom Marble is in a parallel session, but he's involved in the Open JDK jigsaw puzzle He's giving a talk at the end of the track. He will be the perfect person to answer that. Okay, great Okay, so any ideas with about Java security and finding embedded duplicate It's in code. So Lindy and has a whole bunch of tests for finding embedded code already. We keep adding new ones They're sort of scary. They're they're mostly they're mostly checking for see embedded C libraries And so what they're mostly doing is looking in your binaries for strings that match error messages that happen to occur inside those libraries But like many things in lentian, it's it's amazing how far you can get with some ugly heuristics and a few hacks Certainly we're happy to take more stuff along those lines and anything else related to Java It's always better for test specific to a particular language and a particular set of policy if there's Anyone involved in that team who's who's willing to sort of translate that policy into here are the things that lentian can specifically check You know, because there's I know there's a lot of things of that that use where you set a policy Then you think about how do you actually check that with an automated tool and it becomes a little tricky? But yeah, we're happy to take that kind of thing okay, so Thank you very much. We can continue this conversation over lunch And this document will stay here if you want to add more things later on to if you remember or Thank you so much for contributing and I hope you stay for the rest of the track. We have some very interesting talks Thank you