Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #35915 > unrolled thread

Scaling java app

Started byKnute Johnson <nospam@rabbitbrush.frazmtn.com>
First post2016-11-21 11:06 -0600
Last post2016-11-27 16:42 -0800
Articles 20 on this page of 92 — 13 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →


#35953

FromKnute Johnson <nospam@rabbitbrush.frazmtn.com>
Date2016-11-23 19:53 -0600
Message-ID<o15h3m$eu4$1@dont-email.me>
In reply to#35945
On 11/23/2016 11:00 AM, Arne Vajhøj wrote:
>
>> It's disappointing that at this late stage of the game that Swing
>> doesn't have some sort of adjustment for high DPI displays.  But maybe
>> they want us to move to FX?
>
> I don't think desktop is a priority at all.
>
> Arne
>

I've been playing with Java since 1.0? and writing desktop apps as a 
side job since 1.2.  It's really not a bad environment for desktop apps 
but every body seems to think the desktop is dead but I keep writing and 
they keep paying.

knute...

PS I'll give your code a try after the holiday.

take care

[toc] | [prev] | [next] | [standalone]


#35954

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-11-23 21:21 -0500
Message-ID<o15iqn$d56$1@gioia.aioe.org>
In reply to#35953
On 11/23/2016 8:53 PM, Knute Johnson wrote:
> On 11/23/2016 11:00 AM, Arne Vajhøj wrote:
>>> It's disappointing that at this late stage of the game that Swing
>>> doesn't have some sort of adjustment for high DPI displays.  But maybe
>>> they want us to move to FX?
>>
>> I don't think desktop is a priority at all.
>
> I've been playing with Java since 1.0? and writing desktop apps as a
> side job since 1.2.  It's really not a bad environment for desktop apps
> but every body seems to think the desktop is dead but I keep writing and
> they keep paying.

Swing is a little bit oldfashioned but still OK. JavaFX is rather cool.

You can write fine desktop apps in Java.

And some people do. You are not the only one here that does so.

But Java market share in desktop apps is rather small.

The consumer apps typical want the true native look and feel. Java
is not good at that. There will also frequently be a desire for tigth
integration with a bunch of MS technologies. Java is not good at that
either.

The business apps have largely moved to web apps. And the remaining
are for various reasons probably mostly historic still using
MS technologies.

The result is some users but in the big pictures relative few
users.

And if you look at it from Oracle's perspective, then they
don't make a dime on Java SE - it is all cost. The Java EE
stuff make money (all the ex-BEA stuff that sell licenses
for 5 digit dollar amounts per CPU) and are used for
other stuff that also make a ton of money (ERP & CRM).

I think Oracle was very nice that they actually got JavaFX
completed.

But I can not see Java for desktop being a high priority
at Oracle. It is not where the money is.

Arne

[toc] | [prev] | [next] | [standalone]


#35955

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-11-23 21:34 -0500
Message-ID<o15jk8$du5$1@gioia.aioe.org>
In reply to#35954
On 11/23/2016 9:21 PM, Arne Vajhøj wrote:
> On 11/23/2016 8:53 PM, Knute Johnson wrote:
>> On 11/23/2016 11:00 AM, Arne Vajhøj wrote:
>>>> It's disappointing that at this late stage of the game that Swing
>>>> doesn't have some sort of adjustment for high DPI displays.  But maybe
>>>> they want us to move to FX?
>>>
>>> I don't think desktop is a priority at all.
>>
>> I've been playing with Java since 1.0? and writing desktop apps as a
>> side job since 1.2.  It's really not a bad environment for desktop apps
>> but every body seems to think the desktop is dead but I keep writing and
>> they keep paying.
>
> Swing is a little bit oldfashioned but still OK. JavaFX is rather cool.
>
> You can write fine desktop apps in Java.
>
> And some people do. You are not the only one here that does so.
>
> But Java market share in desktop apps is rather small.
> The consumer apps typical want the true native look and feel. Java
> is not good at that. There will also frequently be a desire for tigth
> integration with a bunch of MS technologies. Java is not good at that
> either.
>
> The business apps have largely moved to web apps. And the remaining
> are for various reasons probably mostly historic still using
> MS technologies.
>
> The result is some users but in the big pictures relative few
> users.

Sometime it is interesting to look at demand.

dice.com:

