× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Hello,

Some comments:

1. Although principles of OO seems to be easy it is really difficult to
built robust OO application, with a good architecture.
You need experienced people to do that. It is not necessarly specialist
of Java but specialist of Object Orientation.
My opinion is that you must accept to engage experienced OO designer and
developper, and ask them to design and help the other people of the team.

The experience we have here is that the group of experienced Java developper
developped fast their application, while the learners faced lot of problems.

2. I am not sure to understand the point 2, but it looks like an
architecture
design problem. It depends on what you really want to do, but there are way
to develop reports for free using XML, XSL, FOP, you can then generate html,
pdf,
or whatever you want.
If you have a browser based application you can also use Cocoon to do that.
It is free from the Apache Foundation.

There is also Java reporting tools based on Crystal Report.

For our internet project, i will provide soon reporting facilities based on
Cocoon. I just need to describe my data in XML, transform them using XSL and
FOP, and Cocoon will manage the whole. It is completly free and very easy to
develop. As our web "services" already describes the data in XML, we just
have
to write the appropriate XSL file to generate the report in PDF. One guy
is responsible to write the XSL files to generate the PDF. He doesn't need
any knowledge of Java, C++, only XSL.

What you are talking about is also "interoperability". How can we make tools
communicate together, especially when they are in different languages like
C++, Java,
RPG?

We have decided to use XML to exchange data between applications. We
sometimes
use MQSeries as transport mechanism. In this case you don't have to "export"
database
object. Generally you should never expose database object to other
applications,
you must have an abastraction layer. It will hide the complexity and only
focuses on services. XML is then very useful to pass the data to these
services.

3. Once again your problem looks like an architecture choice. If you have a
server
to provide this information you can insure that only one client at a time
get
an identifier from the database. You just have to synchronize the method
that get the id from the database.
If you have written a a fat client application, you can also use different
technics:
- use a stored procedure that will manage itself a lock on the table of the
identifier
- write a method that locks the access while one application is getting an
id


To summarize: my feeling is that you had all of these problems because your
java developper and designer were not experienced enough. It seems that your
difficulties can be solved with different architecture.

The problem you faced are not related to Java, but working in a client
server
environment. You would have have exactly the same problem working with
other languages.

My opinion is also that these kind of problems should never be solved by
technic solutions (like how to pass a database object to Crystal Reports),
but by design solutions.

You must write abstraction layer between each level (DB, BO, UI), and also
between the applications.

But, before to be able to do that, you must be really experienced. In OO you
build
blocks and architecture to build block, you don't add lines to a program.

>From my experience, the recent use of XML and XSL gave us a lot of solutions
to problems that could have been very technical:
- exchange data between java programs and our legacy application
- exchange data between very heteregenous systems and some very old ones
- generate reports easily, for free.

Now my only experience is on object orientation. My opinion is that Java is
a very good choice. I could not come back to C++.

What i also see is some human problems. Some very experienced RPG
programmers
must accept that they can't do very good java programming untill one year,
just
because you must really understand object orientation. This is a task of the
management to manage the learning curve and to hire the appropriate persons
to ease the process.

Cheers

Gilles

-----Original Message-----
From: Vijosh A [mailto:vijosh@systsoft.com]
Sent: mardi, 9. octobre 2001 08:54
To: java400-l@midrange.com; web400@midrange.com
Subject: Java App. Development - Is it Worth ?



Hi all,

we have been developing a java based application for the past 1 year. the
first phase is almost over. some of the issues we faced are -

        1. Lack of experienced people in Java. For starters also, RPG
learning
takes much less time . They program and start delivering in 2 months time.
Whereas with Java people get bogged down with nitty gritties of Java and
Object Orientation to an extent where they often forget the business logic
itself. For e.g. if you have 3 to 4 combo boxes on the screen and if one
triggers the filling of other and vice versa, the listeners really play
squash. YOU OVER SHOOT TIME LIMITS, FRUSTRATION FOLLOWS, A CUT IN YOUR PAY
CHECK ARE THE CONSEQUENCES.

        2. When it comes to developing reports like the ones developed &
implemented using RLU - EXCPT (RPG OpCode, it is another set of woes. You
don't have many reporting tools that integrates with java. They are too
expensive too. If you go for Crystal Reports, then u need to write a C++
interface. Still u don't have any control over Crystal Report once it is
invoked through this interface. Crystal Reports does not recognize the
database object passed by java, whereas it does understand the result sets
sent by VB etc. HERE WE STAND THE RISK OF LOSING THE CUSTOMERS CONFIDENCE
WHEN HE DOES NOT GET REPORTS AS HE USED TO GET WHILE USING AN RPG
APPLICATION.

        3. Next is the problem with ID generation. Suppose u want continuous
generation of employee ID's in a sequential manner. So if u keep the last ID
in a physical file and decide to use a trigger-program combination(which was
the only solution we found to be feasible)then comes the next set of
problems. In a mulitple user environment 2 users can get the same id. To
prevent this  we use a Data Queue. And put the generated ID into the Data
Queue thereby making it possible for requester program to pick it up from
the Data Queue. PALTFORM INDEPENDENCE IS COMPROMISED.

To sum it up, the amount of learning a new guy needs to do and the amount of
self moulding of one's thinking when programming with java is too high. This
leaves both the employee and the employer disillusioned !!!

Thanx for your patience and sorry. Now my question, does everyone face such
problems? If yes what is your approach in solving these issues ? Economic
recession added, Does your company still have the confidence to place bets
on java ?

Thanks

Cheers
Vijosh







>From the Desk of :

Vijosh A.
Senior Consultant
Systems & Software
123, SDF 4, SEEPZ

Andheri (E), Mumbai.

Tel : (91-22) 829 0803/0075
Fax : (91-22) 829 2578


--------------------------------------------------------------
Systems & Software, Mumbai, India
Sent using "The PostMaster" by QuantumLink Communications
One Internet account, unlimited personal e-mail addresses
Get your free copy of "The PostMaster" at http://qlcomm.com/


_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.


**********************************************************************
This E-mail and any files transmitted with it are confidential
and intended for the exclusive use of the addressee(s) only.
 You should not disclose its contents to any other person.
If you are not the intended recipient please notify the sender
immediately.
**********************************************************************


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.