A couple of months ago, I implemented icons.bni reading. It was hundreds of times easier than I thought it would be to implement, and now I'm disgusted by bots that don't do it.

http://bnubot.googlecode.com/svn/trunk/BNUBot/src/net/bnubot/bot/gui/icons/IconsDotBniReader.java

http://www.x86labs.org/forum/index.php/topic,9269.0.html
I got lazy and never finished support for other tga formats.
But ya, it's easy.
~Hdx

I like my code better because it isn't rittled with warnings. :)

Other than that, it looks like your solution is very similar to mine, from a glance.

Warnings? My code compiles on 1.6.0 without any warnings. I haven't bothered to try it on any other vers because I was lazy when I wrote it.
But ya, there basically the same.
~Hdx

For starters, ArrayLists should be parametarized.

[code]ArrayList x = new ArrayList();[/code]

Will cause a warning, at least in Java 1.5.

[code]ArrayList<Object> x = new ArrayList<Object>();[/code]

Don't even get me started on the warnings in JBLS. :P

[quote]C:\Documents and Settings\Hdx\Desktop\Crap\Coding\JBLS>..\jdk1.6.0\bin\javac -cp .;./JBLS .\JBLS\Main.java .\JBLS\util\*.java .\JBLS\BNLSProtocol\*.java .\JBLS\Hashing\*.java .\JBLS\HTTP\*.java
C:\Documents and Settings\Hdx\Desktop\Crap\Coding\JBLS>[/quote]
No warnings in JBLS, I pride myself on that, so yes, get started.

You're code has warnings as well, you just suppress them (from first glance):
[code]@SuppressWarnings("serial")[/code]
~Hdx

Serial warnings are the only ones I suppress except for maybe one or two cases where I felt justified for some reason there as well, and I do that instead of specifying a serial id because those classes will never, ever be serialized.

There are 17 warnings in my workspace, all of them come from JBLS. There used to be more - 23 to be exact - but a few of them were simply poor Java style, so I fixed them. Perhaps you just have your warnings turned down below the defaults.

I don't want to bash your code, but there are a number of things that I would consider to be wrong with it. For example, you don't have your own unique package root. What will you do if you need to link in another tool that has a fully qualified class name collision with yours? Not likely, since JBLS is the only project I've ever seen that does this, but still, you should refactor everything to org.jbls. In the interest of keeping the thread civil, I'll stop here. :D

[edit] I'm using Java 5, not 6

Just compiled both projects against Java 6, same 17 warnings.

naw this is what the forum is here for.
if your main complaint is my coding habits, then just skip over it.
I'm pretty sure I don't have the warnings disabled by default as if I deliberately do something that would issue a warning (hashtables for example) it does so.

As for the namespace. to be honest.. I don't really like it. JBLS was built to be stand alone. not use in other projects. I actually have a core package (Hdx.IRC.*, Hdx.BNCS.*. Hdx.utils.*, etc.. etc.. depends on what I am making)
I have seen many projects that do not use a root package. Never seen a collision.
I don't make things that the stupid should use :P (they can, and many do, but still)

I'll find a java 4/5 workspace somewhere to test with (mind uploading the JSDK5 as a .zip for me? c:\program files\java\jsdk1.5.0_11\). But just for a note, JBLS has been built against 1.6.0_01 since 2.8.
Hehe, anyways, take advantage of the situation, I'm in a really good mood, My best friend is coming back into town for a few days!

Camel., quote me the warnings, because the screen shot is annoyingly small. Anyways, you're using an outdated version of JBLS, JBLS\Admin no linger exists.

Thats the problem with using things I make in your projects. I'm ever changing them. Especially JBLS
~Hdx

[edit] Just built 3.1 against 4.2, 5 and 6. No errors/warnings.
~Hdx

Create a Google Code project, and host your code there.  Or, at least, get your CVS server back up, or publish its address if it is up.

I can't give you a Windows JVM because I'm using Linux. You don't need an old JVM anyways, just compile your code in compatibility mode for the release you want.

While you're at it, just go download Eclipse. I don't care what you're using; I've seen them all. Eclipse wins, period. Sure, it's an opinion, but it's the correct opinion to have. :D

