commit-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [commit-cp] classpath ./ChangeLog lib/Makefile.am lib/gen-c...


From: Michael Koch
Subject: Re: [commit-cp] classpath ./ChangeLog lib/Makefile.am lib/gen-c...
Date: Tue, 21 Dec 2004 09:13:55 +0100
User-agent: KMail/1.6.2

Am Dienstag, 21. Dezember 2004 09:02 schrieb Jeroen Frijters:
> Michael Koch wrote:
> > > Please just check in the file. Requiring to run platform
> > > specific scripts is not something that makes GNU Classpath more
> > > accessible.
> >
> > We do this in other places too, e.g.
> > gnu/classpath/Configuration.java.
>
> That's the only place I'm aware of. The precedent for checking in
> generated files is also there, the locale classes themselves are
> generated and there are also the JNI header files.
>
> > I will check it in later.
>
> Thanks.
>
> BTW, Why do (some of) the generated files that have territories
> hashtable define a new class for this, this is very wasteful and
> doesn't really do anything useful? I must say that in general I'm

Guilhem wrote this. That's no excuse, I know. ;-)
Its not used yet but will be later. 

> not too thrilled about this whole approach to using classes for
> storing this information, a class file is a very inefficient way to
> store these kinds of tables. Is there any need for these things to
> be classes? Would it be possible to make the generated classes
> final, that would enable a small codegen optimization (at least for
> me)?

Sure, I can make them all final as now no locale class inherits 
another anymore.

When all works, and this means many known bugs need to be fixed first, 
we will move to properties files for this. I just want to make the 
framework working first.


Michael
-- 
Homepage: http://www.worldforge.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]