David Gibbs wrote:
*** I KNOW I'M GOING TO REGRET THIS ***

But (I'm assuming) Richard will not be demonstrating .net code generated by some other product. I'm (fairly) certain he's going to be showing hand coded (or at least wizard generated) .net code. Please correct me if I'm wrong on this.
There is no such thing as "hand written .Net code" at least as far as you and I will ever see. .Net is a platform, the same way that Java is a platform. You use many languages to generate .Net code, including VB and C#. I guess one of the key differences between Java and .Net is that Java has at its core a language specification as well. I suppose C# is close to that for .Net, but I'm not sure. Anyway, let me spell it out again:

.Net is the platform, VB is the language, Visual Studio is the tool.

Java EE is the platform, EGL is the language, RDi-SOA is the tool.

While it may be true that the EGL you are going to demonstrate generates Java ... EGL can also generate Cobol. And, as you've pointed out in the past, the RDB product has a source level debugger for EGL ... so a developer never has to look at the generated code. So you write EGL and you debug EGL. Regardless if RDB generates Java, Cobol, byte-code, or MI code, you are developing in EGL. As such, I would say that what you are demonstrating is not JAVA at all, but EGL entirely. The fact that the code generated from EGL will be Java is purely incidental.
No, David, it's not. Because it generates Java EE applications, it runs in a Java EE container. It's NOT purely incidental. It has to comply with all the standards associated with servlet programming, including implementing the HttpServlet interface. This is not "incidental", it's a carefully designed deployment strategy. The fact that EGL can also generate JavaScript to run in a browser and COBOL to run on an i simply makes it very versatile. But that doesn't take away the fact that EGL targets the Java platform, and that this event showcases the two platforms, .Net and Java, side by side.

FWIW: I agree with Trevor wrt the event title ... I think it could be updated to more accurately represent the content of the event.
And, like Trevor, you're 100% wrong. The only possible change would be to change it to .Net vs. Java EE, to make it absolutely clear to those who don't understand the difference between Java the language and Java the platform (and can't be bothered to read the agenda to see that the entire Java session uses EGL). It could also be headlined as "VB vs EGL" but that's not really the point - if it were just another language comparison, we'd be showing a lot more of the capabilities of the languages and not focusing on integration.

True ... bit I would venture to say there is a higher level of correlation between the generated servlet and the JSP than a Java app generated from EGL. That is only an assumption, as I have not yet done a whole lot of work in JSP yet.
What does this sentence mean? "A higher level of correlation"? A JSP generates a servlet using the tags in the JSP as something like opcodes. JSF is even more complex - it has its own cycle that processes the statements in a specific sequence, not unlike RPG's cycle. EGL generates Java code which uses the statements in EGL kind of like opcodes. Where is the difference in "correlation level"?

This is getting maddening. This anti-EGL inflammatory BS is beginning to overshadow the technical discussions. What possible difference to this community does the title of Richard and my faceoff make? How does it merit discussion of this duration, especially when the discussion is fueled by a basic technical misunderstanding? And yet, EGL discussion gets cut off.

I'm starting to be really disappointed by the level of discourse exhibited on these lists.

Joe

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.