[code]Severity and Description Path Resource Location Creation Time Id
The field InPacketBuffer.pLength is never read locally JBLS/BNLSProtocol InPacketBuffer.java line 27 1187671672227 4006
The local variable bannerExt is never read JBLS/util BNFTP.java line 66 1187671670804 4000
The local variable bannerID is never read JBLS/util BNFTP.java line 65 1187671670803 3999
The local variable contents is never read JBLS/Admin AdminList.java line 19 1187671673060 4013
The local variable contents is never read JBLS/BNLSProtocol BNLSlist.java line 23 1187671672273 4007
The local variable padNumber is never read JBLS/Hashing BrokenSHA1.java line 52 1187671671976 4003
The local variable ret is never read JBLS/Hashing BrokenSHA1.java line 23 1187671671976 4002
The local variable sName is never read JBLS/util BNFTP.java line 68 1187671670804 4001
The local variable verHash is never read JBLS/Admin AdminParse.java line 159 1187671673027 4010
The method GetPath(String) from the type AdminParse is never used locally JBLS/Admin AdminParse.java line 281 1187671673028 4012
The method hex(int) from the type HTTPParse is never used locally JBLS/HTTP HTTPParse.java line 363 1187671672190 4005
The method sendHashFile(String, String[]) from the type HTTPParse is never used locally JBLS/HTTP HTTPParse.java line 284 1187671672189 4004
The static method Broadcast(String, String) from the type BNLSServer should be accessed in a static way JBLS/Admin AdminParse.java line 136 1187671673026 4008
The static method destroyAllConnections() from the type BNLSServer should be accessed in a static way JBLS/Admin AdminParse.java line 140 1187671673027 4009
The static method destroyAllConnections() from the type BNLSServer should be accessed in a static way JBLS/Admin AdminParse.java line 268 1187671673028 4011
The static method destroyAllConnections() from the type BNLSServer should be accessed in a static way JBLS/util Controller.java line 33 1187671670581 3997
This method has a constructor name JBLS/util BNFTP.java line 15 1187671670802 3998[/code]

ssh -> vim ftw
I compile in compatibility mode, But i'm still not getting any of these warnings you speak of. (I looked at each of those lines in your SS, they were either completely gone or changed)
And I don't like using a CVS, mainly because i'm the only one working on it. And i use my jump drive for it so I never need a CVS. :P

I've tried all the JVMs 4.2-6 on both windows and linux. So I have to go with: you're using a way old version of JBLS, before I gave a shit how it compiled as long as it worked.

Also, breaking tables + double posting is EWWWWWWWWWWWWWWWWW
So, fix the table breakin, update to JBLS 3.0 and try again.
~Hdx

I don't see any broken tables. Maybe your browser sucks?

Where are you hosting JBLS? I don't see any links on your website to download it like there used to be.

Yes.. Firefox does suck.....
Actually I'm using the dark blue theam of the forum which does not automatically wrap long code boxes.
It's a theam problem not a browser problem.  But this is the only theam I like, so it's staying.
http://jbls.org/downloads/JBLS.jar
same place it's always been.
~Hdx

Increase your screen resolution. :D

Just imported your new code. Now there are 88 warnings.

Seriously, I would strongly suggest using Eclipse.

