 | |
SDN Chat Sessions Transcripts Index
April 19, 2005 This is a moderated forum. MDR-EdO: Welcome to today's SDN chat on Project Peabody. Project Peabody is an initiative to provide a more collaborative development environment for future generations of the Java 2 Platform, Standard Edition (J2SE). The initiative includes simplified licenses, a more transparent development process, and contribution opportunities for developers. The approach is already being used in the JDK 6 Project for Java SE 6. In today's chat you'll have a chance to ask questions, make comments, and offer suggestions that can help Sun determine how to best work with developers to improve the J2SE platform and the JDK. Here to answer your questions are Peabody Program Manager, Ray Gans, and Sun Senior Engineers Peter Kessler and Kelly O'Hair, who are both directly involved in Project Peabody. Ray, Peter, and Kelly, can you start off by telling us some more about contribution opportunities in Project Peabody? What can be contributed? How can it be contributed (what's the process)? Ray Gans: We are open to contributions of any kind. Bug fixes, performance enhancements, etc. I suggest you start with small fixes and work yourself up to larger fixes as you learn to work with us. Matt: I'm interested in finding out what form the contributions to J2SE source code would take? Is there a process inside Sun to review patches? What tools would outside developers have, such as access to bug database (more than read-only)? Peter Kessler: Contributions can be code for new features, or translations of the documents, or bug fixes. The "form" is a GNU diffs from the sources, with unit tests as appropriate. Is that enough to get you started? Pops: How are my contributions handled? What process will Sun follow to evaluate them and how can I find out their status? Peter Kessler: When contributions show up, we acknowledge them as quickly as we can. Then they enter into pretty much our usual process: code review by a couple of appropriate engineers, builds on our favorite 7 platforms, testing, etc. That can take a couple of weeks, depending on the complexity of the code. Pops: What support can you give me to build the JDK on Windows -- it's hard! Kelly O'Hair: First off, we are trying to make it easier. But we are exploring other options, like being able to build just a portion of the JDK. We have also been working on making it build faster, use more free tools (cygwin vs. MKS), and use the latest MS compilers. Matt: Have there been any contributions accepted for 6.0 yet? Ray Gans: Yes, in fact Andy Tripp wrote it up on javalobby. Paul Mclachlan: But, let me give you an example - I build a kind of performance profiler at work. There are some relatively small (but in an obviously critical part of the code) features inside JVMTI that I could justify spending time on to build. But, I definitely don't want to spend a few weeks doing that if they're going to get rejected out of hand because they're too risky - is there a pre-qualification process or discussion forum where we can talk about how we're going to do things prior to starting them - to increase the chances of their acceptance into the codebase? Peter Kessler: Absolutely. If you want to discuss *how* to implement a fix, by all means start that discussion early. You can start a thread in a forum under the JDK collaboration project on java.net. That way not only do we see the topic, but others in the community can chime in. (The point of this is to be transparent!) We'll make sure we have the right engineers on the discussion from our side. Pops: Am I required to use Sun's make files to build the JDK? Kelly O'Hair: Ultimately we will need the JDK to be built with its own build procedure and its own makefiles, but developers working on fixes are free to use whatever tools they wish; NetBeans, Ant, whatever. So it depends on the fix. If someone has a build procedure that builds the entire JDK other than the existing makefiles, I'd actually like to see it. :^) Pops: How come the JDK project is not a java.net Community? Ray Gans: We are working on becoming a full-fledged java.net Community and going through the acceptance process now. Matt: Not really a question, but just wanted to say that I really like the process underway for Java SE 6. Having earlier access to builds and a more open process is great. Ray Gans: Thanks, we're trying to see what the community needs. Please let us know what else you'd like to see. Is there anything you could use to help make things better/easier for you? javadragon: Makefiles seem so... archaic. have you considered an Ant build? Or something like an Ant build? Kelly O'Hair: Use of makefiles has been historic, and they can do just about anything, but it can be very hard for many people to understand. However nobody has been convinced that wholesale conversion to Ant would be an improvement, especially with the native compilation thrown in. We have and will be exploring adding Ant scripts to build specific Java-only components. Paul Mclachlan: So, generally, I think this is a great move - occasionally you hear the disgruntled complaints of people not having their bugs fixed after 5 years or whatever, at least this gives them at least the opportunity for an outlet to that frustration. :) Peter Kessler: Thanks, I think :-) We don't just want people to fix the bugs that we haven't gotten to, though that would be great. What we want is to have people contributing to the development of the platform, and giving us early feedback (and maybe alternatives) for the features we are putting in. Sometimes we haven't fixed bugs because they are hard to fix (harder than people realize), and sometimes we decide that "fixing" them would break compatibility. It's definitely a balancing act. Pops: I'm not quite clear about the terms of the JRL license. If I develop under a JRL license can I distribute what I develop within my academic community? Ray Gans: Good question. The JRL is a research license and not a general purpose use license. If you want to distribute it for research purposes you need to include the JRL as part of your distribution with the understanding that it is for research purposes. Pops: Will Sun be providing support for other native compilers in the build process? Kelly O'Hair: We will be trying to make it easier to use other native compilers, but we cannot guarantee it will always build with any native compiler, of course. Paul Mclachlan: Are you expecting to see larger companies contribute code in this forum (such as Apple or IBM submitting feature improvements)? Because most of the innovation I see from them is either just incremental improvements for their JDKs or platforms. Peter Kessler: Other companies (large or otherwise) are welcome to contribute. The larger companies often have different channels for contributions, e.g., by being licensees for the Java platform, so you might not see their contributions being discussed on the java.net forum. We certainly do expect companies that aren't licensees to contribute through java.net. And, of course, anything major has to go through the Java Community Process. javadragon: so, if you want people to contribute to the platform, and not just fix bugs, what sorts of things would you like to see people working on? Peter Kessler: Some non-programmers have been asking about translating documents. That's possible, as long as we have someone to check the translations. Another problem there is continued translations into the future. (How many times do you want to translate the javadoc for your favorite class?) People have been suggesting performance improvements, minor tweaks to APIs, etc. We've also had a lot of suggestions about the build process itself. Pops: I'd like to see a newsletter that lists the bug fixes. Ray Gans: Good idea. We make bug fixes available with every release and we will shortly be listing committed bug fixes. We have talked about doing a what's new section to talk about important changes and we will be soon be giving more information about scheduling and roadmaps. Paul Mclachlan: (Perhaps this was discussed in a document somewhere and I missed it - if so, apologies) -- Will access to the code be only via snapshots, or will there be some kind of source repository (CVS?) behind it? CVS is nicer because it will auto-merge changes you've locally made to your tree while you're working on a feature over a long period - most open source projects I contribute to I have small hacks that I've half started and they stay half started for months until I finish them up - constantly porting them into a new snapshot (although I know with some fancy scripting I could do that) would be a pain. Kelly O'Hair: Currently there are no plans to change to CVS. Internally we use the Sun product Teamware, and have for many many years, so we have a large history of changes in this system. If there was a clean way to bridge these source repository tools, I'm sure we would consider it, but from what I've seen the process of converting back and forth seems to be less than ideal. We haven't given up on this, but we just don't have any good answers yet. Pops: Is there a way several developers can work together on a fix? Ray Gans: Absolutely. Discuss your idea on a forum or mailing list in the jdk-contributions project and go for it. Matt: One idea on the build process to extend what Kelly mentioned -- what if there was a simpler build process that would take pre-compiled native bits and just compile all the pure Java source into something usable? Using Ant for that would be great.
Kelly O'Hair: Currently most J2SE developers do this with the JVM, when they build the pre-built
Paul Mclachlan: Where's the line between a feature that you can sneak in on java.net and a major feature that needs a JSR? Does every new API or change need a JSR, for example? Or only brand new APIs and packages? Take adding a method to (for instance) a Peter Kessler: We have this struggle all the time. Mostly we know a JSR when we see one. We do have a review committee for changes, with senior engineers from all parts of the platform, and they usually raise a flag if something is too big for just an engineering change, and needs a JSR. We'll run any community suggestions by that committee, too. But whether to propose something to Sun to go for a JSR was a problem even before putting the code on java.net. How big a change is it? Who should help designing a new interface? Are there experts or other companies we should be consulting to make sure whatever we do works everywhere? Pops: Will my fixes be backported into J2SE 5.0 update releases? Kelly O'Hair: No, not necessarily. Bug fixes for J2SE 5.0 are selected based on a specific criteria. If this bug fits that criteria it would get looked at, but in general the answer to this question is no. Pops: It seems like you're asking us to do free work for Sun. What do we get out of it? Ray Gans: Hmmm... I suppose you could look at it that way, but there are a lot of people in the world who are as passionate about this technology as we are and they tell us they want to help improve and evolve the technology. If you have good ideas and suggestions, we want to hear about them. What do you get out of it? You get to influence where we're going and how we do it (subject to JCP constraints of course). bor: Is Project Peabody just started? Ray Gans: We started putting out Java SE 6 snapshots in build 12 last November. We have since been adding to Peabody with the JDK collection of projects and posted the JDK sources on java.net. We will continue to roll out more things (licenses, projects, etc.) as time goes on. Tell us what you'd like to see. bor Thanks. How do you contribute to Project Peabody?
Ray Gans: You can do three things:
Matt: Ahh, just remembered what my number one beef is with J2SE source. Apparently a lot of Sun devs use emacs still, because indents are totally off. If I remember correctly, this is due to an emacs "feature" that makes code look properly indented even when it's not. Could this be cleaned up so that the code is more accessible to outside developers? A good example is
Peter Kessler: I don't have Matt: Actually, this has existed in every Java release since I can remember. It doesn't have anything to do with Java SE 6 per se, except that it makes using the J2SE source aggravating in general.
Peter Kessler: I just looked at Pops: Can I make contributions that improve the makefiles? Kelly O'Hair: Sure. We will treat it as any other change. We do need to be careful about what tools the makefiles become dependent on, but in general, correcting or fixing makefile problems will be welcome. Pops: Can we expect to see a similar effort at more transparency for the other Java platforms (J2EE and J2ME)? Ray Gans: Answer, yes we're looking into this, but it's hard to say what or when we'll roll out programs for these other technologies. Pops: I'm not sure this was covered previously, but where can I get the Java SE 6 snapshots? Ray Gans: Go to the JDK Project on java.net. If you have any difficulty please let us know on the snapshot forum there. MDR-EdO: Well, we've quickly come to the end of the session. I want to thank everyone who participated today. I thought we had an excellent range of questions. And of course, I'd like to thank our guests, Ray, Peter, and Kelly, for their answers. Kelly O'Hair: If anyone has tried, successfully or not, to build the J2SE, we would certainly like to hear about it. Peter Kessler: And, if you think of questions we didn't answer, post them on the Java SE 6 java.net forums, and we'll answer them there. Ray Gans: Thanks for joining us! MDR-EdO: Moderator signing off. The forum is now unmoderated. | ||||
|
| ||||||||||||
Print-friendly Version
