Board index » jbuilder » Anybody Prefer to Write Delphi-Style Java?

Anybody Prefer to Write Delphi-Style Java?


2003-09-03 01:04:26 PM
jbuilder14
Does anyone here prefer to write "Delphi-Style" Java? Essentially you would write Java code but be able to build
your J2EE application using many rich UI controls, objects, functions that are just like Delphi. This would leverage your Delphi skills and enable you to build a sandard J2EE application with HTML front-end that has a very rich UI. Roughly 80% of the Java code would be automatically generated for you and you would work mostly in JBuilder's Design view rather than Source view.
Thanks,
Ali
 
 

Re:Anybody Prefer to Write Delphi-Style Java?

Does anyone here prefer to write "Delphi-Style" Java? Essentially you would write Java code but be able to build
your J2EE application using many rich UI controls, objects, functions that are just like Delphi. This would leverage your Delphi skills and enable you to build a sandard J2EE application with HTML front-end that has a very rich UI. Roughly 80% of the Java code would be automatically generated for you and you would work mostly in JBuilder's Design view rather than Source view.
Thanks,
Ali
 

Re:Anybody Prefer to Write Delphi-Style Java?

80% of code? I dont think so~
"Ali Kamal" < XXXX@XXXXX.COM >wrote in message
Quote

Does anyone here prefer to write "Delphi-Style" Java? Essentially you
would write Java code but be able to build
your J2EE application using many rich UI controls, objects, functions that
are just like Delphi. This would leverage your Delphi skills and enable you
to build a sandard J2EE application with HTML front-end that has a very rich
UI. Roughly 80% of the Java code would be automatically generated for you
and you would work mostly in JBuilder's Design view rather than Source view.
Quote

Thanks,
Ali
 

{smallsort}

Re:Anybody Prefer to Write Delphi-Style Java?

Ali Kamal wrote:
Quote

Does anyone here prefer to write "Delphi-Style" Java? Essentially you
would write Java code but be able to build
your J2EE application using many rich UI controls, objects, functions that
are just like Delphi. This would leverage your Delphi skills and enable
you to build a sandard J2EE application with HTML front-end that has a
very rich UI. Roughly 80% of the Java code would be automatically
generated for you and you would work mostly in JBuilder's Design view
radher than Source view.

Thanks,
Ali
I apologize, bed I do not understand what this means? How can you RAD J2EE
deve|o`}ent?
HTTP is a stateless protocols, so you do not have anything resembling event
driven programming (as in Swing or Delphi's TForm, TEdits, etc). Hopefully,
this can change somewhat with Java Server Faces, and is semi possible with
struts (though there are no visual designers for struts, AFAIK).
You could, of course, do something similar to this using applets, but you
are going to hit the applet sandbox issues pretty quickly. If you code sign
the applets, of course, you can make this work to a degree. You can also
opt for Java Web Start, which is better than0applets, IMHO.
thinlets offer some possibilities for whad you seek, FWIU. I have not used
them, so I am not speaking from experience. Prhaps someone else has and can
relate their ufvectiveness.
Radding Session and Entity beans can be done through the JB designer, but
drag and dropping these onto a JPanel, or quickly connecting them to a
JTextField, JTextArea, etc, I do not know how you would do this without
investing alot of work to create such a JTextField bound EJB connection.
Yes, it is possible, and would not be a bad idea, IMHO.
As one who grew up with Delphi and then started using Java 5 years ago
(while still doiung Delphi as well), I do not really know how you "Delphi"
code Java 2EE. The two are meant for two different models, unless you are
speaking of Swing related applications. If so, these abilities already
exist in JBuilder, Net Beans, and Oracle JDeveloper, but not for Java 2EE.
In fact, RAD is difficult in Delphi for Server Centric programming as well.
 

Re:Anybody Prefer to Write Delphi-Style Java?

I believe JBuilder can automatically generate roughly 5-10% of the code. Am I correct? I have seen IBM's New Rational Developer (Model-Driven Development) that can generate up to 80% of the code. I was at a conference where they built the Java Pet Store with only 300 lines of code.
Ali
"WongChiHung" < XXXX@XXXXX.COM >wrote:
Quote
80% of code? I dont think so~

"Ali Kamal" < XXXX@XXXXX.COM >wrote in message
news:3f55765a$ XXXX@XXXXX.COM ...
>
>Does anyone here prefer to write "Delphi-Style" Java? Essentially you
would write Java code but be able to build
>your J2EE application using many rich UI controls, objects, functions that
are just like Delphi. This would leverage your Delphi skills and enable you
to build a sandard J2EE application with HTML front-end that has a very rich
UI. Roughly 80% of the Java code would be automatically generated for you
and you would work mostly in JBuilder's Design view rather than Source view.
>
>Thanks,
>Ali


 

Re:Anybody Prefer to Write Delphi-Style Java?

Great comments. Yes, this would be an RAD J2EE development and you are doing event-driven programming. It is possible to keep the state at the client even with HTTP and without a persistent connection. A pre-built framework fo rich controls, objects, functions, is provided that eliminate a lot of the things that are time consuming and you would need to build yourself typically, such as the JTextField bound EJB connection you mentioned. You essentially would build a client/server style J2EE application that gets deployed as an n-tier HTML application (front-end is only HTML and JavaScript), without having to worry about Web-centric issues, such as state management, etc. Would you prefer to build applicaitons this way? How soon do you think this vision will be realized by the J2EE community, such as JSF and BEA's AOP?
Ali
pNichols < XXXX@XXXXX.COM >wrote:
Quote
Ali Kamal wrote:

>
>Does anyone here prefer to write "Delphi-Style" Java? Essentially you
>would write Java code but be able to build
>your J2EE application using many rich UI controls, objects, functions that
>are just like Delphi. This would leverage your Delphi skills and enable
>you to build a sandard J2EE application with HTML front-end that has a
>very rich UI. Roughly 80% of the Java code would be automatically
>generated for you and you would work mostly in JBuilder's Design view
>radher than Source view.
>
>Thanks,
>Ali

I apologize, bed I do not understand what this means? How can you RAD J2EE
deve|o`}ent?