[code]Severity and Description Path Resource Location Creation Time Id
The field BNLSParse.BNLS_RESERVED0 is never read locally JBLS/BNLSProtocol BNLSParse.java line 71 1187675579565 4155
The field BNLSParse.BNLS_RESERVED1 is never read locally JBLS/BNLSProtocol BNLSParse.java line 72 1187675579565 4156
The field BNLSParse.BNLS_RESERVED2 is never read locally JBLS/BNLSProtocol BNLSParse.java line 73 1187675579565 4157
The field BNLSParse.BNLS_RESERVED3 is never read locally JBLS/BNLSProtocol BNLSParse.java line 75 1187675579566 4158
The field BNLSParse.BNLSUsername is never read locally JBLS/BNLSProtocol BNLSParse.java line 34 1187675579564 4154
The field BNLSParse.PRODUCT_BROODWAR is never read locally JBLS/BNLSProtocol BNLSParse.java line 80 1187675579566 4160
The field BNLSParse.PRODUCT_DIABLO is never read locally JBLS/BNLSProtocol BNLSParse.java line 87 1187675579569 4167
The field BNLSParse.PRODUCT_DIABLO2 is never read locally JBLS/BNLSProtocol BNLSParse.java line 82 1187675579567 4162
The field BNLSParse.PRODUCT_DIABLOSHAREWARE is never read locally JBLS/BNLSProtocol BNLSParse.java line 88 1187675579569 4168
The field BNLSParse.PRODUCT_JAPANSTARCRAFT is never read locally JBLS/BNLSProtocol BNLSParse.java line 84 1187675579568 4164
The field BNLSParse.PRODUCT_LORDOFDESTRUCTION is never read locally JBLS/BNLSProtocol BNLSParse.java line 83 1187675579567 4163
The field BNLSParse.PRODUCT_STARCRAFT is never read locally JBLS/BNLSProtocol BNLSParse.java line 79 1187675579566 4159
The field BNLSParse.PRODUCT_STARCRAFTSHAREWARE is never read locally JBLS/BNLSProtocol BNLSParse.java line 89 1187675579569 4169
The field BNLSParse.PRODUCT_THEFROZENTHRONE is never read locally JBLS/BNLSProtocol BNLSParse.java line 86 1187675579568 4166
The field BNLSParse.PRODUCT_WAR2BNE is never read locally JBLS/BNLSProtocol BNLSParse.java line 81 1187675579567 4161
The field BNLSParse.PRODUCT_WARCRAFT3 is never read locally JBLS/BNLSProtocol BNLSParse.java line 85 1187675579568 4165
The field BotNet.PACKET_BROADCASTMESSAGE is never read locally JBLS/util BotNet.java line 29 1187675581299 4214
The field BotNet.PACKET_CHATDROPOPTIONS is never read locally JBLS/util BotNet.java line 35 1187675581300 4215
The field BotNet.PACKET_CYCLE is never read locally JBLS/util BotNet.java line 26 1187675581299 4213
The field BotNet.PACKET_DATABASE is never read locally JBLS/util BotNet.java line 24 1187675581298 4211
The field BotNet.PACKET_MESSAGE is never read locally JBLS/util BotNet.java line 25 1187675581299 4212
The field BotNet.password is never read locally JBLS/util BotNet.java line 40 1187675581300 4216
The field InPacketBuffer.pLength is never read locally JBLS/BNLSProtocol InPacketBuffer.java line 23 1187675579636 4175
The import BNLSProtocol.BNLSlist is never used JBLS Main.java line 46 1187675581081 4206
The import Hashing is never used JBLS/Hashing CheckRevisionV3.java line 7 1187675580656 4184
The import Hashing.SRP is never used JBLS Main.java line 38 1187675581080 4204
The import java.io is never used JBLS/BNLSProtocol BNLSlist.java line 4 1187675579625 4172
The import java.io is never used JBLS/util cSettings.java line 3 1187675582102 4237
The import java.io is never used JBLS/util/PEFiles ImportAddressManager.java line 2 1187675581914 4232
The import java.io.File is never used JBLS/Hashing HashMain.java line 2 1187675580778 4200
The import java.io.IOException is never used JBLS/BNLSProtocol BNLSParse.java line 17 1187675579564 4153
The import java.lang is never used JBLS/HTTP HTTPParse.java line 4 1187675579858 4176
The import java.lang is never used JBLS/HTTP HTTPSendFile.java line 3 1187675579880 4179
The import java.lang.Integer is never used JBLS/BNLSProtocol BNLSlist.java line 5 1187675579626 4173
The import java.lang.NullPointerException is never used JBLS/BNLSProtocol BNLSServer.java line 14 1187675579601 4170
The import java.net is never used JBLS/HTTP HTTPSendFile.java line 4 1187675579881 4180
The import java.util is never used JBLS/HTTP HTTPSendFile.java line 5 1187675579881 4181
The import java.util.Calendar is never used JBLS/Hashing HashMain.java line 5 1187675580778 4201
The import java.util.Date is never used JBLS/Hashing HashMain.java line 6 1187675580779 4202
The import java.util.Date is never used JBLS/util Out.java line 16 1187675581561 4231
The import java.util.NoSuchElementException is never used JBLS/util cSettings.java line 7 1187675582103 4240
The import java.util.StringTokenizer is never used JBLS/BNLSProtocol BNLSlist.java line 6 1187675579626 4174
The import java.util.StringTokenizer is never used JBLS/util cSettings.java line 5 1187675582103 4239
The import util.BigIntegerEx is never used JBLS Main.java line 39 1187675581081 4205
The import util.Buffer is never used JBLS/util/PEFiles PEFile.java line 3 1187675581978 4236
The import util.Out is never used JBLS/BNLSProtocol BNLSlist.java line 3 1187675579625 4171
The import util.Out is never used JBLS/util cSettings.java line 4 1187675582102 4238
The local variable action is never read JBLS/util BotNet.java line 183 1187675581302 4221
The local variable bannerExt is never read JBLS/util BNFTP.java line 85 1187675581139 4209
The local variable bannerID is never read JBLS/util BNFTP.java line 84 1187675581138 4208
The local variable buff is never read JBLS/Hashing lockdown_SHA1.java line 65 1187675581013 4203
The local variable database is never read JBLS/util BotNet.java line 141 1187675581301 4218
The local variable DataDirectory_Imports is never read JBLS/Hashing CheckRevisionV3.java line 155 1187675580657 4185
The local variable DataDirectory_Reloc is never read JBLS/Hashing CheckRevisionV3.java line 155 1187675580657 4186
The local variable dir1 is never read JBLS/Hashing CheckRevisionV3.java line 155 1187675580657 4187
The local variable dir2 is never read JBLS/Hashing CheckRevisionV3.java line 155 1187675580658 4188
The local variable edx is never read JBLS/Hashing CheckRevisionV3.java line 156 1187675580658 4189
The local variable extra is never read JBLS/util BotNet.java line 167 1187675581301 4220
The local variable fndHdr is never read JBLS/util Ini.java line 83 1187675581510 4230
The local variable goodLen is never read JBLS/util BotNet.java line 166 1187675581301 4219
The local variable lower_offset is never read JBLS/Hashing CheckRevisionV3.java line 281 1187675580660 4194
The local variable padNumber is never read JBLS/Hashing BrokenSHA1.java line 52 1187675579945 4183
The local variable protocol is never read JBLS/util BotNet.java line 61 1187675581300 4217
The local variable ret is never read JBLS/Hashing BrokenSHA1.java line 23 1187675579944 4182
The local variable sName is never read JBLS/util BNFTP.java line 87 1187675581139 4210
The local variable upper_offset is never read JBLS/Hashing CheckRevisionV3.java line 282 1187675580660 4195
The method hex(int) from the type HTTPParse is never used locally JBLS/HTTP HTTPParse.java line 351 1187675579858 4178
The method sendHashFile(String, String[]) from the type HTTPParse is never used locally JBLS/HTTP HTTPParse.java line 272 1187675579858 4177
The static field PEFile.EXPORT_TABLE should be accessed in a static way JBLS/util/PEFiles ImportAddressManager.java line 31 1187675581915 4233
The static field PEFile.EXPORT_TABLE should be accessed in a static way JBLS/util/PEFiles ImportAddressManager.java line 44 1187675581915 4234
The static field PEFile.EXPORT_TABLE should be accessed in a static way JBLS/util/PEFiles ImportAddressManager.java line 45 1187675581916 4235
The static field PEFile.IMAGE_NT_OPTIONAL_HDR32_MAGIC should be accessed in a static way JBLS/Hashing CheckRevisionV3.java line 168 1187675580659 4191
The static field PEFile.IMAGE_NT_SIGNATURE should be accessed in a static way JBLS/Hashing CheckRevisionV3.java line 166 1187675580658 4190
The static field PEFile.IMPORT_TABLE should be accessed in a static way JBLS/Hashing CheckRevisionV3.java line 177 1187675580659 4192
The static field PEFile.IMPORT_TABLE should be accessed in a static way JBLS/Hashing CheckRevisionV3.java line 354 1187675580661 4198
The static field PEFile.IMPORT_TABLE should be accessed in a static way JBLS/Hashing CheckRevisionV3.java line 355 1187675580661 4199
The static field PEFile.RELOC_TABLE should be accessed in a static way JBLS/Hashing CheckRevisionV3.java line 184 1187675580659 4193
The static field PEFile.RELOC_TABLE should be accessed in a static way JBLS/Hashing CheckRevisionV3.java line 312 1187675580660 4196
The static field PEFile.RELOC_TABLE should be accessed in a static way JBLS/Hashing CheckRevisionV3.java line 313 1187675580660 4197
The static method destroyAllConnections() from the type BNLSServer should be accessed in a static way JBLS/util BotNet.java line 263 1187675581302 4223
The static method destroyAllConnections() from the type BNLSServer should be accessed in a static way JBLS/util BotNet.java line 266 1187675581303 4224
The static method destroyAllConnections() from the type BNLSServer should be accessed in a static way JBLS/util Controller.java line 26 1187675581434 4226
The static method destroyAllConnections() from the type BNLSServer should be accessed in a static way JBLS/util Controller.java line 50 1187675581435 4227
The static method destroyAllConnections() from the type BNLSServer should be accessed in a static way JBLS/util Controller.java line 81 1187675581435 4228
The static method destroyAllConnections() from the type BNLSServer should be accessed in a static way JBLS/util Controller.java line 86 1187675581436 4229
The static method destroyAllConnections() from the type HTTPServer should be accessed in a static way JBLS/util BotNet.java line 262 1187675581302 4222
The static method destroyAllConnections() from the type HTTPServer should be accessed in a static way JBLS/util BotNet.java line 269 1187675581303 4225
This method has a constructor name JBLS/util BNFTP.java line 33 1187675581138 4207[/code]