Java - 15821
Java and J2EE - 3327
Java and Hadoop - 1405
Java and Tomcat - 1241
Java and JSP - 1194
Java and WebSphere - 980
Java and Android - 953
Java and JBoss - 866
Java and WebLogic - 791
Java and Struts - 702
Java and "Spring MVC" - 518
Java and EJB - 423
Java and JSF - 394
Java AND "Java EE" - 331
Java and Servlet - 256
Java and JAX - 192
Java and Swing - 127
Java and JavaFX - 19

There are definitely overlap and job ads are infamous for not being
accurate regarding skills requirements.

But I think it still demonstrate that desktop apps is a niche
in the Java world.

Java EE is number one. And Android and big data are number two and three.

Arne





[toc] | [prev] | [next] | [standalone]


#35981

FromEric Douglas <e.d.programmer@gmail.com>
Date2016-11-28 05:06 -0800
Message-ID<dd921592-e07a-4bb1-a1a9-cb9030076c13@googlegroups.com>
In reply to#35955
On Wednesday, November 23, 2016 at 9:35:01 PM UTC-5, Arne Vajhøj wrote:
> Sometime it is interesting to look at demand.
> 
> dice.com:
> 
> Java - 15821
> Java and J2EE - 3327
> Java and Hadoop - 1405
> Java and Tomcat - 1241
> Java and JSP - 1194
> Java and WebSphere - 980
> Java and Android - 953
> Java and JBoss - 866
> Java and WebLogic - 791
> Java and Struts - 702
> Java and "Spring MVC" - 518
> Java and EJB - 423
> Java and JSF - 394
> Java AND "Java EE" - 331
> Java and Servlet - 256
> Java and JAX - 192
> Java and Swing - 127
> Java and JavaFX - 19
> 
> There are definitely overlap and job ads are infamous for not being
> accurate regarding skills requirements.
> 
> But I think it still demonstrate that desktop apps is a niche
> in the Java world.
> 
> Java EE is number one. And Android and big data are number two and three.

I haven't tried dice.com.  So far I've only checked monster.com, and the only "Java Developer" jobs demand expertise in Java as well as Javascript, HTML, and CSS, or JavaEE.  Everyone seems to be doing something web related, probably because a lot of the jobs are in health care and the government has demanded patient records be available everywhere, for the MA to check them from home, or the private practice to share them with the ER.

[toc] | [prev] | [next] | [standalone]


#35957

