You've caught me...and you're the perfect person to have done so. I am
indeed thinking of enhanced runtime reflection. See if Java reflection was
complete, this wouldn't even be a discussion. Certainly in C# land it is
not.
There's two reasons: 1) parameter names as you've guessed, 2) Comment block
processing because Java has no multiline strings. Again, in C# this isn't a
problem because C# Attributes are much cleaner than Java annotations, they
have multiline strings and they can introspect on parameter names (James
Gosling, are you listening? Or farting around with NetBeans?)
GWT is nice, but I hate having to "compile" or "generate" code. Blech. The
code is written, why do I want anymore? :-) So if we did support something
like:
public native Employee getEmployee(int id) /*-{
SELECT * FROM EMPLOYEE WHERE ID = ${id}
}-*/;
I would not want to generate yet another artifact (probably XML) at build
time. I personally hate that. So why not just deploy the source? It's the
easy and natural thing to do. And I love the fact that it still compiles!
My biggest concern is that there are some companies that are kind of strict
in the sense that they believe this is a security risk, which I believe is
totally false. However, I could understand to some degree that developers
of desktop apps would not want to do this if they have IP/legal issues with
handing out their source code.
But then again, that's why we have multiple solutions right? ;-)
Cheers,
Clinton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Larry Meadors
Sent: October-26-07 8:26 AM
To: dev@ibatis.apache.org
Subject: Re: Deploying Source Code
I used to do that, but looking at it now, I am asking "What's the cost
and what's the value?".
The cost in terms of disk is negligible these days - You can't buy a
drive <120GB these days, so what's a few hundred KB, or even a few MB
on disk? Especially compared to the 80MB of struts or spring?
I'm not sure how class loaders deal with this, I suspect if they load
a jar, they load all of the resources, not just what's needed. That
*could* be a bit more costly in terms of startup time, and free memory
for the application, but again, sheesh, when you have 4-8GB of RAM in
a server, what's a few K here and there? I suspect you'll leak more
than that running firefox. ;-)
The value seems kind of iffy. I guess if you wanted to use embedded
comments for runtime code generation, this is the only real way to do
that. But IMO, since we have annotations, that's not a great idea. It
might help overcome some of Java's retarded reflection limitations
(who needs parameter names, anyway?), but again - an annotations can
do that, too.
My gut reaction is that it's not a good idea, but I can't really
quantify why. :-)
Larry
On 10/26/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
>
>
>
>
> I mean deploying your .java files to production alongside your .class
files
> and having it available on the classpath at runtime.
>
>
>
> com/yourdomain/yourapp/SomeClass.java
>
> com/yourdomain/yourapp/SomeClass.class
>
>
>
> I hope that's more clear.
>
>
>
> Clinton
>
>
>
>
>
>
>
> From: agodinhost [mailto:[EMAIL PROTECTED]
> Sent: October-26-07 6:17 AM
> To: dev@ibatis.apache.org
> Subject: Re: Deploying Source Code
>
>
>
>
>
> I don´t know if I really understood what you mean.
>
>
>
>
>
> If you are just talking about the iBates part of code, to give a more
> examples, it is okay.
>
>
> But if you are talking about the whole application this can be a
> nightmare!!!
>
>
>
>
>
> Please, explain better your idea.
>
>
>
>
>
> Woody
>
>
>
> ----- Original Message -----
>
>
> From: Clinton Begin
>
>
> To: dev@ibatis.apache.org
>
>
> Sent: Thursday, October 25, 2007 11:41 PM
>
>
> Subject: Deploying Source Code
>
>
>
>
> What does anyone/everyone think of deploying their Java source code with
> their application?
>
>
>
> Thoughts, ideas, fears, absolutely not???
>
>
>
> Why?
>
>
>
> Cheers,
>
> Clinton
