Hi Stefan,
I was actually debugging an ASPX page which uses J to build its data when I
answered your question. I now re-read your email and would like to answer some
points directly.
> 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
> alternative to more traditional architectures such as Java+SQL+JBoss - in
> terms of run- time performance, customizability, and programmer efficiency.
>From my development environment, the normal way was to develop first a whole
>module in C# or any .Net language then optimize them afterwards with J. There
>are of course cases where J was integrated from the first step but this are
>special cases. I normally get called in a development meeting when the team
>already has a performance problem.
** Run-time Performance - there is no doubt that tweaking a module with J
always-always have an increase in performance. Unfortunately saying a
"percentage" is relative to what was being accomplished.
** Customizability - since most of the implementation of J in my development
environment is very specific ... customizability is also relative. Take for
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 have 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 structures per
client and the base code customization became minimal.
** Programmer Efficiency - the problem with this is that I technically am the
only main J resource in our company. I have trained a lot of in-house
developers 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 roughly 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 resources
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
sources like
a. data coming from different databases or database servers
b. consolidation of data coming from different source like: EDI, CSV,
output 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, CSV
to FIXED WIDTH files, etc)
4. Really complicated data displays (i.e. reports that requires cubes, pivots,
etc)
5. Processing data for complicated reports
Some weakness of current version of J6 (J7 is still in beta but looking good)
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 language
to J (i.e. J -> C#, C# -> J). A few years back, we built a production planning
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 backend with VB.NET as
the main language. This was a pretty big system because the each Production
Plant has its own database and each country may have more than 1 Production
Plant ... then we allow a user/manager to play around with putting his/her
order on any production plants in the World (well, at least at countries where
we have a factory). When I was pulled-in to re-engineer the project, the first
thing I did was gutted the middle-tier of the system 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 acc
ept inputs. J now handles all data processing which meant I actually
implemented a local database cache in J because data is consolidated 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 managers get
the data from off-site factories).
So to summarize (I am rambling again), I would not create a pure-J system but
instead a hybrid where I would use J where it would be at its best. :)
r/Alex
-----Original Message-----
From: [email protected]
[mailto:[email protected]] 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
files, processing of interface files, etc.
2. Long Running Computations - Raw Material Consumption, Raw Material
Requirements, 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 works
well enough because it can retrieve/process/update/create data to big-iron
databases using ADO.NET and ODBC.
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: [email protected]
[mailto:[email protected]] On Behalf Of Stefan Scott Alexander
Sent: Thursday, June 10, 2010 3:51 PM
To: [email protected]
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
interacts 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
libraries (JAR files) being loaded, row-oriented (versus column-oriented)
nature 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 alternative 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-size
Java+SQL+JBoss application to J (involving roughly 500 tables, with roughly a
million records and 100 columns in the biggest table)?
Would there be any serious "gotchas" I'd run into eventually - features that
are considered standard in polished client-server database apps which would be
difficult or impossible to implement using J? I haven't probed all the ins and
outs of J yet, so I'm still not sure whether I'd be able to use it to satisfy
practical real-world requirements such as the following:
- implement some sort of concurrency mechanism to handle situations where
multiple 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 cell,
a multi-column combo-box control in a cell referencing a foreign key, maybe
even a graphic in a cell), "freezable" left-hand grid columns, etc. - perhaps
by adding some additional OCX controls. [Even though OCX controls are compiled
separately, would J602 still be able to manipulate them dynamically?]
- - - 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) roughly
as well as, say, Java+SQL+JBoss could, then I might be interested in rolling 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
database application from Java+SQL to J, initially targeting just the Windows
platform for deployment. I realize that everything's browser-based these days,
and J701 may be dropping support for the native Windows GUI, but using J602 to
target just Windows as a client platform could still make sense for two
reasons: the continued widespread use of Windows, and the remarkable ability of
J602's interpreter to dynamically manipulate native Windows forms and controls.
The examples below which I've been playing with seem to indicate that J (and
its libraries) can already provide much of the basic infrastructure needed 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 when I
loaded the (million-record) Vehicle Registration table into the Browser example
above, J seemed to freeze. But maybe the example was using a regular grid, and
it would perform better if a virtual grid were used instead. Since J can be
used to implement column-oriented rather than row-oriented databases, 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 features like concurrency,
rich user interface, scaling to large numbers of connections - the kinds of
nice-to-have features which users have come to expect 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 runtime.
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 other
hand, what I've seen so far about J is really impressive - not only for its
ability to handle vector data compactly and quickly without looping, and for
its powerful algebra of functions, but also for the runtime customization
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 interpreted
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 like J
could easily do this, while also providing much more compactness, efficiency,
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
