gmane.comp.java.openjdk.general

Re: challenge question

Mario Torre — 2008-09-02T19:31:57

Il giorno mar, 02/09/2008 alle 21.23 +0200, Clemens Eisserer ha scritto: Hi Ray! I second Clemens :) Not that I want to push, but just some hints at least... Cheers, Mario

Re: challenge question

Clemens Eisserer — 2008-09-02T19:23:58

Hi Ray, Some estimated date would be really cool, I guess everybody has been waiting the last two weeks nervously ;) Thanks, Clemens

Re: challenge question

Neal Gafter — 2008-09-01T06:32:37

Ray- Can you please tell us when you expect to announce the winners? -Neal On Tue, Aug 19, 2008 at 1:34 PM, Ray Gans public.gmane.org> wrote:

JDK 7 build 34 is available at the openjdk.java.net website

Xiomara Jayasena — 2008-08-29T00:43:10

The OpenJDK source is available at: http://hg.openjdk.java.net/jdk7/jdk7 http://hg.openjdk.java.net/jdk7/jdk7/rev/46a989ab9329 The OpenJDK source binary plugs for the promoted JDK 7 build 34 are available under the openjdk http://openjdk.java.net website under Source Code (direct link to bundles: http://download.java.net/openjdk/jdk7) Summary of changes: http://download.java.net/jdk7/changes/jdk7-b34.html -Xiomara

Re: MarkMail for OpenJDK

Max (Weijun) Wang — 2008-08-26T00:36:14

Find the reason, I disabled Flash. -Max On Aug 26, 2008, at 8:12 AM, Max (Weijun) Wang wrote:

Re: MarkMail for OpenJDK

Max (Weijun) Wang — 2008-08-26T00:12:34

The links in the filter pane (what? who?) do not work in Firefox? On Aug 26, 2008, at 4:02 AM, Ray Gans wrote:

MarkMail for OpenJDK

Ray Gans — 2008-08-25T20:02:43

The good folks at MarkMail have indexed our openjdk mailing lists as part of their service. This provides us with a nice web GUI to search our mail archives. Check it out: http://openjdk.markmail.org/ http://openjdk.markmail.org/search/?q= If you're unfamiliar with MarkMail, click the "?" next to the search box to get some information about how to refine your searches. -Ray

Re: challenge question

Ray Gans — 2008-08-19T20:34:22

You are correct Neal. We will let the winners know shortly and public announcement will occur in conjunction with the other Sun Innovation Awards announcements. Stay tuned. ;-) -Ray On Aug 8, 2008, at 7:53 AM, Neal Gafter wrote:

JDK 7 build 33 is available at the openjdk.java.net website

Xiomara Jayasena — 2008-08-15T00:40:03

The OpenJDK source is available at: http://hg.openjdk.java.net/jdk7/jdk7 http://hg.openjdk.java.net/jdk7/jdk7/rev/bb1ef4ee3d2c The OpenJDK source binary plugs for the promoted JDK 7 build 33 are available under the openjdk http://openjdk.java.net website under Source Code (direct link to bundles: http://download.java.net/openjdk/jdk7) Summary of changes: http://download.java.net/jdk7/changes/jdk7-b33.html -Xiomara

Re: Project Proposal: BSD port

Andrew John Hughes — 2008-08-08T15:01:05

2008/8/7 Volker Simonis public.gmane.org>: Better to agreed than have a different schema per group to contend with, which would just add to confusion, especially with those outside Sun where these groups aren't as established concepts.

Re: challenge question

Neal Gafter — 2008-08-08T14:53:09

I think they may have to rank, as only 6 projects sent a completion announcement, and the official rules do no pay evenly in case there are fewer than 7 completed projects. -Neal On Fri, Aug 8, 2008 at 4:58 AM, Mario Torre public.gmane.org>wrote:

Re: challenge question

Mario Torre — 2008-08-08T11:58:49

Il giorno gio, 07/08/2008 alle 17.44 -0400, Andy Tripp ha scritto: We are not even yet judged! I would be against a ranking if the project all equally succeed. I would instead be personally happy to receive impressions and suggestions for the projects, because I think the real goal should be to improve the OpenJDK code base, not just get the money and forget :) Cheers, Mario

challenge question

Andy Tripp — 2008-08-07T21:44:15

The Challenge page http://openjdk.java.net/challenge/says: Will there really be a ranking of completed projects, since the prize money is the same for each? If so, will Sun list the rankings? I'm not requesting that this be done, I'm just curious. I would like to request, though, that Sun post something about the results. Even if it's nothing more than saying something like "all projects were judged to be 'complete' and conformed to the rules". Andy

Re: Project Proposal: BSD port

Volker Simonis — 2008-08-07T19:12:24

