No subject

e module in C# or any .Net language then optimize them afterwards with J. T=
here are of course cases where J was integrated from the first step but thi=
s are special cases. I normally get called in a development meeting when th=
e team already has a performance problem.

** Run-time Performance - there is no doubt that tweaking a module with J a=
lways-always have an increase in performance. Unfortunately saying a "perce=
ntage" is relative to what was being accomplished.
** Customizability - since most of the implementation of J in my developmen=
t environment is very specific ... customizability is also relative. Take f=
or example an EDI parser. I have built a bunch of EDI parsers for A&F, Polo=
 Raph Lauren, adidas, SPRIT, etc. For each of this companies, I actually ha=
ve a base code which I customize for each of our clients. I initially hard-=
coded everything and later-on created J Nouns to handle specific data struc=
tures per client and the base code customization became minimal.
** Programmer Efficiency - the problem with this is that I technically am t=
he only main J resource in our company. I have trained a lot of in-house de=
velopers over the years but most of them use J to just support the existing=
 J modules that they have. What they do use J for is problem solving prior =
to coding the solution to the preferred .NET language.

So you asked:
> Would it make sense, from a practical standpoint, to port a typical, mid-=
size Java+SQL+JBoss application to J (involving roughly 500 tables, with ro=
ughly a million records and 100 columns in the biggest table)?

Short answer: NO

Long answer: Re-engineer your system using the tools that you or your resou=
rces are most familiar and identify where J can best help.

Some suggestion:
1. Process where computation takes more than 2 minutes.
2. Process/Computations that uses more than 3 tables.
3. Process/Computations that uses data/information coming from different so=
urces like
    a. data coming from different databases or database servers
    b. consolidation of data coming from different source like: EDI, CSV, o=
utput from Mainfraimes and MINIs, data coming from OEM/hardware (like Time =
Tracking devices).
    c. Conversion of data from one format to another (EDI->XML, XML->CSV, C=
SV to FIXED WIDTH files, etc)
4. Really complicated data displays (i.e. reports that requires cubes, pivo=
ts, etc)
5. Processing data for complicated reports

Some weakness of current version of J6 (J7 is still in beta but looking goo=
d)
1. Complicated GUI (for those WD masters ... don't hurt me)
2. Data Entry modules
3. Operations that require row by row processing (never use J with this)

Another note, as much as possible, minimize data marshaling from one langua=
ge to J (i.e. J -> C#, C# -> J). A few years back, we built a production pl=
anning system in our company using pure VB.NET. I got called in because re-=
scheduling a production run technically freezes the user's PC. The original=
 system uses GDI+ to draw the GANTT chart and an MS-SQL server at the backe=
nd with VB.NET as the main language. This was a pretty big system because t=
he each Production Plant has its own database and each country may have mor=
e than 1 Production Plant ... then we allow a user/manager to play around w=
ith putting his/her order on any production plants in the World (well, at l=
east at countries where we have a factory). When I was pulled-in to re-engi=
neer the project, the first thing I did was gutted the middle-tier of the s=
ystem and replacing it with J. The database is still MS-SQL server and the =
front-end is GDI+ using VB.NET but this module concern is now only to draw =
the GUI and accept inputs. J now handles all data processing which meant I =
actually implemented a local database cache in J because data is consolidat=
ed from different sources. Of course, this is an oversimplification of what=
 we did (there were a lot of other changes to make sure that high level man=
agers get the data from off-site factories).

So to summarize (I am rambling again), I would not create a pure-J system b=
ut instead a hybrid where I would use J where it would be at its best. :)

r/Alex



-----Original Message-----
From: programming-bounces at jsoftware.com [mailto:programming-bounces at jsoftwa=
re.com] On Behalf Of Alex Rufon
Sent: Thursday, June 10, 2010 5:05 PM
To: Programming forum
Subject: Re: [Jprogramming] Feasibility of mid-size client-server databases=
 in J versus, say, Java+SQL?

Hi Stefan,

I work for a software arm of a multinational company. We use the following:
1. GUI - C#, VB.NET, ASP.NET, ASPX
2. Databases - MS-SQL Server and Oracle

So where does J come it? We use J where its advantageous to do so:
1. Data transformation - importing/transforming EDI documents, AS400 text f=
iles, processing of interface files, etc.
2. Long Running Computations - Raw Material Consumption, Raw Material Requi=
rements, Production Scheduling, etc.
3. Quick/One-off GUI's and interfaces

In relation to your question, I also use J as a local (client-machine) data=
 cache both as an in-memory and a saved-to-disk model. For my needs, J work=
s well enough because it can retrieve/process/update/create data to big-iro=
n databases using ADO.NET and ODBC.=20

Did I answer your question or I'm trolling again? I hope my comments help. =
I'll be willing to answer a more specific question though.

r/Alex


-----Original Message-----
From: programming-bounces at jsoftware.com [mailto:programming-bounces at jsoftwa=
re.com] On Behalf Of Stefan Scott Alexander
Sent: Thursday, June 10, 2010 3:51 PM
To: programming at jsoftware.com
Subject: [Jprogramming] Feasibility of mid-size client-server databases in =
J versus, say, Java+SQL?

Hi -

I see a lot of client-server database applications where a Java client inte=
racts with an SQL database server via an application server such as JBoss.

This is a popular architecture, but in many situations requiring only some =
basic CRUD operations and some simple notions of workflow, it seems to have=
 several drawbacks:

- slow performance, due to the multiple tiers, multiple languages, big libr=
aries (JAR files) being loaded, row-oriented (versus column-oriented) natur=
e of most commercial RDBMSs

- difficult to customize on-the-fly, due to static typing on the Java side =
and the traditional split between DDL and DML on the SQL side

I'm still rather new to J, but I'm impressed with many of its features: its=
 simplicity, performance, its dynamic/interpreted nature, the small size of=
 its interpreter and code, and the possibility of coding both the front end=
 and back end of a system using a single language: J.

So I'm interested in hearing people's opinions as to whether J is suitable =
for mid-size client-server database application development, as an alternat=
ive to more traditional architectures such as Java+SQL+JBoss - in terms of =
run-time performance, customizability, and programmer efficiency.


Would it make sense, from a practical standpoint, to port a typical, mid-si=
ze Java+SQL+JBoss application to J (involving roughly 500 tables, with roug=
hly a million records and 100 columns in the biggest table)?

Would there be any serious "gotchas" I'd run into eventually - features tha=
t are considered standard in polished client-server database apps which wou=
ld be difficult or impossible to implement using J? I haven't probed all th=
e ins and outs of J yet, so I'm still not sure whether I'd be able to use i=
t to satisfy practical real-world requirements such as the following:

- implement some sort of concurrency mechanism to handle situations where m=
ultiple users might be trying to write the same record at the same time

- ensure database ACID properties

- provide a rich user interface including things like:
- - - grids having custom cell editors (eg, a calendar control in a date ce=
ll, a multi-column combo-box control in a cell referencing a foreign key, m=
aybe even a graphic in a cell), "freezable" left-hand grid columns, etc. - =
perhaps by adding some additional OCX controls. [Even though OCX controls a=
re compiled separately, would J602 still be able to manipulate them dynamic=
ally?]
- - - a user-friendly visual query builder similar to the one in MS-Access

- handle large numbers of simultaneous connections efficiently in terms of =
memory space usage and CPU usage

- support updatable views without too much hassle

If people are of the opinion that J could satisfy these sorts of practical =
real-world requirements (plus any other major ones I may have left out) rou=
ghly as well as, say, Java+SQL+JBoss could, then I might be interested in r=
olling up my sleeves and attempting to do some real-world programming J.

Maybe I could start off by porting some existing medium-sized open-source d=
atabase application from Java+SQL to J, initially targeting just the Window=
s platform for deployment. I realize that everything's browser-based these =
days, and J701 may be dropping support for the native Windows GUI, but usin=
g J602 to target just Windows as a client platform could still make sense f=
or two reasons: the continued widespread use of Windows, and the remarkable=
 ability of J602's interpreter to dynamically manipulate native Windows for=
ms and controls.

The examples below which I've been playing with seem to indicate that J (an=
d its libraries) can already provide much of the basic infrastructure neede=
d for building client-server database systems:

