Jim,

> >>Don't put Java source in the table. It's not useful to the database and
> >>there's no practical way to guarantee that it's in sync with the class
> >>blob. No compiler can find it there, and Java source files are normally
> >>handled by source code manager (cvs). Putting them in the database will
> >>drive everyone nuts.
> >>
> >>
> >
> >Disagreed. Putting them in the database is great for ad-hoc development.
> >
> >If you can save your Java source and the Firebird Java plugin attempts
> >to compile it, return errors etc, this would be excellent, and pretty

much

> >the same as the current PSQL Stored Procedures.
> >
> >
> Get serious.

I am.

>Editors/IDEs only work off files and Java compilers only
> work off files.

The internal Firebird java-compiler could be modified to do
this... As I wrote:
"the Firebird Java plugin attempts to compile it, return errors etc,"

>The source in the database would be obsolete on the
> first change.

Huh? This is how it's being done with PSQL Stored Procedures.
Why is Java any different?

>Source in the database would have to extracted before
> anything could be done with it.

Where do you think the source comes from in Firebird GUI tools
that allow you to "edit" a Stored Procedure?

>And which source file would you
> believe, the one in your source control system or the one in the
> database? And what would happen when you trashed your development
> database? Restore an old copy and loose all your Java changes?

Again: how is this different from PSQL?

> And
> how many software developers really want to ship their source code to
> their customers and competitors?

See above... again.

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com