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