HTTP is a stateless protocols, so you do not have anything resembling event
driven programming (as in Swing or Delphi's TForm, TEdits, etc). Hopefully,
this can change somewhat with Java Server Faces, and is semi possible with
struts (though there are no visual designers for struts, AFAIK).

You could, of course, do something similar to this using applets, but you
are going to hit the applet sandbox issues pretty quickly. If you code sign
the applets, of course, you can make this work to a degree. You can also
opt for Java Web Start, which is better than0applets, IMHO.

thinlets offer some possibilities for whad you seek, FWIU. I have not used
them, so I am not speaking from experience. Prhaps someone else has and can
relate their ufvectiveness.

Radding Session and Entity beans can be done through the JB designer, but
drag and dropping these onto a JPanel, or quickly connecting them to a
JTextField, JTextArea, etc, I do not know how you would do this without
investing alot of work to create such a JTextField bound EJB connection.
Yes, it is possible, and would not be a bad idea, IMHO.

As one who grew up with Delphi and then started using Java 5 years ago
(while still doiung Delphi as well), I do not really know how you "Delphi"
code Java 2EE. The two are meant for two different models, unless you are
speaking of Swing related applications. If so, these abilities already
exist in JBuilder, Net Beans, and Oracle JDeveloper, but not for Java 2EE.

In fact, RAD is difficult in Delphi for Server Centric programming as well.


 

Re:Anybody Prefer to Write Delphi-Style Java?

In < XXXX@XXXXX.COM >pNichols wrote:
Quote
Ali Kamal wrote:
>Does anyone here prefer to write "Delphi-Style" Java? Essentially
>you would write Java code but be able to build your J2EE application
>using many rich UI controls, objects, functions that are just like
>Delphi. [...]

I apologize, bed I do not understand what this means? How can you RAD
J2EE deve|o`}ent?
Still sleepy (viz, "bed")?
I also have to say that I don't exactly understand
whether Ali is asking a question or proposing a
solution.
However, he touches on a more general aspect of the
state of Java: for all its object orientation, there
is a dearth of components. JDJ has an op-ed piece on
just this issue:
Where are the Components?
sys-con.com/java/article.cfm
Quote
HTTP is a stateless protocols, so you do not have anything resembling
event driven programming (as in Swing or Delphi's TForm, TEdits, etc).
I'm not sure that it follows that since HTTP is stateless,
there's no such thing as an event. See the Barricuda
framework, an alternative to Struts, which indeed has
an event mechanism:
barracuda.enhydra.org/cvs_source/Barracuda/docs/vision.html
Note that Barricuda is based on templates, not JSPs, for
presentation. They speak of a template engine component,
but it represents a rather mild dependence on components.
Quote
Hopefully, this can change somewhat with Java Server Faces, and is
semi possible with struts (though there are no visual designers for
struts, AFAIK).
JavaServer Faces represents a trend toward Web page UI components,
but as in the case of Barricuda, this is a limited take on
what such components really mean to developers.
Other Web application frameworks are already based on components --
e.g., Apple's Web Objects and its open source alternative, Tapestry.
jakarta.apache.org/tapestry/
(I stress _already_, since JavaServer Faces is _still_ not
production ready.)
Quote
You could, of course, do something similar to this using applets,
[...]
Again, this is simply componentization of the UI. The question
"where are the components?" applies equally, or more so, to
the "backend".
Quote
thinlets offer some possibilities ...
I don't think so -- they don't necessarily promote
any additional level of componentization: they are
just a means of serializing the user interface.
The real issue is "why are we re-writing the same
generic-izable stuff over and over in Java, especially
in the J2EE arena?"
What really is needed in terms of components are some
of the following:
1. authentication components,
2. account management components,
3. order management component.
4. others?
These would be drop-in, configurable by property
inspectors, generalized components.
Quote
[...] I do not really know how you
"Delphi" code Java 2EE. The two are meant for
two different models [...]
Actually, I don't see why a J2EE application should
be immune from using components. The problem is,
as pointed out by Ottinger (author of article cited
above) is the disarray that Sun has managed to keep
the Java world in: for example, JavaBeans may have
originally been meant to foster a component industry,
but Sun undermined all of that when it made Swing
so untoolable, and by relegating the definition of
a JavaBean to "a class which has a no-parameter constructor,
and getter/setter methods."
For an idea as to where the software industry should
have already arrived, look for a copy of Brad Cox's
now ancient book, "Object-oriented Programming, An
Evolutionary Approach", published by Addison-Wesley
(it may be out of print now but used copies may be
found). Cox's Web site has some links of interest:
www.virtualschool.edu/cox/
(See his publications page, as well.)
Here's a link which is totally off-topic for this
thread, but may be of interest to some:
www.virtualschool.edu/lang/objectivec/influenceOnJava.html
Paul Furbacher [TeamB]
Save time, search the archives:
info.borland.com/newsgroups/ngsearch.html
Is it in Joi Ellis's Faq-O-Matic?
www.visi.com/~gyles19/fom-serve/cache/1.html
Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.
 

Re:Anybody Prefer to Write Delphi-Style Java?

On 9/3/2003 at 1:06:15 AM, Ali Kamal wrote:
Quote
Does anyone here prefer to write "Delphi-Style" Java?
Please do not multi-post, as it is against the rules for this news
server. You should read the newsgroup guidelines at:
info.borland.com/newsgroups/guide.html
--
Regards,
John McGrath [TeamB]
---------------------------------------------------
Before sending me e-mail, please read:
www.JPMcGrath.net/newsgroups/e-mail.html
 

Re:Anybody Prefer to Write Delphi-Style Java?

Paul Furbacher [TeamB] wrote:
Quote
In < XXXX@XXXXX.COM >pNichols wrote:

>Ali Kamal wrote:

>>Does anyone here prefer to write "Delphi-Style" Java? Essentially
>>you would write Java code but be able to build your J2EE application
>>using many rich UI controls, objects, functions that are just like
>>Delphi. [...]
>
>I apologize, bed I do not understand what this means? How can you RAD
>J2EE deve|o`}ent?