i'm at 1024x768 which is the best res for working int he dark IMO.
And this is bullshit, 88 warnings my ass. Figure out how to reproduce the warnings through command line and I'll fix them, untill ten, shush.
Eclipse is jsut being gay.
And I don't like using IDEs. not my style.
I prefer writing the code myself, not following prompts from a dammen IDE (at times hats pretty much what java does, you can write entire function by doing nothing but hitting the direction arrows)
we're on the 2nd page now so it should be good, just dont start quoting long code again. If you do use the quote tag.
~Hdx

I know what you mean; I maintain makefiles for my automated build process, so I'm not hell-bent on the IDE. It's just much easier to actually write code in it, because of the context-assistant, the jitter, the error quick-fixes, etc. Writing java code without Eclipse takes longer, and is just more of a pain.

I suppose you don't miss what you've never had, though.

Or maybe the more appropriate phrase is that you can't teach an old dog new tricks.

Or perhaps just, "you're f#&king stubborn."

You don't have to try it, and if you try it you don't have to like it, but you do have to try it before you can say you don't like it.

In any event, did you even read any of the warnings that were posted? They're all trivial changes, so you might as well make them. Mostly unused variables.

Ya, I just read them, I didnt see that you edited your post.
I'm not stubborn, I can be taught new tricks, And I have used eclipse/other IDEs before. I just think it's better to have raw access to the file without all the frills of an IDE.
If you're a competent programmer you'll know how to fix errors without an IDE holding your hand.
Anyways, get me the command line eclipse is running so i can reproduce these warnings (warnings != errors btw)
And it's right, it's jsut bitching because of the way I documented parts of my code. (For example look at my Packet ID list)