Yea, these are good points. If we take into account that the code in the j2se directory is maintained by several different groups (i.e. AWT, Core Libraries, Networking, Sound, ...) it may be perhaps even usefull to rearrange the platform dependant code in such a way that the first level of subdirectories inside the "j2se" directory denotes the specific group. Every group could than decide for itself, how it wants to handle the platform specific differences. Otherwise, all groups involved would have to agree on a new schema which I imagine could be quite difficult... I know this means even more changes, but perhaps it's the right time to do them now, if there is a common consense on changing the structure of the j2se project anyway. Regards, Volker On 8/6/08, Mike Swingler public.gmane.org> wrote:

Re: Project Proposal: BSD port

Mike Swingler — 2008-08-06T16:11:31

I think the ideal thing to do would be to clearly discriminate in the directory structure exactly what difference is between the platforms. If the difference is X11, then create an x11 directory (because not all *nix's are going to be based on X11). If the difference is Win32 vs. Posix threading and file system operations, there should be a win32 and posix directory for that sub-system. The same should be true for fonts, OpenGL work, or any other system where discrimination does not cleanly cleave down platform lines. #ifdef'ing should only be reserved for situations where the code is largely similar, but requires just a tweak one way or the other (like 32 vs. 64-bit). Glomming all the classes together in the same pot and removing the 'shared' directory will encourage everyone to just "compile all the classes", and toss them into the same jar, and ship classes that make no sense on for that platform. Any accessory or utility classes that don't result in a runtime link error only

Re: Project Proposal: BSD port

Kelly O'Hair — 2008-08-06T16:22:53

Good points. A while back I changed code that was ifdef'd on the platform changed to being ifdef'd on _LITTLE_ENDIAN, just made more sense and the code was easier to understand. Changing the ifdef's to specific features rather than making it a platform thing makes sense. So I agree with your X11 comment. And also agree that we don't want to deliver classes to a platform that doesn't need them. -kto Mike Swingler wrote:

Re: Project Proposal: BSD port

Dmitri Trembovetski — 2008-08-05T23:01:21

Rob Ross wrote: I agree, but they don't need to have different roots as they are now. Currently we have weird stuff similar to this: jdk/src/windows/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp jdk/src/windows/classes/sun/awt/windows/Win32GraphicsDevice.java It seems that it could as easily be src/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp src/classes/sun/awt/windows/Win32GraphicsDevice.java ... (I'd even remove 'shared') The native code for the most part mimics the java packages names, so if a package is platform-specific, it should probably have the platform in its name (sun.awt.windows in this case, or sun.awt.nix or whatever). The native code's structure would naturally follow the java package naming. For cases where the package name is the same on different platform but the native code is different we could follow Kelly's approach and/or use ifdef-ing. I do realize that such changes would be a huge pain though. Espe

Re: Project Proposal: BSD port

Rob Ross — 2008-08-05T22:43:00

I can't comment on whether it's better to have all *nix statement variants be wrapped in #ifdefs or placed in their own platform- specific folder. It's probably a judgment call on whether platform- specific variations are different enough to warrant their own directory structure. But if you think about the differences between Windows, Mac OS, and *nix X11 native code for things like GUI or file-system access, I think these kinds of differences probably warrant their own directories. The code to render a native window is going to be quite different on these three platforms. It's not just a platform statement variation, you're calling native APIs that may only exist on one platform. So in cases like these, it makes sense to me to keep the code separate. I do like that the actual "low level" Java implementation is defined by private Java classes, that then call native methods to do to actual platform specific work. Thus there would still be need of having Java classes in these platfor

Re: Project Proposal: BSD port

Kelly O'Hair — 2008-08-05T18:11:37

I think I'm mostly in agreement with Martin here. Hotspot is different, and I'm not speaking to that, just what is in the jdk7/jdk repository. I have tried over time to make any C code I see be standard conforming and avoided using the src/windows and src/solaris directories, favoring using the src/share area for as much as possible. I don't have the history on why the share vs. solaris vs. linux vs. windows separations were originally created and populated, I think someone with some ancient jdk history might speak to the real meaning of "share". I've treated "share" as "generic" code. I myself would prefer to have one implementation source file with a clean #ifdef approach rather than copied sources, but that's just me. I prefer to see all the implementations of a function in one file. However, I've adapted and over the years have experimented with many ways to do this. A couple of small examples in the OpenJDK sources I am familiar with: hprof, hprof_md.h is in the share area, and it's implemention is

Re: CFV: Project sponsorship: BSD port

Kurt Miller — 2008-08-05T10:27:55

Thank you Dalibor and the others behind the scenes who helped this along. -Kurt

JDK 7 build 32 is available at the openjdk.java.net website

2008-08-04T23:52:29

The OpenJDK source is available at: http://hg.openjdk.java.net/jdk7/jdk7 http://hg.openjdk.java.net/jdk7/jdk7/rev/64da805be725 The OpenJDK source binary plugs for the promoted JDK 7 build 32 are available under the openjdk http://openjdk.java.net website under Source Code (direct link to bundles: http://download.java.net/openjdk/jdk7) Summary of changes: http://download.java.net/jdk7/changes/jdk7-b32.html -Xiomara