₦airaland Forum

OK. I'll give you just 1 blind tip (as I am really groping in the dark here):

Make sure all the required libraries (jar files) are in the class-path (on Windows, check that the environment variable %CLASSPATH% includes all the jar files delimited by semi-colon). One of such is definitely the MySQL JDBC driver. I don't know the rest.

Guy, you said you think the issue is as a result of the application not communicating with the database when deployed as a JAR. Now, my question to you is, don't you think if this is the issue, that an exception would have been thrown? Yet you said there are no exceptions/errors. What does that tell you? Assuming you handled exceptions well, then it means the issue is not because the application cannot communicate with the database.

QED.

Beaf:
If it does'nt add to il how can it even begin to affect compiler performance. It says it there as clear as day.

In Java, the compilation using the tacit import directive as opposed to the verbose version has a potential impact on compilation performance (which is mostly unnoticeable anyway, as packages usually contain just a few hundred classes at the most). Yet, the referenced classes ARE NOT ADDED to the dependent classes. I expect the same with C#.

This guy. How does what you quoted imply that compilation using a tacit "uses" directive does not result in longer compilation times? You don't seem to know what performance measure is of concern during compilation. Nobody is saying using a tacit "uses" directive will result in a bloated application (such as was the issue with the "include" directive in C/C++ which literally, well, includes all required classes). In Java, that issue was resolved as imported classes do not bloat the application size, and are referenced on an "as-needed" basis.

Beaf:
That didn't take any time, See http://msdn.microsoft.com/en-us/library/aa664764(VS.71).aspx

I don't see anywhere in that document that the tacit "using" directive has no impact on compilation performance compared to the "verbose" directive. You can do your benchmark by creating a package with a million dummy classes and trying both. Get back to us with the results. Good luck.

Sorry, that was not supposed to be "JVM", but the compiler (javac for instance), as both sources will compile into the same byte-code.

Beaf:
You can nest namespaces, but not packages. Namespaces are not limited to a single source file, you can have as many as you want. namespaces do not dictate app file structure, rather they are logical groupings only.

I don't quite get this. You mean packages cannot be nested? You mean a package is limited to a single source file? You mean packages are not logical groupings? This namespace thing you are touting is not much of a big deal. It's really a similar concept to the package concept and it's even used in some Java frameworks (such as Struts2 configuration files). How is it such a big deal?

And you know this because you have tested it? You have a tendency of making blanket statements with nothing to back you up. To me, you are just a C# fan-boy and nothing more.

The impact on performance we are talking about is on the actual compilation. This is trivial in most cases but non-trivial as the number of classes and packages increase, and as each package contains a huge number of classes (say in the region of millions - which really is stretching it as I have never seen such a package, and having millions of classes in a package may indicate a poor design strategy).

If you think the reason the form is not showing is because the application is not communicating with the database, don't you also think an exception would have been thrown? How did you handle exceptions in your application?

I think a demonstration of terse versus verbose using a code snippet is required here, for those who don't realize the idea behind verbosity in Java:

Snippet 1
import java.util.*;

Snippet 2
import java.util.Date;
import java.util.List;
import java.util.ArrayList;
import java.util.Vector;
import java.util.HashMap;

Snippet 1 is the tacit version of Snippet 2. But guess what? Snippet 2 results in a better performance by the compiler in resolution of dependencies, which is why IDEs generally generate code like Snippet 2 and not Snippet 1. With Snippet 1, the compiler basically pre-loads all the classes in the package, while Snippet 2 tells it which classes to load, hence the efficiency.

The other advantage of Snippet 2 is, it presents the class dependencies to anybody reading the code at a single glance. Snippet 1 merely tells you that certain classes will be loaded from the package "java.util", but no more. You do not know the actual classes until you start looking through the code. So Snippet 2 is more readable.

The fact is, Java could have been designed such that you do not need import statements, making the compiler/translator do the work of figuring out which classes to load. That will be a higher degree of terseness. But this results in inefficient compilation/linkage.

You need to understand the reason behind verbosity/terseness, and not just think they are fancy terms to be bandied around.

Beaf:
Haha.
Nobody even knew about this until last year http://slightlyrandombrokenthoughts..com/2008/12/calendar-bug.html
That was from an unsigned applet. Signed applets are just as dangerous as activex (maybe even more so, since they have the power of standalone programs. . . in your browser! ).

Yes, signed applets CAN be as dangerous as ActiveX, but the signature is about trust. If you do not trust the author of the applet, you have the option of not allowing the applet to load. I don't know how ActiveX security is being handled now, but back then it was a nightmare as there was no comparable security model to the signature/sandbox model used by applets.

