On 09 May 2005 13:10:45 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote: > > Open problems > > * The class library is incomplete. I tend to dump this in the 'bug' > category. Anyway, the reason the class library appears in both the > non-problem and problem lists is that it seems unlikely that a new > project would address this more efficiently than just hacking on > Classpath.
Just to add one. API Versions. Harmony needs to get 1.5 implemented, with an eye on 1.6. > * Fragmentation. I think there are too many free JVMs. In particular > the "C/C++-based VM" niche is over-full. It ought to be possible, > though difficult, to write a configurable core VM that can be reused > by other projects. The idea here is, have a reusable reference > implementation, and reduce writing a VM to writing an execution > engine (and perhaps a GC). Versions comes in again. Long term, will there have multiple VM spec implementations? Another aside. Using 1.3 as an example; it would have been nice to have been able to compile Harmony 1.2 and compile in the 1.3 regex library, rather than moving wholesale to 1.3. I know there's a sf.net project for adding the 1.5 libraries to 1.4. Maybe that would just be the easier solution; relatively standalone apis like collections, regexp, logging, even nio perhaps could be available as separate jars. These are really just examples; I mainly mean similar styles of libraries in 1.6 etc. > * Publicity. Though we try, and though we're starting to see some > successes, it does seem that just the announcement of Harmony has > generated more PR than Classpath got over the last year. > > * com.sun.*. Those pesky java programmers often end up using unfree > APIs. I'm not sure what Harmony could do here; maybe pressure Sun > into make it much more difficult to do this? Offer similar functionality from Harmony? My big wish on the tools list is that they be APIs as well as command line tools. A definite area for vendor improvements. > Maybe it seems like a grim environment for starting a new project. > Well, considered on technical grounds alone, it is. One needs a > pretty compelling technical story to do better than already existing > projects. I think you've hit on some of the major parts. Harmony can bring various existing bits together, underline to open-source coders as a whole that it's not just a GPL product, break 'open-java' into the corporates, help strengthen JCP backing, and offer a large user base. Apache hasn't got that many potential VM coders (I think), but does have a lot of VM users and test-writers. Hen