Still sleepy (viz, "bed")?

Seems that way <G>..
Quote
However, he touches on a more general aspect of the
state of Java: for all its object orientation, there
is a dearth of components. JDJ has an op-ed piece on
just this issue:

Where are the Components?

sys-con.com/java/article.cfm


Hey Paul, I am certainly not arguing with the concept. The most costly part
of J2EE development is the fact that we cannot bind the components to the
back end structure as an integrated whole. You are forced to go to the
"build and immediate test" method for each and every JSP to Controller
mechanism you code. This is very time consuming and costly in terms of
development cost. The only other (poor) alternative, is to code everything
in the JSPs and/or create many custom taglibs that will allow you to embed
the taglibs into the HTML based JSPs to handle a semi state management on
the HTML based controls, or include JavaScript code in these TagLibs to
take care of simple things in form validation, OnClick, Mouse events, etc.
That is why building a Java application using Swing or SWT is usually 5
times faster than creating the same JSP application. JSP is not hard to do,
but creating everything from scratch for your site, either in a Struts type
framework or creating your own custom tags and the constant test between
the communication of the JSP to the Servlets/Taglibs, is a royal pain.
Throw EJB into the mix and it even gets harrier.
I certainly agree we ought to have more components available to standardize
a RAD way of doing J2EE Development. My address was not meant to be a "what
would be super nice", but rather to address the current state of affairs.
Quote
>HTTP is a stateless protocols, so you do not have anything resembling
>event driven programming (as in Swing or Delphi's TForm, TEdits, etc).

I'm not sure that it follows that since HTTP is stateless,
there's no such thing as an event. See the Barricuda
framework, an alternative to Struts, which indeed has
an event mechanism:

barracuda.enhydra.org/cvs_source/Barracuda/docs/vision.html

Thanks, I haven't looked at Barracuda, but it may be something of great
value to us, if these features are included. However, here we go with yet
another problem in the mix;-- very little centralized management of sub
projects. Jakarta/Apache does a great job of finding palatable solutions,
but the acceptance and standards process of using all of these technologies
is so fragemented that it requires a team to do nothing but look at new
technologies every week, to see what is useful and doable. I would much
rather have a set of standards that is promoted by a central authority and
validated as useful and the general direction we should go due to
usefulness and proven testing. We have Struts, Barracuda, Velocity, JSTL,
and JSP 1.x-2.x standards,and the coming Java Server Faces, all which will
use different scripting mechanisms. There is no way to keep up with it all
and at the same time, get any real work done.
Quote
Note that Barricuda is based on templates, not JSPs, for
presentation. They speak of a template engine component,
but it represents a rather mild dependence on components.

Precisely what I am referring to above. Frameworks need to be standardized,
not bastardized <G>.
Quote
>Hopefully, this can change somewhat with Java Server Faces, and is
>semi possible with struts (though there are no visual designers for
>struts, AFAIK).

JavaServer Faces represents a trend toward Web page UI components,
but as in the case of Barricuda, this is a limited take on
what such components really mean to developers.

Precisely!!
Quote
Other Web application frameworks are already based on components --
e.g., Apple's Web Objects and its open source alternative, Tapestry.


>thinlets offer some possibilities ...

I don't think so -- they don't necessarily promote
any additional level of componentization: they are
just a means of serializing the user interface.
The real issue is "why are we re-writing the same
generic-izable stuff over and over in Java, especially
in the J2EE arena?"

I do not know about Thinlets by direct experience, that is why I stated
"supposively" and "I have no experience"
Quote
What really is needed in terms of components are some
of the following:

1. authentication components,

True
Quote
2. account management components,

True again
Quote
3. order management component.

True
Quote
4. others?

A new Framework that makes JSP development more RAD or at least will handle
the underlying event management mechanisms in a Java way instead of relying
on Java Script. I do not see this happening until the Browser manufacturers
comply. Since MS will not do so under any cirsumstances, we are stuck where
we are.
I do think that if Netscape had remained the dominent player, we would have
a more standards based browser that would incorporate these added features.
But since MS is only interested in promoting MS and MS based solutions, and
as long as MS rules on the Desktops, we are stuck with what MS will and
will not support. Of course, we are in a totally different scenario on the
server side.
Have a good one Paul and thanks for the comments.
 

Re:Anybody Prefer to Write Delphi-Style Java?

Ali Kamal wrote:
Quote

Great comments. Yes, this would be an RAD J2EE development and you are
doing event-driven programming. It is possible to keep the state at the
client even with HTTP and without a persistent connection. A pre-built
framework fo rich controls, objects, functions, is provided that eliminate
a lot of the things that are time consuming and you would need to build
yourself typically, such as the JTextField bound EJB connection you
mentioned. You essentially would build a client/server style J2EE
application that gets deployed as an n-tier HTML application (front-end is
only HTML and JavaScript), without having to worry about Web-centric
issues, such as state management, etc. Would you prefer to build
applicaitons this way? How soon do you think this vision will be realized
by the J2EE community, such as JSF and BEA's AOP?

Ali

Do not know.. I think JSF is going this route, but the main problem now is
browser acceptance. What I mean is that the browser limitiations and the
non adherence to any real standards, cripple many could be efforts in the
long run. As long as MS remains the overwhelmingly predominent player, MS
will support and promote only MS based and MS bound solutions. Can we
imagine what would happen if Mozilla became the predominent player? Would
they create such standards for Java and PHP that the browser would
automatically use, support. and recognize? Probably, but until MS has 50%
or less marketshare, this will not happen. Look at MS' plans for Office
2003. They want to proprietize the Documents produced and even require an
MS server to use the Office suite. Does that benefit the user community? Of
course not, but if they are successful, it certainly helps pad MS' sales
and profits and therfore its bottom line.
 

Re:Anybody Prefer to Write Delphi-Style Java?

Paul Furbacher [TeamB] < XXXX@XXXXX.COM >wrote in
Quote
I'm not sure that it follows that since HTTP is stateless,
there's no such thing as an event. See the Barricuda
framework, an alternative to Struts, which indeed has
an event mechanism:
The event framework is completely seperated from the any other part of
barracuda. Matter of fact all the differenct parts are decoupled. You can
pick and choose which parts you want to use.
Quote
Note that Barricuda is based on templates, not JSPs, for
presentation. They speak of a template engine component,
but it represents a rather mild dependence on components.
There is a component framework, but the template framework works so well
almost everyone abandons components once they see how well the templates
work. One thing that could be taken as a negative is a reliance on XMLC.
We're working towards using any DOM implentations.
--
Iman
Well, it’s never “happily ever after?because “happily ever after?is you
die. You know, it’s “long enough ever after.?You just deteriorate, and,
then, you die. - Harvey Pekar
 

Re:Anybody Prefer to Write Delphi-Style Java?

pNichols < XXXX@XXXXX.COM >wrote in
Quote
Can we
imagine what would happen if Mozilla became the predominent player? Would
they create such standards for Java and PHP that the browser would
automatically use, support. and recognize?
Check out XUL/XPCOM. It is an open standard, all built on top of
Javascript and XML.
www.mozdev.org/
mab.mozdev.org/ is a great example of how that framework could be
used.
--
Iman
Well, it’s never “happily ever after?because “happily ever after?is you
die. You know, it’s “long enough ever after.?You just deteriorate, and,
then, you die. - Harvey Pekar
 

Re:Anybody Prefer to Write Delphi-Style Java?

Iman L Crawford <ilcrawford.at.hotmail.dot.com>wrote:
Quote
pNichols < XXXX@XXXXX.COM >wrote in
news: XXXX@XXXXX.COM :

>Can we
>imagine what would happen if Mozilla became the predominent player? Would
>they create such standards for Java and PHP that the browser would
>automatically use, support. and recognize?

Check out XUL/XPCOM. It is an open standard, all built on top of
Javascript and XML.

Know about this, problem is it is not universally supported, which brings us
back to the issue of MS support of any standards that they do not own or
promote.
Since Internet Explorer has a user base of 90% plus, using standards
supported by any other browser regulates that your dependent code is
usuable only in an intranet setting, not as a Internet solution. Therein
lies the major problem.
The only way to overcome these limitations, is through the use of some
plug-in archictecture, which again will stymie general usage. Many users
are on dial-up connections and an 8 meg download of a plug-in to run your
application, requires users not only the time that the bandwidth limitation
invokes, but also you, the developer and sistributor, must to be assuried,
that the end users install the plug-in correctly. That requires a major
burden of usability to be shifted to the user. Overall, this is not a good
requirement, and would mandate that the product you produce have limited
target scope and/or use many resources for help desk type support.
The only way I see these limitations to be overcome, is for marketshare to
shift. MS currently, has no incentive to support common standards. They can
support their own proprietary standards, which users follow, simply because
they use, by default, the MS OS which is tied so closely to MS Intenet
Explorer.
Unless and until the MS marketshare is cut to a point where MS has no choice
but to support open standsrds (not speaking of Open Source per se, but
rather open standards), or lose further business opportunities, I do not
see this changing. That is only one reason why I think we need an OS that
is not tied to a company who is also in the application business. If one
company (whoever it may be), also benefits from the applications that run
only on that OS, then any company rightfully, would want to lock their
customer base into proprietary standards that promote not only the sale of
their own OS, but also the products that are tied to that OS. Just common
business practice to support and promote your own over and above the
competition. MS isn't evil in their pursuits, they are actually practical
from a business point of view. Does this mean innovation and better
solutions are stifled in the free market? Of course it does. But MS nor any
other commercial firm will be concerned about a level playing field, they
are interested instead of protecting and growing their own business model.
That is why I think the only way to have a level playing field and let the
best technology compete without limitations tied to a single source or
entity. Since no one owns Linux for instance, the developers are free to
exploit the Linux technology in a way that makes innovative technoloy the
goal, rather than self-promotion.
However, there are caveats to that picture and/or scenario. I can certainly
see how Open Source as a threat to programmers making a living in the long
run, so I do see the case(es) of companies and the development communities
that have a problem with Open Source. But in the OS arena, I also see where
Open Source has the greatest potential of leveling the playing field, at
least until someone comes up with a better model where application
development and innovations are not tied to single company.
If the OS is non promotional in the business sense of the model and no one
company or companies have a vested interest in promoting the OS for profit,
then the application community is free to innovate and make the better
technologies the choice, not a for profit motivation. That is NOT TO SAY
that the companies producing the applications or technology is not free to
profit from their products or development, but rather that the underlying
OS upon which it runs, is open to all to compete for innovation sake.
In other words, the underlying hardware to software communication is open
and free for anyone to improve and exploit, it is not under the control of
a single entity to use, change, and create properietary tie-ins that
naturaly gives the company that produces it a distinct advantage over
everyone else. That is what currently exists, and it is not the best route
or way to go to improve the IT community at large. Why? Because we are at
the nercy of that single entity, whoever it may be, to support competing
technologies which may offer better solutions, but is not in the interest
of supporting a business model that could prove (and eventually would) be
self-defeating to the owning entity.
My hope therefore, is that Linux or something like it, take hold and create
absolute necessities for other companies (in this case MS), to support
standards that are beneficial to either OS and to the community at large.
But until this happens, we are not totally free to innovate, but rather
accomodate or create less than perfect solutions.
 

Re:Anybody Prefer to Write Delphi-Style Java?

Hi,
in a J2EE application UI is not 80% of the code, I don't think in a typical
J2EE application UI exceed 20%, (even less on web-services, or web-based
apps.), by the way there are now many tools that generate much of J2EE based
source codes (for example EJB interface/home)....
by the way do you have any tool like Delphi for generating J2EE codes?
Amir Pashazadeh
"Ali Kamal" < XXXX@XXXXX.COM >wrote in message
Quote

Does anyone here prefer to write "Delphi-Style" Java? Essentially you
would write Java code but be able to build
your J2EE application using many rich UI controls, objects, functions that
are just like Delphi. This would leverage your Delphi skills and enable you
to build a sandard J2EE application with HTML front-end that has a very rich
UI. Roughly 80% of the Java code would be automatically generated for you
and you would work mostly in JBuilder's Design view rather than Source view.
Quote

Thanks,
Ali
 

Re:Anybody Prefer to Write Delphi-Style Java?

I would take vendor demonstrations with a grain silo of salt. Code
generators provide many benefits but they are filling in for the lack of
coherent language hierarchy. There's Java and then you customize the rest.
There are now vertically integrated languages but rather high-level APIs. We
need both and that is the gap filled by modeling tools that are also code
generators.
BTW, what gets genenerated usually requires the brain power of an ameoba.
That is why a higher level language, not a model transducer, will have to
be introduced. The mistake is that we get high-level languages that also
implement, very badly, everything in the low level language. How about a new
language bound to Java, say, Jumbo. Vertical flavors of Jumbo could also be
developed. We have all of this already but as an incoherent collection of
vendor-defined products.
As for Delphi-like, what is it about the Delphi syntax that would make it
better than Java? Are you not really just speaking about an IDE and a
component framework? There is nothing about object-pascal that lends itself
better to this sort of thing than Java does.