Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #35915 > unrolled thread
| Started by | Knute Johnson <nospam@rabbitbrush.frazmtn.com> |
|---|---|
| First post | 2016-11-21 11:06 -0600 |
| Last post | 2016-11-27 16:42 -0800 |
| Articles | 12 on this page of 92 — 13 participants |
Back to article view | Back to comp.lang.java.programmer
Scaling java app Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-11-21 11:06 -0600
Re: Scaling java app Martin Gregorie <martin@address-in-sig.invalid> - 2016-11-21 19:48 +0000
Re: Scaling java app Eric Douglas <e.d.programmer@gmail.com> - 2016-11-21 12:33 -0800
Re: Scaling java app Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-11-21 18:23 -0600
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-21 21:22 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-21 21:25 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-21 22:29 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-21 22:41 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-22 10:51 -0500
Re: Scaling java app a.laforgia@gmail.com - 2016-11-23 04:58 -0800
Re: Scaling java app Eric Douglas <e.d.programmer@gmail.com> - 2016-11-23 05:18 -0800
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-23 09:52 -0500
Re: Scaling java app Eric Douglas <e.d.programmer@gmail.com> - 2016-11-23 07:51 -0800
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-23 09:46 -0500
Re: Scaling java app Eric Douglas <e.d.programmer@gmail.com> - 2016-11-23 08:07 -0800
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-23 12:10 -0500
Re: Scaling java app Eric Douglas <e.d.programmer@gmail.com> - 2016-11-23 10:39 -0800
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-23 14:57 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-23 15:04 -0500
Re: Scaling java app a.laforgia@gmail.com - 2016-11-24 02:01 -0800
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-24 09:10 -0500
Re: Scaling java app a.laforgia@gmail.com - 2016-11-25 03:48 -0800
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-25 09:58 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-25 10:22 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-25 10:34 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-26 00:01 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-26 09:05 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-26 09:52 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-21 19:46 -0500
Re: Scaling java app Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-11-21 21:12 -0600
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-21 22:44 -0500
Re: Scaling java app Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-11-22 09:56 -0600
Re: Scaling java app Silvio <silvio@internet.com> - 2016-11-22 20:07 +0100
Re: Scaling java app Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-11-22 18:00 -0600
Re: Scaling java app Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-11-22 19:35 -0600
Re: Scaling java app Silvio <silvio@internet.com> - 2016-11-24 00:51 +0100
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-23 10:26 -0500
Re: Scaling java app Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-11-23 15:54 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-23 20:46 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-23 12:00 -0500
Re: Scaling java app Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2016-11-23 19:53 -0600
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-23 21:21 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-23 21:34 -0500
Re: Scaling java app Eric Douglas <e.d.programmer@gmail.com> - 2016-11-28 05:06 -0800
Re: Scaling java app Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2016-11-24 20:45 +0800
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-24 09:12 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-25 10:32 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-26 00:05 -0500
Re: Scaling java app Martin Gregorie <martin@address-in-sig.invalid> - 2016-11-26 15:24 +0000
Re: Scaling java app Eric Douglas <e.d.programmer@gmail.com> - 2016-11-28 05:08 -0800
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-28 19:51 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-28 21:18 -0500
Re: Scaling java app lewbloch@gmail.com - 2016-11-29 13:50 -0800
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 16:53 -0500
Re: Scaling java app lewbloch@gmail.com - 2016-12-01 13:27 -0800
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 16:45 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-12-01 22:07 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:35 -0500
Re: Scaling java app Gene Wirchenko <genew@telus.net> - 2016-12-02 08:53 -0800
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 15:05 -0500
Re: Scaling java app Martin Gregorie <martin@address-in-sig.invalid> - 2016-12-02 20:25 +0000
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 16:20 -0500
Re: Scaling java app Martin Gregorie <martin@address-in-sig.invalid> - 2016-12-02 18:33 +0000
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 15:16 -0500
Re: Scaling java app Martin Gregorie <martin@address-in-sig.invalid> - 2016-12-02 22:57 +0000
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 19:25 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-12-02 22:18 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 22:28 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-12-02 22:36 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 11:27 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-12-02 22:05 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 22:30 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-12-02 22:41 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 11:29 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-12-02 22:00 -0500
Re: Scaling java app lewbloch@gmail.com - 2016-12-02 11:40 -0800
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 15:17 -0500
Re: Scaling java app lewbloch@gmail.com - 2016-12-02 16:26 -0800
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 20:46 -0500
Re: Scaling java app Eric Douglas <e.d.programmer@gmail.com> - 2016-12-02 12:44 -0800
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-12-02 21:57 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 22:40 -0500
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-12-02 22:51 -0500
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 11:42 -0500
Re: Scaling java app Andreas Leitgeb <avl@logic.at> - 2016-12-02 15:43 +0000
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-12-02 21:19 -0500
Re: Scaling java app Martin Gregorie <martin@address-in-sig.invalid> - 2016-12-02 10:28 +0000
Re: Scaling java app Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:37 -0500
Re: Scaling java app Gene Wirchenko <genew@telus.net> - 2016-12-02 09:00 -0800
Re: Scaling java app Eric Douglas <e.d.programmer@gmail.com> - 2016-12-01 13:50 -0800
Re: Scaling java app Arne Vajhøj <arne@vajhoej.dk> - 2016-11-25 10:30 -0500
Re: Scaling java app Roedy Green <inquiry@mindprod.com> - 2016-11-27 16:42 -0800
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-12-02 21:57 -0500 |
| Message-ID | <o1tcab$jo0$1@gioia.aioe.org> |
| In reply to | #36017 |
On 12/2/2016 10:35 AM, Jerry Stuckle wrote: > On 12/1/2016 10:07 PM, Arne Vajhøj wrote: >> On 12/1/2016 4:45 PM, Jerry Stuckle wrote: >>> It's more than just inertia. It's because COBOL has packed decimal >>> format, which is directly compatible with major databases DECIMAL >>> data type. >>> >>> Packed decimal on the mainframes is good to 31 significant digits by >>> default (there are libraries to extend that), although in most cases >>> only 18 to 20 are required. >> >> Most languages support fixed point math today. >> >> Java got BigDecimal with arbitrary precision. .NET languages got decimal >> with 95 bits of precision. C++ got various libraries (may be a little >> bit cumbersome, but not more than it can be made working). >> >> The support for fixed point data types has not been a good reason >> for COBOL for 15-20 years. > > But is it compatible with the DECIMAL data type on databases? Can you > *efficiently* read and write DECIMAL types to DB2, instance? JDBC (which will be below practically all relational database usage in Java) supports DECIMAL/BigInteger the same way as any other datatype like INTEGER/int or VARCHAR/String. Somewhat similar for ADO.NET, .NET and decimal. > And exactly how does Java interface efficiently with databases like DB2? In practice the type 2 or the type 4 JDBC driver. In theory it could also be SQLJ. But I have never met a living person that has used SQLJ. > Java only has the equivalent of dynamic SQL, That depends on what is meant by dynamic SQL. In most terminologies a JDBC PreparedStatement would be considered static. But with a traditional DB2 embedded SQL terminology, then it would be considered dynamic > where every SQL statement > must be interpreted by the database. Usually the execution plan will be cached in the database. > Additionally, the connection to > the database is relatively slow. The connection speed must depend more on the physical connection than on what software is doing the connect. > COBOL has libraries which interface directly with the database, and, > using DB2 as an example (only because it's the one I'm most familiar > with), there is a preprocessor which interprets the SQL statements > *once* at compile time, and stores the resulting access plan in the > database. This saves significant time interpreting the SQL and building > the access plan. Embedded SQL is well-known. You can even do it Java: SQLJ. But as already stated then that is a very rare animal. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-02 22:40 -0500 |
| Message-ID | <o1tens$ns8$1@jstuckle.eternal-september.org> |
| In reply to | #36037 |
On 12/2/2016 9:57 PM, Arne Vajhøj wrote: > On 12/2/2016 10:35 AM, Jerry Stuckle wrote: >> On 12/1/2016 10:07 PM, Arne Vajhøj wrote: >>> On 12/1/2016 4:45 PM, Jerry Stuckle wrote: >>>> It's more than just inertia. It's because COBOL has packed decimal >>>> format, which is directly compatible with major databases DECIMAL >>>> data type. >>>> >>>> Packed decimal on the mainframes is good to 31 significant digits by >>>> default (there are libraries to extend that), although in most cases >>>> only 18 to 20 are required. >>> >>> Most languages support fixed point math today. >>> >>> Java got BigDecimal with arbitrary precision. .NET languages got decimal >>> with 95 bits of precision. C++ got various libraries (may be a little >>> bit cumbersome, but not more than it can be made working). >>> >>> The support for fixed point data types has not been a good reason >>> for COBOL for 15-20 years. >> >> But is it compatible with the DECIMAL data type on databases? Can you >> *efficiently* read and write DECIMAL types to DB2, instance? > > JDBC (which will be below practically all relational database usage > in Java) supports DECIMAL/BigInteger the same way as any other datatype > like INTEGER/int or VARCHAR/String. > > Somewhat similar for ADO.NET, .NET and decimal. > Yes, and those are very inefficient when dealing with DECIMAL datatypes. >> And exactly how does Java interface efficiently with databases like DB2? > > In practice the type 2 or the type 4 JDBC driver. > > In theory it could also be SQLJ. But I have never met a living person > that has used SQLJ. > Which is still less efficient than the native calls. >> Java only has the equivalent of dynamic SQL, > > That depends on what is meant by dynamic SQL. > > In most terminologies a JDBC PreparedStatement would be > considered static. > > But with a traditional DB2 embedded SQL terminology, then > it would be considered dynamic > That is true. But it is not static SQL, which is what we are discussing. >> where every SQL statement >> must be interpreted by the database. > > Usually the execution plan will be cached in the database. > "Usually". Not always. And for how long? >> Additionally, the connection to >> the database is relatively slow. > > The connection speed must depend more on the physical connection > than on what software is doing the connect. > In your PCs, yes. Not true on mainframes (and hasn't been for at least 40 years). Multiple fiber optic channels transferring data concurrently via DMA, disks with transfer rates as good or better than SSDs on PCs, huge caches on the disk controllers... I/O transfer rate is where mainframes excel. >> COBOL has libraries which interface directly with the database, and, >> using DB2 as an example (only because it's the one I'm most familiar >> with), there is a preprocessor which interprets the SQL statements >> *once* at compile time, and stores the resulting access plan in the >> database. This saves significant time interpreting the SQL and building >> the access plan. > > Embedded SQL is well-known. > Embedded SQL is not necessarily static SQL. > You can even do it Java: SQLJ. But as already stated then > that is a very rare animal. > > Arne > You have shown you have no knowledge of mainframes, big database operations in other languages, or static SQL. I'd suggest you quite before you make a bigger fool of yourself. But I know you won't. You've shown before that you will continue to argue out of a position of ignorance, just to argue. Face it - there are some things you are NOT an expert on - and in this case, you aren't even a novice. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-12-02 22:51 -0500 |
| Message-ID | <o1tfgm$n67$1@gioia.aioe.org> |
| In reply to | #36044 |
On 12/2/2016 10:40 PM, Jerry Stuckle wrote: > On 12/2/2016 9:57 PM, Arne Vajhøj wrote: >> On 12/2/2016 10:35 AM, Jerry Stuckle wrote: >>> On 12/1/2016 10:07 PM, Arne Vajhøj wrote: >>>> On 12/1/2016 4:45 PM, Jerry Stuckle wrote: >>>>> It's more than just inertia. It's because COBOL has packed decimal >>>>> format, which is directly compatible with major databases DECIMAL >>>>> data type. >>>>> >>>>> Packed decimal on the mainframes is good to 31 significant digits by >>>>> default (there are libraries to extend that), although in most cases >>>>> only 18 to 20 are required. >>>> >>>> Most languages support fixed point math today. >>>> >>>> Java got BigDecimal with arbitrary precision. .NET languages got decimal >>>> with 95 bits of precision. C++ got various libraries (may be a little >>>> bit cumbersome, but not more than it can be made working). >>>> >>>> The support for fixed point data types has not been a good reason >>>> for COBOL for 15-20 years. >>> >>> But is it compatible with the DECIMAL data type on databases? Can you >>> *efficiently* read and write DECIMAL types to DB2, instance? >> >> JDBC (which will be below practically all relational database usage >> in Java) supports DECIMAL/BigInteger the same way as any other datatype >> like INTEGER/int or VARCHAR/String. >> >> Somewhat similar for ADO.NET, .NET and decimal. > > Yes, and those are very inefficient when dealing with DECIMAL datatypes. They transfer as fine as any other data type. All operations on them work. One meed to accept method calls instead of operators, but that is manageable. >>> And exactly how does Java interface efficiently with databases like DB2? >> >> In practice the type 2 or the type 4 JDBC driver. >> >> In theory it could also be SQLJ. But I have never met a living person >> that has used SQLJ. >> > > Which is still less efficient than the native calls. It uses the same mechanisms as embedded SQL in other languages including COBOL. >>> where every SQL statement >>> must be interpreted by the database. >> >> Usually the execution plan will be cached in the database. >> > > "Usually". Not always. And for how long? It all depends on the database. A lot of databases purge when they need to free memory, so if there is memory available, then it will stay to the database is restarted. >>> Additionally, the connection to >>> the database is relatively slow. >> >> The connection speed must depend more on the physical connection >> than on what software is doing the connect. >> > > In your PCs, yes. Not true on mainframes (and hasn't been for at least > 40 years). Multiple fiber optic channels transferring data concurrently > via DMA, disks with transfer rates as good or better than SSDs on PCs, > huge caches on the disk controllers... I/O transfer rate is where > mainframes excel. Speed between database and storage does not matter much for connection speed. That depends more on the speed between the application and the database. But even if that was not the case, then it just determines whether connection is fast or slow - it does not make connection speed different between different types of connects. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-03 11:42 -0500 |
| Message-ID | <o1usjj$qgq$1@jstuckle.eternal-september.org> |
| In reply to | #36046 |
On 12/2/2016 10:51 PM, Arne Vajhøj wrote: > On 12/2/2016 10:40 PM, Jerry Stuckle wrote: >> On 12/2/2016 9:57 PM, Arne Vajhøj wrote: >>> On 12/2/2016 10:35 AM, Jerry Stuckle wrote: >>>> On 12/1/2016 10:07 PM, Arne Vajhøj wrote: >>>>> On 12/1/2016 4:45 PM, Jerry Stuckle wrote: >>>>>> It's more than just inertia. It's because COBOL has packed decimal >>>>>> format, which is directly compatible with major databases DECIMAL >>>>>> data type. >>>>>> >>>>>> Packed decimal on the mainframes is good to 31 significant digits by >>>>>> default (there are libraries to extend that), although in most cases >>>>>> only 18 to 20 are required. >>>>> >>>>> Most languages support fixed point math today. >>>>> >>>>> Java got BigDecimal with arbitrary precision. .NET languages got >>>>> decimal >>>>> with 95 bits of precision. C++ got various libraries (may be a little >>>>> bit cumbersome, but not more than it can be made working). >>>>> >>>>> The support for fixed point data types has not been a good reason >>>>> for COBOL for 15-20 years. >>>> >>>> But is it compatible with the DECIMAL data type on databases? Can you >>>> *efficiently* read and write DECIMAL types to DB2, instance? >>> >>> JDBC (which will be below practically all relational database usage >>> in Java) supports DECIMAL/BigInteger the same way as any other datatype >>> like INTEGER/int or VARCHAR/String. >>> >>> Somewhat similar for ADO.NET, .NET and decimal. >> >> Yes, and those are very inefficient when dealing with DECIMAL datatypes. > > They transfer as fine as any other data type. > Working is not the same as working efficiently. But once again you show you have clue. > All operations on them work. One meed to accept method calls instead > of operators, but that is manageable. > Working is not the same as working efficiently. But once again you should you have no clue. >>>> And exactly how does Java interface efficiently with databases like >>>> DB2? >>> >>> In practice the type 2 or the type 4 JDBC driver. >>> >>> In theory it could also be SQLJ. But I have never met a living person >>> that has used SQLJ. >>> >> >> Which is still less efficient than the native calls. > > It uses the same mechanisms as embedded SQL in other languages > including COBOL. > No, it does not. Compiled languages such as COBOL make direct calls to the DB via DB libraries. JDBC must go through at least one additional driver to connect to those same libraries. They end up in the same place, but it is not the same mechanism. But once again you show you have no clue. >>>> where every SQL statement >>>> must be interpreted by the database. >>> >>> Usually the execution plan will be cached in the database. >>> >> >> "Usually". Not always. And for how long? > > It all depends on the database. > > A lot of databases purge when they need to free memory, so if there > is memory available, then it will stay to the database is restarted. > Cached in memory is not the same as stored in the database. And even on a mainframe, memory is often at a premium. There are many more valuable uses for memory than caching access plans. Additionally, when the execution plan is cached in memory, the RDBM must search to see if that plan still exists in memory, clean up execution plans which have not been used for a while when memory is used, and all kinds of other housekeeping. None of this is required with static SQL and stored access plans. Plans are indexed in the database, and the call to the database requests the access plan by its index. Access is very fast with little or no overhead. >>>> Additionally, the connection to >>>> the database is relatively slow. >>> >>> The connection speed must depend more on the physical connection >>> than on what software is doing the connect. >>> >> >> In your PCs, yes. Not true on mainframes (and hasn't been for at least >> 40 years). Multiple fiber optic channels transferring data concurrently >> via DMA, disks with transfer rates as good or better than SSDs on PCs, >> huge caches on the disk controllers... I/O transfer rate is where >> mainframes excel. > > Speed between database and storage does not matter much for connection > speed. That depends more on the speed between the application and the > database. > You've got to be kidding. You really believe that storage speed doesn't matter? Now I know you're an idiot. > But even if that was not the case, then it just determines whether > connection is fast or slow - it does not make connection speed > different between different types of connects. > > Arne > > No, but the amount of work that has to be done between the code and the database makes a huge difference. Arne, I know you know nothing about compiled languages, mainframes, or whatever. You think Java is the slickest thing since snot on a doorknob and it is the only language anyone should ever use. Your arguments show that opinion, to the extent you make wild-ass claims which have no basis in reality. It is very obvious you have no idea what you are talking about. Java has its uses, that I will admit. But there are other languages much better suited for different situations. Fortunately, millions of programmers around the world understand that, and understand how to select an an appropriate language for the situation. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Date | 2016-12-02 15:43 +0000 |
| Message-ID | <slrno435ng.uka.avl@login.logic.tuwien.ac.at> |
| In reply to | #36012 |
Arne Vajhøj <arne@vajhoej.dk> wrote: > Most languages support fixed point math today. > Java got BigDecimal with arbitrary precision. Yes, Java has got BigDecimal. Code which in other languages looks like: 42+a+2*b looks like the following in Java: new BigDecimal(42).add(a).add(new BigDecimal(2).multiply(b)) but we can check the box saying that Java has got BigDecimal.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-12-02 21:19 -0500 |
| Message-ID | <o1ta3l$hc3$1@gioia.aioe.org> |
| In reply to | #36020 |
On 12/2/2016 10:43 AM, Andreas Leitgeb wrote: > Arne Vajhøj <arne@vajhoej.dk> wrote: >> Most languages support fixed point math today. >> Java got BigDecimal with arbitrary precision. > > Yes, Java has got BigDecimal. Code which in other languages > looks like: 42+a+2*b looks like the following in Java: > > new BigDecimal(42).add(a).add(new BigDecimal(2).multiply(b)) > > but we can check the box saying that Java has got BigDecimal. The syntax is not elegant. But the functionality is there. And if you create named objects for the constants then it is not that bad. FORTYTWO.add(a).add(TWO.multiply(b)) or rearranged: a.add(b.multiply(TWO)).add(FORTYTWO) People live it with it. Arne
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-12-02 10:28 +0000 |
| Message-ID | <o1rica$ddh$1@dont-email.me> |
| In reply to | #36009 |
On Thu, 01 Dec 2016 16:45:04 -0500, Jerry Stuckle wrote: > It's more than just inertia. It's because COBOL has packed decimal > format, which is directly compatible with major databases DECIMAL data > type. > Given that COBOL preceded all major databases, its more accurate to say that the major databases introduced the DECIMAL data type for compatibility with COBOL. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-02 10:37 -0500 |
| Message-ID | <o1s4ci$fc6$2@jstuckle.eternal-september.org> |
| In reply to | #36013 |
On 12/2/2016 5:28 AM, Martin Gregorie wrote: > On Thu, 01 Dec 2016 16:45:04 -0500, Jerry Stuckle wrote: > >> It's more than just inertia. It's because COBOL has packed decimal >> format, which is directly compatible with major databases DECIMAL data >> type. >> > Given that COBOL preceded all major databases, its more accurate to say > that the major databases introduced the DECIMAL data type for > compatibility with COBOL. > > Yes, I would have to agree that is more accurate. The DECIMAL type was created for DB2 (long before any SQL standard existed) mainly for businesses using Packed Decimal. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2016-12-02 09:00 -0800 |
| Message-ID | <3p934ctnvt909etlc13kohmmocplg1ve8l@4ax.com> |
| In reply to | #36013 |
On Fri, 2 Dec 2016 10:28:26 -0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> wrote:
>On Thu, 01 Dec 2016 16:45:04 -0500, Jerry Stuckle wrote:
>
>> It's more than just inertia. It's because COBOL has packed decimal
>> format, which is directly compatible with major databases DECIMAL data
>> type.
>>
>Given that COBOL preceded all major databases, its more accurate to say
>that the major databases introduced the DECIMAL data type for
>compatibility with COBOL.
I would say that COBOL had decimal arithmetic for good reason,
and that reason fits for DBMSs, too, so they have it, too.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-12-01 13:50 -0800 |
| Message-ID | <2a97874c-824c-45d7-9a63-f5edc9c52350@googlegroups.com> |
| In reply to | #36007 |
On Thursday, December 1, 2016 at 4:27:58 PM UTC-5, lewb...@gmail.com wrote: > > I don't know about that being a question of needs as such, but of inertia. Government and other large organizations tend to have a massive amount of business intelligence already embodied in large COBOL systems, compared to retailers, not because their needs differ but because larger organizations got into the computer game earlier. I suppose you could say that affects their "needs", but I find that description misleading. > > -- > Lew http://www.npr.org/sections/alltechconsidered/2016/10/27/499642220/obama-urges-a-boost-in-it-spending-to-secure-federal-computers
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-11-25 10:30 -0500 |
| Message-ID | <o19ldp$mk1$1@gioia.aioe.org> |
| In reply to | #35957 |
On 11/24/2016 7:45 AM, Richard Maher wrote: > On 24-Nov-16 10:21 AM, Arne Vajhøj wrote: >> I think Oracle was very nice that they actually got JavaFX >> completed. > > The fact that you still see JavaFX as viable says all we need to know :-( Viable for where Swing was viable before. Java desktop apps is not a super big thing. Consumer apps usually go native and business apps usually either go web or Microsoft. But there is some market left where web for whatever reason does not work and either cross platform is a requirement or Java skills are available. That was once done via Swing. And those Swing apps are still being maintained - I doubt many of those is being ported to JavaFX - it is just not worth it. But for a new app then JavaFX seems obvious to me. It is simply better. Not that Swing is really bad, but fat client GUI technology has simply evolved the last 15 years. And JavaFX are leveraging that. > Either way Java continues to be the new Cobol. Good luck. Maybe. But given Java's presence in new stuff like Android and big data, then I think Java is like where Cobol was in 1975-1980. It has not even reached its peak yet. Arne
[toc] | [prev] | [next] | [standalone]
| From | Roedy Green <inquiry@mindprod.com> |
|---|---|
| Date | 2016-11-27 16:42 -0800 |
| Message-ID | <odsm3c5fc1jjvr0rvbr42k9ap7c314tcee@4ax.com> |
| In reply to | #35915 |
On Mon, 21 Nov 2016 11:06:59 -0600, Knute Johnson <nospam@rabbitbrush.frazmtn.com> wrote: >Is there a generic way to scale a Java app when it runs under Windows? One way to do this add magnification/zoom menu item. You use a slider to decide. Save the setting in the registry with the Persistence mechanism. This also helps someone with poor eyesight.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.java.programmer
csiph-web