So of what use is having terseness as an option in a language when the rule-of-thumb suggests a moderately verbose approach?

Beaf, you seem to think the size of instructions required to write code is related to verbosity. When we talk about verbosity/terseness, we are referring to High Level Languages. Nobody will ever refer to Assembly Language as "verbose". Assembly code is lengthier simply because of its limited grammar and primitive constructs.

A good example of "terse" versus "verbose" was 5 lines of code in Python which somebody claimed would require 100 lines in Java. Unfortunately, I couldn't make sense of the code. It was that complex. And in my opinion, it would have been coded in Java quicker (or in any other more verbose form) because I know to have come up with that code, the programmer would have spent thousands of hours honing and adjusting the code, and not to add at least 20 years of experience to have a clear understanding of the terse code he was writing.

Kobojunkie, with regards to this: "you notice code is less MANAGEABLE, increase in testing time, as well as resource consumption, and in some cases less readable code". Once a piece of code is all what you mentioned in the quote, I doubt it is verbose. Verbose code for one is definitely much more readable than terse code.

Beaf:
Its is more complicated than that. Both java applets and activex were a conduit for security problems, so they fell out of favour.

See, the problem is you don't know enough about Java. Applets were considered safe because of the sandbox model, but fell out of favor because they were what you would consider fat clients (and of course with all the attendant draw-backs). ActiveX clients were usually avoided like the plague back in the day because of the security concerns, but not applets.

Are you sure you know what you are talking about? Verbosity actually leads to less bugs. A terse language is more likely to incur bugs than a verbose one. Reason being the terseness leads to complexity of expressions and therefore confuse developers.

Kobojunkie:
I agree with that being a weakness for Java. Ever notices how there are so many Java based frameworks out there?  Most of them are designed to help SIMPLY that particular Java coding problem.

Wow! I've heard it all. Verbosity leads to a proliferation of frameworks?

Beaf:
What exaggeration? Last century ended in 1999.

Anybody who knows enough about the development of Java as a language will tell you that Java was actually considered even stronger on the client-side (applets) than on the server-side circa 1999. At the moment, the client-side is almost done with, and it has matured into a solid server-side development language.

Beaf:
Last century, that was true. These days, .NET rules.

Apparently, you don't know what a century is, or you are one of those whose MO is unnecessary exaggerations. Either way, it's not worth it joining issues with you.

Why don't you google "asynchronous messaging"? I'll give you a hint and mention WebSphere MQ (formerly MQ Series).

In any case, how well does PHP scale? If you don't know what I mean by scaling, you can google that too.

candylips:
guy you need to explain yourself better

LOL, the guy dey under stress naw! He no wan lose him job.

Pogo Plank - replaces the SpringBoard functionality with a "roulette wheel".

candylips:
you shouldn't be using java for windows GUI it sucks at it

Actually I have seen some very nice desktop applications developed in Java (such as Limewire - but you can bet they are not using the standard AWT/Swing APIs, but some custom APIs), but yeah (like any experienced Java developer should know), the power of Java doesn't lie in desktop apps.

And what platform are you interested in? Or are you open to any?

I think this is one of those situations when you won't be reinventing the wheel by writing your own (especially since you know exactly what you need). That's what I would do anyway.

Who's "high" here?

@candylips

The phrase you are looking for is "quick-and-dirty".

Wrong. It is not about ego as I wouldn't even have this conversation in the first place if it was. And it is not about MY code, but more about MY design (architecture).

I was hoping you'd put your knowledge where your keyboard+mouse+finger is, but it's whatever. I am a very practical person, and trust me when I say I'd rather prove points practically than exchange posts all day. Ciao.

How about you mention a few. Then we will proceed by actually coming up with real problems and then you code the solution, while I use an MVC based framework. We then compare my solution to yours?

#4: U can access the serial port using Java; and you can access Java through Javascript. With Javascript in your page, you can figure the rest out.

@Kobojunkie

Your post made the assumption that all developers only aspire to be framework users, and will likely not develop frameworks themselves. But even then, while developing simple systems (framework or no framework), I don't see why you shouldn't aspire to code as cleanly, elegantly and efficiently as possible (which is why we use patterns in the first place).

You don't seem to understand. I am more interested in developing a framework like Struts for others to use, than simply be a user of frameworks. Meaning I have to have a firm understanding of design patterns. That was the point I was making. Any developer that does not want to limit himself to merely being a framework user will definitely get well acquainted with patterns.

Well, guy, I hope you are aware there are several "layers" of Software Development. You should be aware that it's people who developed such frameworks as Struts, meaning they had to implement the MVC pattern on which Struts is based. Not all developers are only focused on using frameworks; some actually build them. *light-bulb*