the main problem is getting the command like to be as bitchy as your IDE, because to be honest, I don't thin java is the one bitching,  think it's eclipse. (One more reason I don't like it, its to picky)
Also the fact that when I'm coding, I don't have a GUI, I shut everything off except terminal.
~Hdx

Whatever man, I'll take the jitter over trial and error any day. I can write a huge object model and know it compiles just because the jitter's been following me each step of the way. Eclipse even closes your braces and parenthesise for you - and I know that sounds like having an assistant to wipe your ass for you, but the next time you have to write ten thousand lines of repetitive code, you'll wish you had it.

The argument that IDEs are a crutch for weak developers just isn't valid. I'm going to go way out on a limb and guess that you got that impression because your only experience with Java development is your own personal work and in school. If that's the case, you should be aware that you're surrounded by people who are just learning (read: idiots), and who are looking for any crutches they can find.

At my company, there are approximately 30 Java developers, and they've been developing in Java since before pertinent IDEs were around. I personally have been using Java since NetBeans was the greatest one, and I absolutely hated it, so I always took the approach you're taking now by doing everything at the command line - although I used make files cause they're sexy. When Eclipse came out with a jitter, they all adopted it in its first version. I didn't get my hands on Eclipse until a generation or two after that, but I fell in love with it as soon as I did.

It's true that the responsibility of the IDE is to make the developer's job easier, but why does that have to be a bad thing? That's like saying cars are bad because they make one's commute easier. Sure they break down every once in a while, but you're already a mechanic so who cares?

My $0.02

[edit] Who cares what the source of the messages is? Are you trying to argue that unused variables are good?

[edit2] I forgot to mention the debugger interface. Ever tried to debug a java program with jdb? Bleh!

[edit3] Did I mention built in CVS integration? SVN with a plugin. Very convenient.

No i'm not arguing that unused variables are good.
But, it's actually an optimization of the compiler that nops out unused variables. So having them has no effect on the compiled program.
But meh it's just laziness on my end.

As for my only experience with java being personal and school, this is not entirely true.
Last year a group of us (read: 8) worked on a project for a company out teacher worked for (so yes can be considered school, but we got paid $500 each, so I'd call it work)
(it was just some user tracking/database management system for some local company, I can't remember the details)
But that experience taught me a few things.
CVS is nice for team projects
IDEs are nice for rapid bug fixes in a team
IDEs do most of the work for you
I suck at organization/structures
and finally IDEs make programmers stupid. (Seriously, People didn't know how to compile the code themselves, or commit it to CVS with anything but eclipse)

I'm not trying to say ides are bad, on the contrary, I can see how people like them they are really useful (Read: Eclipse's built-in bnetdocs is the pwnzorz)
But it's just my personal style to shy away from them unless i'm in a team project. (Nobody has expressed real interest in deving on JBLS or I would make the dev more easily accessible to users)

BTW, I went and fixed all the things that are causing the last warnings you showed. even though I can't see them on my end cuz I don't use an IDE but anyways. most of the crap was jsut laziness on my end. I'm actually dedicating 3.3 to optimization, and cleaning, cuz i'm bored.

~Hdx

[quote author=Hdx]But, it's actually an optimization of the compiler that nops out unused variables. So having them has no effect on the compiled program.
But meh it's just laziness on my end.[/quote]
You won't see me arguing for manual optimization over the compiler, but come on! Leaving stuff like that in is just asking for trouble. Besides, the intent of the warning message is to remind you that you created that variable for a reason, but never remembered to use it. It's another trick you can use to speed development if you don't have enough RAM available to your brain.

[quote author=Hdx]As for my only experience with java being personal and school, this is not entirely true.
Last year a group of us (read: 8) worked on a project for a company out teacher worked for (so yes can be considered school, but we got paid $500 each, so I'd call it work)
(it was just some user tracking/database management system for some local company, I can't remember the details)
But that experience taught me a few things.
CVS is nice for team projects
IDEs are nice for rapid bug fixes in a team
IDEs do most of the work for you
I suck at organization/structures
and finally IDEs make programmers stupid. (Seriously, People didn't know how to compile the code themselves, or commit it to CVS with anything but eclipse)[/quote]
That is a prime example of the situation I just described. I think you'd be hard pressed to find a senior Java developer, or even a competant Java programmer who isn't, at the very least, familiar with the command line tools.

Just out of curiosity though, if you suck at organization and structures, why'd you choose an OO language? Your Java code reminds me of a C daemon more than a Java server.

[quote author=Hdx]I'm not trying to say ides are bad, on the contrary, I can see how people like them they are really useful (Read: Eclipse's built-in bnetdocs is the pwnzorz)
But it's just my personal style to shy away from them unless i'm in a team project. (Nobody has expressed real interest in deving on JBLS or I would make the dev more easily accessible to users)[/quote]

I distinctly remember offering to port lockdown and being shunned.



While the discussion's open, and this would probably be better suited in the Java Programming forum, but here goes anyways:

One of the philosophies I hold very highly is that objects have single, simple, one-liner responsibilities. I've heard people argue that this is stupid because Objects have lots of overhead, and if you create lots of them, you'll use lots of memory. My response to that is get over it, or stop using Java.

Objects are instances of classes - you might be surprised how many Java developers in the field don't know that. Semantics.

I don't see the use of any design patterns in your code. It looks like everything was just randomly thrown together the way an inexperienced programmer would do it. Don't get me wrong, I'm not bashing your code, I simply don't see where the design came from. To help you understand exactly what I mean, I'll briefly explain the object model for my bot:
[hr]
Core package: A collection of classes with the joint responsibility of establishing and maintaining a battle.net connection
Connection - abstract representation of a connection of unknown type to battle.net - could be BNCS, BNFTP [not actually BNFTP, but that's a discussion for another day], or CHAT
BNCSConnection - name should say it all
ChatQueue - a simple chat queue. Some day, I'll make it a priority queue

Bot package: A collection of plugins designed to to act as robots and human interfaces
EventHandler - interface for plugging in to the core of the bot. Defines every battle.net event (user joins the channel, user emotes, a user on your friend list was promoted, etc)

Extensions of the EventHandler include (but are not limited to):
TriviaEventHandler - provides trivia for hours of fun
GUIEventHandler - provides a GUI to the user
ConsoleEventHandler - provides a CLI

A variation on the EventHandler interface is the RealmEventHandler - it has all of the MCP events. I won't go in to detail here.
[hr]
At run-time, the bot reads the settings file, and builds a Connection based on the settings provided. Based on the user's input, it will decide which plugins to enable (CLI, GUI, Trivia, etc). For every plugin to be loaded, it will create an instance of the plugin, and link it in with the connection.

Now the object model is assembled in memory, here's how it actually works: Every time the Connection generates an event, it broadcasts it to all of its EventHandlers. See below:

By the way, I know I'm not blocking on the semaphore properly in addEventHandler(), but it doesn't matter because that method is only called from initialization code.
[code]public abstract class Connection extends Thread implements EventHandler {
protected ConnectionSettings cs;
protected ChatQueue cq;
protected LinkedList<EventHandler> eventHandlers = new LinkedList<EventHandler>();

private int eh_semaphore = 0;

private void waitForEHSemaphore() {
while(eh_semaphore > 0) {
try {Thread.sleep(10);} catch (InterruptedException e) {e.printStackTrace();}
Thread.yield();
}
}

public void addEventHandler(EventHandler e) {
waitForEHSemaphore();

eventHandlers.add(e);
e.initialize(this);
}

public synchronized void recieveEmote(BNetUser user, String text) {
eh_semaphore++;
Iterator<EventHandler> it = eventHandlers.iterator();
while(it.hasNext())
it.next().recieveEmote(user, text);
eh_semaphore--;
}
}[/code]
[hr]
Okay, so a page and a half isn't terribly brief, but I'm sure you get the point.

Meh, I'm trying to understand what having specialized handelers like that are suppost to be used for in a single static query->response system like JBLS... Somethin like that would only bee needed for a system with multiple responses to a static query.
I think I have everything pretty well sandboxed in, cept a few parse classes where I tack everything not the same switch, but I'm planning on fixing that in my 3.2/3 release.
As for choosing Java.. Its just something that fell into my lap and never left. Meh.
(Ugh I Have to go finish registering for school today -.-)
~Hdx

Wasn't exactly my point. That is one example of a design pattern I use. If you don't already know, a design pattern is most loosely defined as a solution to a problem. A better definition in my opinion is that it is a good solution to a common problem. Things like singletons (although tabu), factories/abstract factories, adapter, bridge, decorator are all examples of design patterns. Wikipedia has a long list of them, and I would definitely consider studying every single one of them to be a pre-requite to becoming an expert OO developer. I might even argue that it's the single most important thing you can learn about OOD.