FromRichard Maher <maher_rjSPAMLESS@hotmail.com>
Date2016-11-24 20:45 +0800
Message-ID<o16ne0$1td3$1@gioia.aioe.org>
In reply to#35954
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 :-(

When I see Applets as they could have been I ask "Why not?"


Either way Java continues to be the new Cobol. Good luck.


>
> Arne
>
>

[toc] | [prev] | [next] | [standalone]


#35960

FromJerry Stuckle <jstucklex@attglobal.net>
Date2016-11-24 09:12 -0500
Message-ID<o16sdf$95k$2@jstuckle.eternal-september.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 :-(
> 
> When I see Applets as they could have been I ask "Why not?"
> 
> 
> Either way Java continues to be the new Cobol. Good luck.
> 
> 
>>
>> Arne
>>
>>
> 

Java should be so lucky as to be the most popular programming language
in the world.  But it isn't even close to holding a candle to COBOL.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#35968

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-11-25 10:32 -0500
Message-ID<o19lhu$mk1$2@gioia.aioe.org>
In reply to#35960
On 11/24/2016 9:12 AM, Jerry Stuckle wrote:
> On 11/24/2016 7:45 AM, Richard Maher wrote:
>> Either way Java continues to be the new Cobol. Good luck.
>
> Java should be so lucky as to be the most popular programming language
> in the world.  But it isn't even close to holding a candle to COBOL.

Cobol was the most popular programming language like 20 years ago.

It is not in tier 1 today. It is not even in tier 2. It is a tier 3
language.

The world has moved on.

Arne


[toc] | [prev] | [next] | [standalone]


#35971

FromJerry Stuckle <jstucklex@attglobal.net>
Date2016-11-26 00:05 -0500
Message-ID<o1b53j$sfi$1@jstuckle.eternal-september.org>
In reply to#35968
On 11/25/2016 10:32 AM, Arne Vajhøj wrote:
> On 11/24/2016 9:12 AM, Jerry Stuckle wrote:
>> On 11/24/2016 7:45 AM, Richard Maher wrote:
>>> Either way Java continues to be the new Cobol. Good luck.
>>
>> Java should be so lucky as to be the most popular programming language
>> in the world.  But it isn't even close to holding a candle to COBOL.
> 
> Cobol was the most popular programming language like 20 years ago.
> 
> It is not in tier 1 today. It is not even in tier 2. It is a tier 3
> language.
> 
> The world has moved on.
> 
> Arne
> 
> 
> 

Sorry, you're wrong.  COBOL has an estimated 2 billion lines of new code
every year.  No, it's not popular on PCs,  But it's very popular in the
government and commercial fields, especially banks and insurance.

In the U.S., the Federal, every state, and every large county and city
uses COBOL on their mainframes.  As do every major bank and insurance
company and most (if not all) smaller ones.  And the same is true in
most developed countries around the world.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#35974

FromMartin Gregorie <martin@address-in-sig.invalid>
Date2016-11-26 15:24 +0000
Message-ID<o1c9en$3mr$1@dont-email.me>
In reply to#35971
On Sat, 26 Nov 2016 00:05:14 -0500, Jerry Stuckle wrote:

> Sorry, you're wrong.  COBOL has an estimated 2 billion lines of new code
> every year.  No, it's not popular on PCs,  But it's very popular in the
> government and commercial fields, especially banks and insurance.
> 
> In the U.S., the Federal, every state, and every large county and city
> uses COBOL on their mainframes.  As do every major bank and insurance
> company and most (if not all) smaller ones.  And the same is true in
> most developed countries around the world.
>
COBOL is also alive and in use on UNIX/Linux and Windows systems thanks 
to MicroFocus, who supply a system somewhat like the JVM: the compiler 
generates a form of byte code that runs in a portable runtime environment.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]


#35982

FromEric Douglas <e.d.programmer@gmail.com>
Date2016-11-28 05:08 -0800
Message-ID<f1606db1-06ee-452d-b520-02c99c09fbe7@googlegroups.com>
In reply to#35960
On Thursday, November 24, 2016 at 9:12:17 AM UTC-5, Jerry Stuckle wrote:
> 
> Java should be so lucky as to be the most popular programming language
> in the world.  But it isn't even close to holding a candle to COBOL.

COBOL was #1 when I finished college in 1996 and Java barely existed.  By 1999 I had a job with one of the largest retailers on the planet and they were working on converting mainframe programs to Unix servers running Oracle SQL back-end with PeopleSoft (Java based) front end.

[toc] | [prev] | [next] | [standalone]


#35984

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-11-28 19:51 -0500
Message-ID<o1ijdl$1gbm$1@gioia.aioe.org>
In reply to#35982
On 11/28/2016 8:08 AM, Eric Douglas wrote:
> On Thursday, November 24, 2016 at 9:12:17 AM UTC-5, Jerry Stuckle
> wrote:
>> Java should be so lucky as to be the most popular programming
>> language in the world.  But it isn't even close to holding a candle
>> to COBOL.
>
> COBOL was #1 when I finished college in 1996 and Java barely existed.
> By 1999 I had a job with one of the largest retailers on the planet
> and they were working on converting mainframe programs to Unix
> servers running Oracle SQL back-end with PeopleSoft (Java based)
> front end.

ERP/CRM is one of those areas where a lot of fully in house developed
COBOL systems has been replaced by (highly customized) socalled standard
systems.

SAP (ABAP and Java), Oracle (Java) and Microsoft Dynamics (X++ and C#).

Arne


[toc] | [prev] | [next] | [standalone]


#35985

FromJerry Stuckle <jstucklex@attglobal.net>
Date2016-11-28 21:18 -0500
Message-ID<o1iofk$gek$1@jstuckle.eternal-september.org>
In reply to#35982
On 11/28/2016 8:08 AM, Eric Douglas wrote:
> On Thursday, November 24, 2016 at 9:12:17 AM UTC-5, Jerry Stuckle wrote:
>>
>> Java should be so lucky as to be the most popular programming language
>> in the world.  But it isn't even close to holding a candle to COBOL.
> 
> COBOL was #1 when I finished college in 1996 and Java barely existed.  By 1999 I had a job with one of the largest retailers on the planet and they were working on converting mainframe programs to Unix servers running Oracle SQL back-end with PeopleSoft (Java based) front end.
> 

Yes, but retailers have completely different needs than governments,
banks and insurance companies.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#35989

Fromlewbloch@gmail.com
Date2016-11-29 13:50 -0800
Message-ID<c1308902-605c-47b8-908c-f6b2db493d7f@googlegroups.com>
In reply to#35985
On Monday, November 28, 2016 at 6:18:48 PM UTC-8, Jerry Stuckle wrote:
> On 11/28/2016 8:08 AM, Eric Douglas wrote:
> > On Thursday, November 24, 2016 at 9:12:17 AM UTC-5, Jerry Stuckle wrote:
> >>
> >> Java should be so lucky as to be the most popular programming language
> >> in the world.  But it isn't even close to holding a candle to COBOL.
> > 
> > COBOL was #1 when I finished college in 1996 and Java barely existed.  By 1999 I had a job with one of the largest retailers on the planet and they were working on converting mainframe programs to Unix servers running Oracle SQL back-end with PeopleSoft (Java based) front end.
> > 
> 
> Yes, but retailers have completely different needs than governments,
> banks and insurance companies.

And those differences affect the topic here exactly how?

-- 
Lew

[toc] | [prev] | [next] | [standalone]


#35990

FromJerry Stuckle <jstucklex@attglobal.net>
Date2016-11-29 16:53 -0500
Message-ID<o1kt9p$d01$1@jstuckle.eternal-september.org>
In reply to#35989
On 11/29/2016 4:50 PM, lewbloch@gmail.com wrote:
> On Monday, November 28, 2016 at 6:18:48 PM UTC-8, Jerry Stuckle wrote:
>> On 11/28/2016 8:08 AM, Eric Douglas wrote:
>>> On Thursday, November 24, 2016 at 9:12:17 AM UTC-5, Jerry Stuckle wrote:
>>>>
>>>> Java should be so lucky as to be the most popular programming language
>>>> in the world.  But it isn't even close to holding a candle to COBOL.
>>>
>>> COBOL was #1 when I finished college in 1996 and Java barely existed.  By 1999 I had a job with one of the largest retailers on the planet and they were working on converting mainframe programs to Unix servers running Oracle SQL back-end with PeopleSoft (Java based) front end.
>>>
>>
>> Yes, but retailers have completely different needs than governments,
>> banks and insurance companies.
> 
> And those differences affect the topic here exactly how?
> 

Governments and the like have a greater need for the capabilities of
COBOL than retailers.  Just because one retailer switched from COBOL to
a Java front end to PeopleSoft does not make a significant difference in
the usage of COBOL.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#36007

Fromlewbloch@gmail.com
Date2016-12-01 13:27 -0800
Message-ID<af4ba7ad-4ba6-4a2f-b6dc-c4ffa9d4a992@googlegroups.com>
In reply to#35990
On Tuesday, November 29, 2016 at 1:53:24 PM UTC-8, Jerry Stuckle wrote:
> On 11/29/2016 4:50 PM, lewbloch wrote:
> > On Monday, November 28, 2016 at 6:18:48 PM UTC-8, Jerry Stuckle wrote:
> >> On 11/28/2016 8:08 AM, Eric Douglas wrote:
> >>> On Thursday, November 24, 2016 at 9:12:17 AM UTC-5, Jerry Stuckle wrote:
> >>>>
> >>>> Java should be so lucky as to be the most popular programming language
> >>>> in the world.  But it isn't even close to holding a candle to COBOL.
> >>>
> >>> COBOL was #1 when I finished college in 1996 and Java barely existed.  By 1999 I had a job with one of the largest retailers on the planet and they were working on converting mainframe programs to Unix servers running Oracle SQL back-end with PeopleSoft (Java based) front end.
> >>>
> >>
> >> Yes, but retailers have completely different needs than governments,
> >> banks and insurance companies.
> > 
> > And those differences affect the topic here exactly how?
> > 
> 
> Governments and the like have a greater need for the capabilities of
> COBOL than retailers.  Just because one retailer switched from COBOL to
> a Java front end to PeopleSoft does not make a significant difference in
> the usage of COBOL.

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

[toc] | [prev] | [next] | [standalone]


#36009

FromJerry Stuckle <jstucklex@attglobal.net>
Date2016-12-01 16:45 -0500
Message-ID<o1q5i3$ad6$1@jstuckle.eternal-september.org>
In reply to#36007
On 12/1/2016 4:27 PM, lewbloch@gmail.com wrote:
> On Tuesday, November 29, 2016 at 1:53:24 PM UTC-8, Jerry Stuckle wrote:
>> On 11/29/2016 4:50 PM, lewbloch wrote:
>>> On Monday, November 28, 2016 at 6:18:48 PM UTC-8, Jerry Stuckle wrote:
>>>> On 11/28/2016 8:08 AM, Eric Douglas wrote:
>>>>> On Thursday, November 24, 2016 at 9:12:17 AM UTC-5, Jerry Stuckle wrote:
>>>>>>
>>>>>> Java should be so lucky as to be the most popular programming language
>>>>>> in the world.  But it isn't even close to holding a candle to COBOL.
>>>>>
>>>>> COBOL was #1 when I finished college in 1996 and Java barely existed.  By 1999 I had a job with one of the largest retailers on the planet and they were working on converting mainframe programs to Unix servers running Oracle SQL back-end with PeopleSoft (Java based) front end.
>>>>>
>>>>
>>>> Yes, but retailers have completely different needs than governments,
>>>> banks and insurance companies.
>>>
>>> And those differences affect the topic here exactly how?
>>>
>>
>> Governments and the like have a greater need for the capabilities of
>> COBOL than retailers.  Just because one retailer switched from COBOL to
>> a Java front end to PeopleSoft does not make a significant difference in
>> the usage of COBOL.
> 
> 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.
> 

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.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#36012

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-12-01 22:07 -0500
Message-ID<o1qogr$jvg$1@gioia.aioe.org>
In reply to#36009
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.

Arne


[toc] | [prev] | [next] | [standalone]


#36017

FromJerry Stuckle <jstucklex@attglobal.net>
Date2016-12-02 10:35 -0500
Message-ID<o1s49a$fc6$1@jstuckle.eternal-september.org>
In reply to#36012
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.
> 
> Arne
> 
> 
> 

But is it compatible with the DECIMAL data type on databases?  Can you
*efficiently* read and write DECIMAL types to DB2, for instance?

And exactly how does Java interface efficiently with databases like DB2?
 Java only has the equivalent of dynamic SQL, where every SQL statement
must be interpreted by the database.  Additionally, the connection to
the database is relatively slow.

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.

And don't try to claim performance isn't important any more.  It may not
be on YOUR system - but to people running large mainframes, it is still
quite important.  They have millions of dollars invested in the
hardware, and want every bit of performance they can get out of their
investment.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#36021

FromGene Wirchenko <genew@telus.net>
Date2016-12-02 08:53 -0800
Message-ID<ph934ctn8bf70shvqb7csfk8vue4lho2hf@4ax.com>
In reply to#36017
On Fri, 2 Dec 2016 10:35:36 -0500, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

[snip]

>But is it compatible with the DECIMAL data type on databases?  Can you
>*efficiently* read and write DECIMAL types to DB2, for instance?
>
>And exactly how does Java interface efficiently with databases like DB2?
> Java only has the equivalent of dynamic SQL, where every SQL statement
>must be interpreted by the database.  Additionally, the connection to
>the database is relatively slow.
>
>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.

     If the situation changes (whatever this means) after the
compilation, the access plan could then be out of date.  How would one
ever find out?  I am curious about this aspect and how its
disadvantages are mitigated.

>And don't try to claim performance isn't important any more.  It may not
>be on YOUR system - but to people running large mainframes, it is still
>quite important.  They have millions of dollars invested in the
>hardware, and want every bit of performance they can get out of their
>investment.

     Quite.  How do they do it?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]


#36025

FromJerry Stuckle <jstucklex@attglobal.net>
Date2016-12-02 15:05 -0500
Message-ID<o1sk3b$db5$1@jstuckle.eternal-september.org>
In reply to#36021
On 12/2/2016 11:53 AM, Gene Wirchenko wrote:
> On Fri, 2 Dec 2016 10:35:36 -0500, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
> [snip]
> 
>> But is it compatible with the DECIMAL data type on databases?  Can you
>> *efficiently* read and write DECIMAL types to DB2, for instance?
>>
>> And exactly how does Java interface efficiently with databases like DB2?
>> Java only has the equivalent of dynamic SQL, where every SQL statement
>> must be interpreted by the database.  Additionally, the connection to
>> the database is relatively slow.
>>
>> 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.
> 
>      If the situation changes (whatever this means) after the
> compilation, the access plan could then be out of date.  How would one
> ever find out?  I am curious about this aspect and how its
> disadvantages are mitigated.
>

RUNSTATS updates the current statistics on the database, and REBIND
rebinds all applications, creating new access plans for each.

>> And don't try to claim performance isn't important any more.  It may not
>> be on YOUR system - but to people running large mainframes, it is still
>> quite important.  They have millions of dollars invested in the
>> hardware, and want every bit of performance they can get out of their
>> investment.
> 
>      Quite.  How do they do it?
> 
> Sincerely,
> 
> Gene Wirchenko
> 

By using compiled languages and efficient database connections.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer


csiph-web