avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject [RT (was: OT)] .Net better than Java in some ways
Date Mon, 12 May 2003 09:14:14 GMT

> From: Jakob Praher [mailto:jpraher@yahoo.de] 
> > > 	(Java+Avalon).atLeastAsGoodAs( .NET ) ==  true
> > 
> > patch:
> >          (Java+Avalon).potentiallyAtLeastAsGoodAs( .NET ) ==  true
> > 
> > we've got some work to do :D
> propably more realistic - now we have patched it let's make 
> that statement evaluate to true ;-)


even worse, since the only non-numeric type for which the + operator is
defined is String the first (Java+Avalon) expression will evaluate
to String or some numeric type and the thing won't even compile.

                       -oO   However   Oo-

I have been thinking about extending Java for scripting purposes (and
for other purposes). In effect, being able to play around with different
extensions of Java just to see what happens. For example, while you
have to do this in JDBC:

    Connection conn = getConnection ();
    try {
        PreparedStatement stmt = conn.prepareStatement (
            "UPDATE employee SET office = ? WHERE office = ?");
        try {
            stmt.setInt (1, 6);
            stmt.setInt (1, 5);
            stmt.executeUpdate ();
        } finally {
            stmt.close ();
    } catch (SQLException e){
        // Handle the exception somehow
    } finally {
        conn.close ();

I'd like to change that to:

    transaction (companyDatabase) {
        update (Employee) {
            office = 6;
        } where {
            office == 5;
    } catch (SQLException e) {
        // Handle the exception somehow

to get some kind of SQL-in-Java processing. In effect, relational
processing in Java.

Now regarding the extending of Java: Eclipse (www.eclipse.org) have
defined what is in effect a Java DOM. That is, you have a class
SwitchStatement that can give you a list of CaseStatements and
so on. Having that would allow one to

 + Extend the DOM with custom elements.

 + Extend the parser to support those elements.

 + Have some equivalent of XSLT.

 + Output Java source code, feed that to the standard Java compiler.

 + Augment the bytecode afterwards.

(I think it was Bjarne Stroustrup who said it was only a matter of
time before Java evolved into multiple, incompatible versions,
each one with proprietary extensions.)

Anyway, what the above would allow one to use Java as a base and
create doman-specific extensions as needed.

It would also allow us to play around with C# features.


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message