http://www.jsoftware.com/jwiki/JDB
http://www.jsoftware.com/jwiki/JDB/ClientServer
http://www.jsoftware.com/jwiki/JDB/Browser

Again, my concern is whether these sorts of simple examples would "scale"
well to mid-size, real-world applications. I noticed, for example, that whe=
n I loaded the (million-record) Vehicle Registration table into the Browser=
 example above, J seemed to freeze. But maybe the example was using a regul=
ar grid, and it would perform better if a virtual grid were used instead. S=
ince J can be used to implement column-oriented rather than row-oriented da=
tabases, I'm not too worried about J's performance as a "calculation server=
". I guess what I'm more worried about, as mentioned above, are other featu=
res like concurrency, rich user interface, scaling to large numbers of conn=
ections - the kinds of nice-to-have features which users have come to expec=
t in polished, professional real-world applications.


Intuitively, the roadmap for such a project seems fairly clear-cut: rewrite=
 the RDBMS tables and views from SQL to J, rewrite the client from Java to =
J, and rewrite the server from Java to J. I'm hoping that the payoff would =
be a new sort of client-server database application: one which is fast and =
compact and easy to customize, maybe even to some degree by end-users at ru=
ntime.

Does that make sense? Am I missing any major pieces of the puzzle here?

I'm still rather new to J. On the one hand, I don't want to overly idealize=
 it, imagining that it can do all kinds of things it can't do. But on the o=
ther hand, what I've seen so far about J is really impressive - not only fo=
r its ability to handle vector data compactly and quickly without looping, =
and for its powerful algebra of functions, but also for the runtime customi=
zation possibilities which I suspect it could offer due to the fact that it=
's interpreted, and the simplicity and flexibility which would result from =
being able to program all tiers of a client-server system in just one inter=
preted language rather than in several compiled ones.

Is there any reason (other than lack of awareness about J) why a real-world=
 mid-size client-server database couldn't be successfully implemented in J =
versus more traditional approaches like Java+SQL? As I said earlier, a lot =
of the big database apps out there is just CRUD + workflow, and it seems li=
ke J could easily do this, while also providing much more compactness, effi=
ciency, simplicity, and customizability.

Thanks for any advice.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm