Restoring Swing applications after minimising

[Lew]

Lew: Is there even really an issue?

That is not an assertion, but a question.

Lew: Studies have shown that people will often report a program
Lew: as being faster at, say, initial startup even if it's actually
Lew: slower compared to a control. Factors such as a splash screen
Lew : can reduce the perceived time even when the clock time is
longer.

That is not an assertion but a suggestion of alternative explanations, ones
which may well pertain and will have to be considered in order to explain and
possibly correct the situation.

Why do I have the feeling that most of your posts are bordeline
trollish and that you use many little dirty intellectual tricks
to drag the discussion exactly where you want to?

Perhaps because you are misinterpreting my posts.

Are you saying that it is incorrect to consider that the problem might be
caused by something other than Swing?

 

[Lew]

Lew is actually using a lot of logical fallacies in various
of his posts and a lot of ad nominem attacks.

Plonk.

 

[Jarrick Chagma]

[...]

P.S: I qualify writing "Did you try to read ..." instead of "Did you
read"
as a dirty little intellectual trick. The JLS-nazi bot has become
a master in manipulating such dirty little intellectual tricks.

P.P.S.: Don't bother reading the JLS-nazi bot's answers on anything
that
cannot be answered by a direct JLS quote.

While Lew can be a little abrasive at times and certainly loves a good
argument, I think he means well and he is clearly very knowledgeable. I
don't find him offensive at all (re "take umbrage") and would rather someone
genuinely challenged my claims than said nothing if they believed them to be
questionable. I appreciate it when anyone takes the time to reply to my
posts so I have no issue with Lew or anyone else for that matter.

 

[Seamus MacRae]

Lew is actually using a lot of logical fallacies in various
of his posts and a lot of ad nominem attacks.

Actually, he has posted a lot of ad hominem attacks. Ad nominem attacks
would be arguments against the name, if anything, not arguments against
the man.

Actually a bot that would take first post and do a search
in the JLS on a few terms and quote the JLS in condescending
terms like:

"You should try to read J.L.S. x.y.z."

could probably be easily programmed and it would sound
very much like Lew's response.

The bot would fail to unpredictably fly off the handle and start foaming
at the mouth, which Lew has been observed to do on several occasions,
including once, a while back, when someone posted as "Saint Nick", and
most recently in the large Lisp thread.

 

[Arne Vajhøj]

Lew is actually using a lot of logical fallacies in various
of his posts and a lot of ad nominem attacks.

No. You seem to be doing that.

Don't forget that it will also nitpick on english spelling
and grammar mistakes (which is laughable in a newsgroup
where non-native english speakers --like myself-- participate).

That can be a bit irritating.

But do you know what: COMMENT ON IT IN THE THREADS WHERE IT HAPPEN
NOT HERE !

Actually a bot that would take first post and do a search
in the JLS on a few terms and quote the JLS in condescending
terms like:

"You should try to read J.L.S. x.y.z."

could probably be easily programmed and it would sound
very much like Lew's response.

Java is the holy grail and the JLS is the gospel.

There is not anything wrong in referring to the JLS
in a Java programming language - it is the authoritative
guide to how Java works.

Everything in Java was done right, and there are no
issues at all.

I can not remember Lew ever stating that.

He is like many other skeptical when someone
comes and say that adding XYZ to Java would be
great, that it should have been added a long time
ago etc.etc..

Not to mention he's never been involved in a project
involving client side Swing code deployed on various
architectures nor in server-side code involving an OO DB.

Use of OODBMS's are extremely rare.

And >95% of Java GUI's are web GUI's.

So that is something Lew share with a lot of people here.

Arne

 

[Lew]

Use of OODBMS's are extremely rare.

For good reason.

And >95% of Java GUI's are web GUI's.

So that is something Lew share with a lot of people here.

Actually, poster "charlesbos73" is mistaken. I have worked on Swing for
multiple architectures, i.e., *IX and Windows. As for that being client-side,
part of that work involved a Swing client for EJBs on the back end.

As for working on server code involving an "OO DB", he's mistaken twice over.
I worked on so-called "OO DB"s back when they were known by their proper
name as "network-model" database systems. I've also done quite a bit of ORM
(object-to-relational mapping) work, using "OO" with a "DB", actually a far
more powerful paradigm.

I have evaluated "OO DB"s, and like other respondents in this forum I've found
that they do nothing to enhance the object orientation of the Java code, and
I've also assessed that they do diminish the power of the data layer.

 

[Arne Vajhøj]

For good reason.


Actually, poster "charlesbos73" is mistaken. I have worked on Swing for
multiple architectures, i.e., *IX and Windows. As for that being
client-side, part of that work involved a Swing client for EJBs on the
back end.

SO he is also mistaken about that part.

As for working on server code involving an "OO DB", he's mistaken twice
over. I worked on so-called "OO DB"s back when they were known by their
proper name as "network-model" database systems.

I don't think CODASYL databases and OODBMS's are quite the same.

Arne

 

[Lew]

I don't think CODASYL databases and OODBMS's are quite the same.

I don't know about CODASYL specifically, but I get your point. There are
significant similarities at the data layer between network databases, and I've
worked with several other than CODASYL, in particular both allocate relations
as part of the data layer. They obtain significant query speed and modeling
strength in the case where the object model always maps to the data model
including the relationships. They lack somewhat in flexibility, having
trouble expressing novel relations without coupled changes to the object model
and vice versa. The relational model gains in flexibility and the "cheat" of
indexes offsets most if not all the performance disadvantage for well-known
relationships.

OODBMSs seek to leverage the strength of direct object model expression in the
data layer. There is strength, IMO to the degree that they give the
developers an object view into the data. This in turn helps move the logic
programmer away from a data-centric programming mindset and toward better
modeling. Good things.

Object-relational mapping frameworks, ORMs, are the attempt to put camel's
feet on a bicycle so you can ride in the desert. Ahem, so to speak.

It turns out that you don't even need a data layer to think about your program
in terms of an object model. You could just formulate a good object model and
cast it in terms of Entity instances and operations thereupon. From that
point of view you simply wave a magic wand and your information lasts forever.

It also turns out that for the greater part of workaday projects, you can do a
naive translation of entities to tables and get a good data model match, even
with a relational database. Just ignoring relations in the code for a
minute, mind you. But early on, you do get a sense of foreign key relations
and you model some simple parent-to-child relationships and many-to-many
liaisons with a straightforward matching of foreign keys to Java collections.

Now here's the beautiful part: both OODBMSes and JPA apps on top of regular
ol' SQL table-based ones turn the programmer loose in that world of object
modeling only, and both hide all the messy data-level crud from application
development. With just a sensible understanding of simple normalization and
foreign key references, you can do what little tweaking of the data model you
really need, which isn't usually much coming from either JPA or an OODBMS.

At that point, the assessment of the two approaches has to diverge. I
conclude that the JPA+RDBMS combination is the best of both worlds - domain
logic from the object model perspective and data from the data perspective.

 

[Martin Gregorie]

I don't know about CODASYL specifically, but I get your point. There
are significant similarities at the data layer between network
databases, and I've worked with several other than CODASYL, in
particular both allocate relations as part of the data layer. They
obtain significant query speed and modeling strength in the case where
the object model always maps to the data model including the
relationships. They lack somewhat in flexibility, having trouble
expressing novel relations without coupled changes to the object model
and vice versa. The relational model gains in flexibility and the
"cheat" of indexes offsets most if not all the performance disadvantage
for well-known relationships.

This is not a huge disadvantage for a large project using some form of
waterfall development, though it can cause problems with extreme
programming and other prototyping approaches.

OTOH, by forcing to programmers and module designers to consider the
relationships defined and optimised in the DB schema a network database
does avoid one bugbear of using an RDBMS in a large project - performance
issues due to programmers writing SQL that defines relationships which
nobody told the DBAs about. Merely finding these relationships in order
to do something about the performance can be a problem. As an affected
DBA I've ended up turning on ODBC debugging during regression testing in
order to capture the SQL and to get a handle on relationship usage
frequency. This info is often omitted from both the design and the module
docs because SQL is "only code". That bit me with non-Java development,
but exactly the same problem could easily occur in a Java/JDBC project.

I have been DBA for equally complex greenfield CODASYL and RDBMS projects
and have also solved RDBMS performance problems in other people's designs.
I've found that a major cause of this type of problem is that any schema/
SQL mismatch will show apparently good performance with typical program
and integration test data volumes but slow down drastically once the main
tables contain several thousand rows. Unfortunately, the designers and
devs have often moved on by then, so they never have the chance to learn
from the problems they've caused.