This is dedicated to all the hackers and the crackers, to the hackers and the crackers.
I see in binary, I speak source code, step on my toes, I'll post a million jpegs of you
and a fag pwned, in your digital stance getting firewalled ho, cause I'm riding the net in
my six-fold, I was a dick with my 56, now with my cable I'm able to get that stable,
on the out, my name is Ace and I'm a Leo, on the digital highway, my name is Neo and
I'm a hero, in a flash, I'll screw you on burning dreamcast, you need some ISO, let me through
my hard drive rifle, our exchange you could never stifle, in a digital hug, you just caught
the love bug, I bootlegged your CD, I caused a fight between Un and Jay-Z, your CG, it's
all gonna be free, whether we take it by force or we take it nicely, you feel that rattling
your phones, when I tell you we just hacked out Jones, and NASDAQ leaves you flat on your
back, cause I am he who loves to hack and crack, cause I am he who loves to hack and crack.
This is dedicated to the hackers and the crackers, serial codes, source codes, ISOs, RANs, SIFs,
SIFs, this is dedicated to the hackers and the crack.
Welcome to Binary Revolution Radio episode, I think 195, I really don't know that either,
last one I had recorded was 194, so I think that's where we left off, so 195 today is,
let's see, you're hearing this June 5th, Tuesday June 5th, 2007, Not Theory is on the phone
with us for the episode this week, I'm at the house, what's up?
In the hazy, and if we can actually get through this episode without totally cutting up and
ruining the entire thing, as we've done how many times in the last 10 minutes, let's see,
let's do some housekeeping, got any Bell's Mind housekeeping? I noticed the mysterious circle
that we mentioned on the last episode has disappeared.
Yeah, I don't really want to talk about it too much, it's top secret, but the people who figured
out the Easter egg, they all know what's up.
Alright, well, I guess that, we'll leave it at that, you got any other updates to Bell's
Mind to talk about?
Nope, things are back online, they had a little hit at downtown, somebody contacted me actually
recently, just a couple days ago, asking how the hell to parse out all this crazy JavaScript
content that's a site that's now, ignore all the JavaScript, if you're trying to scrape
stuff from Bell's Mind, basically, do an NPA search, and find the links off of there,
all of the links are still straight HTML, eventually there will be an API, if you're interested in
it, email me, otherwise, keep scraping the site, it's no big deal, do it as much as you
like.
And speaking of contacting you, there are right ways and wrong ways, why don't you yell at
everybody about the right ways to contact you with information or questions about Bell's
Mind?
The wrong way to contact me is to not contact me and ask somebody else what's wrong with
Bell's Mind, that doesn't work.
As in the forums?
What's that?
As in posting to the forums?
Yeah, for anybody who doesn't know, I realize that I'm kind of like an absentee hacktor at
this point, because I pretty much just work all the time, so if you don't know me, I'm
the guy who runs Bell's Mind, so email me, N, the letter N, theory, at Bell's Mind dot
net, and if you put Bell's Mind in the subject line, I will actually read your email and
reply to it, and if I promise that I'll do something the same day, and I'll get to it
like four or five days later.
Yeah, you'll reply, you'll lie your ass off, but you will actually reply.
No, the two people that emailed me, one guy had a crazy long handle that I can't remember,
but I'm going to post some of this code on the site soon, so you'll all know who he
is.
I got back there pretty quickly, and I still have a pretty good response, he's having some
account problems, but if you're having account problems, if you can't register, can't sign
in, let me know.
If you can't get to the site, let me know.
If you can't hear Binary Revolution Radio, then you're pretty much SOL, so let me know.
I guess if you can't hear Binary Revolution Radio, let me know, but that doesn't make any
sense either, but anyway, let's see, what else in the housekeeping, obviously, we had
another few weeks hiatus there, I was out of town for vacation, and we are pretty much
at the point where I'm the only one doing the show these days, nobody else has time
or is able to fill in and do the show, so we are not weekly these days, we are, whenever
I can get a show out, that's pretty much all I can tell you right now, planned ahead
for this, and as usual, plans fall through for one reason or another, so unfortunately,
there's nothing I can do about it, always took pride in having the show come out regularly
and every week, but just not going to happen, so I'm just telling you up front, disclosing
to you that it's not going to happen.
Speaking of things that aren't going to happen, in Bell's mind, where's Freak Factor?
I don't know, it's pretty much the same place that like eight episodes of Binary Revolution
are, but nowhere.
And they're recorded and just haven't been released yet?
Oh yeah, yeah, we did some Secret Bell's mind, Freak Factor recording, and nobody knows
about it, but the tapes, as they were, were lost, so.
There are actually some recordings on your box, but that's a whole other story altogether.
Yeah.
There are actually a lot of recordings, believe it or not, some people have recorded radio
shows on there from some interface I set up a long time ago, and they're still sitting
there.
I don't think they know how to get to them anymore, because they never cleaned them out,
so I don't know what the hell's up with that, but anyway, whatever.
There you go.
Well, as for the main topic this week, I'm not even sure if we're going to have time
to get to a main topic anyway, so I will mention it later if we have time in the show, but because
of the long hiatus, and because of the fact that I purposely saved a few emails from the
last episode that you and I did, where the topic was Java, I purposely saved some emails
from then, and we've had some other emails since then, so this may end up being an old
email show, a Java redux, Java part two, a redo, if you will, and if we have some more
time, we'll go into a main topic later.
We do have one, but we may just sit on it until the next episode.
So, that being said, let's do some email.
Okay, email for this week, which is, there's quite a bit of it, so, and quite a bit of
it's very long, so not theory, I'm going to just basically, let's go ahead and set a ground
rule right now, that we're just going to start reading it, and interrupt, jump in any time
when there's a point we want to respond to, because if we read the whole email, and wait
to respond at the end, we're going to forget things, they're really long and detailed this
time, which is very cool, actually, it's very good, so let me just start reading, and you
just yell and interrupt, and, I don't know, scream out Armageddon, that's our safe word,
you can scream out Armageddon and interrupt me if you want to add a point to this.
All righty.
All right, first email this week comes from, we're going to call him KG, because he dropped
his docs, I don't know if it's real docs, or if he probably is okay with us reading
it, but we're going to call him KJ, did I say KG?
KJ, just to be safe.
KJ says, I think that this discussion was a bit loose, and he was referring to our Java
episode, I think that this discussion was a bit loose.
I hate Java's guts, is too complex, verbose, and convoluted language.
However, when you said about write once, run everywhere, I think you could have approached
it better, I'm going to correct this as we go along, maybe KJ could approach his English
better, but, I mean, you got stuck on the write once, run everywhere, as long as you
have a VM.
Did I get stuck on that?
I know I brought that up, did I get stuck on that?
No, I don't think so, I mean, we definitely brought it up, but I'm, I don't know, that's
the big deal about Java, there's really not much else to talk about.
Well, true.
I think this is very logical.
I guess he means to say illogical.
I think this is very illogical.
I mean, you can say the same thing about Flash.
You write a SWF once, and it will run on everywhere, as long as you have the Flash player.
So the platform is independent, which makes your code portable.
You can say the same about, and HTML is a write once, run everywhere.
Armageddon, Armageddon, I disagree.
As long as you have a browser.
Now, Flash, on the one hand, yeah, it's write once, and it runs the same, almost the same,
everywhere.
Same with Java, runs very, very similar.
HTML, there are no sets that you could possibly be safe on, but HTML is different.
It's different in one version of Firefox, so HTML doesn't really fit that.
But I thought we had mentioned that Flash was very similar to Java, and that you could
write it, and it would look very similar on most architectures.
Well, I think I even brought up, I think my example was the same thing with .NET.
You have to have the .NET framework installed to be able to use all that stuff as well.
So, I mean, I think that's a fair comparison.
I think we definitely talked about that.
Maybe he wrote the email before he listened to the full episode or something, I don't know.
But we definitely brought some of that up.
Now, I'm going to actually defend him a little bit and play devil's advocate.
Actually, no, I kind of, well, let me see what you think about this.
When he says HTML write once, run everywhere, if you use HTML 3.0, 4.0 standards and no custom
browser markups and stuff like that, do you still disagree?
No, yeah, I don't really think so.
I think that some things do render slightly differently.
I mean, if you did everything like absolute positioning and all that kind of stuff, yeah, it does look
the same pretty much everywhere, but I'm sure that there's some quirk in some browser that
just makes it non-match up.
But you know what, HTML, HTML and Java and Flash, they're very different things.
Java and Flash are much closer to each other than HTML because there's no, there's no virtual
machine in HTML.
Like, it's a format that you parse and you display it.
Right.
But the whole virtual machine thing is very different.
Well, right, well, it's right there in the definition, HTML is a markup language, so it's
interpreted on the fly.
All these other things are either pre-compiled, depending on, again, what flavor of Java and
Applet and all that other stuff we want, we'll back off of that because we're going to talk
about it later, or it's compiled on the fly.
Right.
You know, so it's like, not compare, it's not, I don't know, it's not a good comparison
with HTML as far as that goes anyway.
I don't know.
Ah, let's see, so, um, um, um, um, um, um, where was I?
Okay, just as HTML3.x dump developers start using Java, I guess dumb developers, that's
an irony statement, ironic statement right there, dump developers start using Java and encapsulating
on a Windows-specific environment.
So a Java app will be on a exe installer, which makes it unusable in Linux.
This happens on clients such as TalkShoe.
The installer is useless to Linux, so to make it work, you have to install it to Windows and
then move the installation folder to Linux, and only then Java on Linux can run the client.
Many banks also have some crappy IE-specific web applications which won't work on the Linux.
Now wait a second, wait a second.
He's talking about IE-specific.
Is he talking about, like, IE and ActiveX application?
Like, that's not Java.
That's not what we're talking about here.
Right, I, I, he's not really giving us enough information.
I'm assuming he means Java apps written specifically for Internet Explorer, possibly using the IE libraries
and displays libraries or something?
I don't, I don't know.
Maybe, maybe I'm too much of a Java dupe, but I didn't really think you could make an applet
that, that ran on IE if it's run on Firefox.
But, I've just never seen that before.
I honestly don't know the answer to that either.
And that's, the whole thing is there's so much to Java that's, there's so much overwhelming
information, I just don't know what to believe.
So much conflicting information too, and I think we're going to find that out through some
of these upcoming emails.
Let's see, to go on with KJ's email here, on the Mono versus .NET versus Java, well, Mono
has some philosophical goals to justify its existence.
What is true is that Mono is more like a framework.
You can run Java in Mono, as well as other languages like Perl, Python, C++, etc.
The so-called Windows Forms versus GTK toolkits, GTK sharps toolkits, and how to map each widget
with the next.
Yeah, I, not to be a dick, but that was really broken English through the whole email, so
just trying to understand what some of these things were.
It really jumped around a lot.
So, I don't know, some of those things I think we did talk about.
I don't remember us doing a Mono versus .NET versus job.
I think we mentioned all three of those things, but I don't know that we did a quote versus.
Did we?
Yeah, you know, man, I don't know that I could really say that I know enough about, I mean,
I've used .NET plenty, but I haven't really used Mono all that much, so I don't really
think I'd be qualified to make any type of comparison on that.
Yeah.
I mean, I think we might have simply mentioned that Mono is the attempt at making code written
in .NET portable over to Linux, so that you can use the same function calls that you would
use in .NET, even if it's called, you know, resize underscore win, or whatever, and I'm
just making that up.
I don't know if that's real, so don't email me about that.
But if it's called that in .NET on a Windows environment, they're trying to make that same
function call with the same parameters over in the Linux environment.
Now, they may have to write the code behind it to do it a little differently, but at least
keep the names and function calls the same so that the code will port straight over there
without having to rewrite specific Linux-only versions of the same thing to draw a Windows
version where it's ex-Windows, GNOME, KDE, et cetera, et cetera.
Yeah.
But, yeah, that's definitely something that I have not, I have never done anything in
Mono, so I'll say that up front.
Yeah.
Actually, the only thing I've tried to do in Mono is I've tried to take a .NET application
that's done it with Mono, but apparently Mono doesn't implement the Microsoft, like, Windows
forms, so this thing tried to put up a message box or something like that, and it just
wouldn't, it would give me some error saying that it couldn't find Microsoft.messagebox.show,
or Microsoft.visualbasics.messagebox.show, or something like that.
So, I don't know.
Mono seems like a bit more of a disaster to me than Java right now, just from the little
bit that I've seen.
I'm not saying that it is definitely, but I haven't seen anything great that runs it.
I've seen, I actually heard, I forget the name of the music player, but suppose that there's
something like Mono Music Player for Linux that's just fantastic.
So, I want to check that out, actually, tonight, to see what it's all about, but so far, Mono
hasn't really blown me out of the water.
But that actually brings me to an important side.
For anybody out there who is a .NET wizard and who uses, or at least knows about VisualBasic.NET,
please email us, or me, or somebody, and let me know if VisualBasic.NET supports incremental
builds.
Because I'm working on a huge VB.NET project for somebody that I really hate, and anytime
I change anything, it takes, like, fucking two minutes for the damn thing to just stop
maxing out the processor to let me use the editor again.
So, I just had to throw that in there.
I don't think it does support incremental builds from seeing this.
VisualStudio.NET 2005, and anytime I change anything, I just piss away minutes of my time,
and it makes developing pretty much possible.
All right, there you go.
All right, on that, let's move ahead to a next email from Vati, who was nice enough
to give me a pronunciation for his handle, so take note, people.
Vati says, background, I've been coding primarily in Java, Gawk, G-A-W-K, and PHP for five years,
miscellaneous other languages longer.
Okay, so he's established credibility, so I like the start of this email.
One of Java's great aspects is its stock API, collections of pre-existing objects like GUI components or database connectors.
There are three sizes, quote-unquote, sizes available, so you don't waste drive space with extraneous features.
J2-ME is micro, J2-SE is standard, and J2-EE is enterprise tons of stuff.
So, let's see, keep your target audience in mind.
If your program includes objects in a larger slash newer API than they have, it'll die.
Stick to basics, and your EE dev environment can probably compile apps that run on ME phones.
Most people run 1.4 SE and up.
Compilers have switches to dumb themselves down, but instead, I stay a couple generations behind to be safe.
I'm going to stop right there.
Do we have any reply to that?
I think we kind of bitched and made some comments along those lines,
but I think he actually explained it a little bit better.
Yeah, so far, I'm with this guy.
Yeah, I think that's clear, the way he worded it is probably better than we did.
And actually, I think we were kind of questioning that anyway, so that kind of clarifies some things.
And staying a couple generations behind, see, I don't like the idea of that.
That's not good backwards compatibility when you're scared to upgrade and stuff like that,
but that's a whole, I guess, a whole other topic.
So, he's saying, basically, that just get the J2EE edition or 1.4 SE or above,
and if you're going to develop a micro application, I guess, to use this terminology,
or an ME for something for a cell phone, a portable PDA or something like that,
to just be careful to only use the micro libraries for things that you want to do.
Is that what I'm reading into this?
Is that what he's saying, he or she?
No, I kind of thought that he was saying, basically, use the smallest functions that's possible,
and you may turn out you don't need all that.
You know, if your application is written as J2SE, you might be able to get by with just the J2ME functionality.
But if you were making a J2ME application, and you try to use an SE function or EE function,
it just won't compile.
It will just tell you, I can't find this.
Well, if you tried to code that in the IDE, it's not going to find the libraries that come with SE or EE
because you didn't install them.
Right, right, right.
So they rolled downhill.
The EE should come with everything that the SE and the ME comes with.
Right.
Is that right?
So why not just always use the J2EE and just be knowledgeable and understand which libraries you're going to need
for which applications you're going to write?
Why do they have to break it up into three different things?
Why not just have, you know, project-based?
What type of project are you writing?
Just have one IDE, J2EE, Enterprise whatever edition,
and then when you start a new project, program, whatever nomenclate you want to use, select.
Are you writing something for a portable object?
If so, I'll only demonstrate and show you the available objects and libraries for that type of application.
That's something that's an issue we handle in the IDE.
Oh, yeah, actually, Eclipse does that.
Eclipse will let you set project-specific and say,
okay, for this project I want to use Java 1.3 with only these particular settings,
and I want, you know, I want to be able to auto-complete these different libraries.
Yeah, Eclipse definitely does that.
You have one editor that does M-E-S-E-E-E.
It's exactly what you're talking about.
All right, so that should just, it seems to me like we don't have a need for J2M-E-S-E-E.
Just have one fucking development environment and let the users select what they're doing.
You know, this is for programmers.
If you can't figure that out as a programmer, then...
But I think you're confusing the development environment and the run time.
The point is the development environment can support all of them.
You can let your app, whichever application you want.
Right.
Or whichever standard, M-E-S-E-E-E.
But if you're running something on a phone, it only has the M-E run time,
which means it has this very small subset of functions they can use.
So if you try to use something that's S-E-E-E, it's just not going to run.
All right, I hear you, but I'm saying that when I, let's say I use, again, the E-E,
let's call that the I-D-E, we're going to call it J2-E-E or whatever.
I don't know.
What was the name?
Is there a name of the actual development environment itself?
Yeah, Eclipse.
Eclipse, okay, I'm sorry.
Maybe I'm using, maybe my names are...
So let's say you're in Eclipse and you want to write a program.
Why not just have one super version of Eclipse that has E-E libraries, S-E libraries,
and M-E libraries, all of them?
And I say...
That's what I'm saying.
Eclipse has that already.
That's exactly what Eclipse does.
Well, then why does J2-M-E and S-E and E-E, why are they all separated?
Because they're different run times.
You might have a device that runs E-E.
You might have a phone that runs S-E.
You might have like a web server that runs E-E.
It needs to do a lot of stuff.
Oh, so this is not...
When you download a development environment,
you're not downloading only the J2-M-E Eclipse with only J2-M-E libraries?
No, you might be able to download like a J2-M-E or J2-S-E, like SDK,
but Eclipse comes with everything all together.
Okay, well, that's...
What is Eclipse?
Does that come from Sun?
No, Eclipse is an IDE that was like...
It's an open source IDE.
Actually, it's a framework for building editors that you can...
That they've built this Java IDE off of,
and I think it's kind of sponsored by IBM or stuff like that.
But it's all open source.
It's actually written in Java,
and it's like a really...
It's a really amazing development.
Well, that's great.
I mean, it sounds like there was a need for that.
It's a great thing.
But let's take that back out of the equation
because it's not something that Sun delivers as something for Java.
It's a third-party thing.
Oh, yeah.
So it sounds great.
I can't say much about Sun.
I don't know what to say about those guys.
Yeah, I mean, from what I've seen in my experience,
I go to the website to download a development,
and I have to download one of those three.
At least the last time I looked,
and I got so frustrated, as we've talked about in the other show,
it's like, geez, why can't I just download one thing
and then let me wade through and read the RTFM
and figure out what libraries I need to use
for what application I need to develop?
So it sounds like that need was so in demand
that third-party people, open source, whatever,
have developed Eclipse to do exactly what I'm describing to do,
which is great,
but let's not give credit to Sun or to Java for doing that.
They obviously missed that need,
and thus there was a need for third-party people,
whether it was IBM or whatever,
to come in and develop that.
So that's a good solution.
I like the idea of that,
but let's not give credit to Sun or to Java for that,
in my opinion.
Okay, fair enough.
All right.
And, yes, we're going to get a lot more hate mail for this,
but that's all right.
That's the way I feel about it,
so what can I tell you?
Let's see.
Where did I leave off here?
SE has got more than enough for general purposes.
I've rarely needed to look for libraries outside the API
to include with my app.
JDOM is a particularly nice XML parser live by the O'Reilly guys.
That's J-D-O-M.
And, actually, you know,
actually one other question,
because you kind of mentioned this about most people run 1.4 SE and up.
As far as the runtime environment,
you have to be careful.
I mean, you can't assume that everybody has the latest version of the Java runtime stuff, right?
Right, exactly.
So if I run with the just absolute cutting-edge latest version of Java,
anybody that wants to run that Java app is going to have to download that latest runtime library, right?
That's why Java is all the time being updated.
Yeah, exactly.
So it's easy to say something is run anywhere when the quote-unquote anywhere is constantly being updated and changed.
Yeah, exactly.
It's not exactly a perfect system, but the best they've got right now.
But it's not run anywhere.
That's the point I made all along, and people seem to be trying to defend.
The bottom line is it's not run anywhere.
It's run anywhere that has the latest runtime environment updated and installed, you know?
Right.
I mean, I understand it's the nature of it.
Don't get me wrong.
I understand the nature of it.
But let's just be honest and not call it run anywhere.
It's run anywhere that has the proper version and the proper runtime library type,
whether it's M, E, S, E, or whatever,
and the proper version or higher that you need.
Right.
But the point of the whole virtual machine thing
is so that somebody can do the implementation of the virtual machine on that platform once,
and then all of those other things can run on it.
Whereas if you're writing a C application, C is portable, right?
But everybody who writes a C application needs to know about all these quirks of different operating systems
to make it run on those other operating systems.
Whereas a Java virtual machine is supposed to take care of that for you.
And despite what you may think, it really does a pretty good job of that, I think.
No, I think...
At least on the platforms I've seen.
Oh, I definitely think it does it better.
No doubt about that.
I'm not completely saying that it's garbage or anything.
I'm just saying let's put it in perspective.
Let's not...
You know, some of these Java zealots will just put it up on a pedestal like it's the greatest thing ever.
It has flaws, too.
Yeah, everything has flaws.
Yeah, so there's nuances.
Yeah, yeah, right.
The mysterious circle.
That's all I have to say.
It's totally mysterious.
It can take apart guns with its mind.
But keep your eyes on, it may come back in the future, listeners, if you find it.
Behold its power.
Another nice thing is that the whole API source code is available.
Well, of course, that's a great thing.
You can see the guts of a J button or linked list.
You can start by coding RAD style, which is rapid access development.
RAD style, and then eventually streamline by copy-pasting to create an identical but custom object and stripping out methods.
Or if a new Java 1.x introduces a bug, you can make an old-school button from the previous source.
Totally feel you on that one.
That's definitely straightforward.
Cool.
As mentioned before, the write once run everywhere means your users don't need to troubleshoot compiler errors.
They do have to install a virtual machine once.
Okay, I'm going to stop.
Armageddon!
They have to install a VM once.
I'm going to insert and constantly upgrade it as new releases come out.
Oh, you don't have to worry about updating it because Java Update does that for you like 15 times a day.
I know, constantly.
I swear to God, I am not joking.
I did that before we started recording and rebooted my freaking machine.
Of course.
Let's see.
They do have to install a virtual machine once, but from then on, they just run your JAR, and it behaves the same on any virtual machine.
And again, correct me if I'm wrong on this or if you know this, but we're going back to what he said.
I think that's within the parameters he laid out earlier of only using the standard stick-to-basics that he says earlier.
Your EE dev environment can compile apps that run on, blah, blah, blah.
So sticking with the libraries and the APIs that it comes with, not using any third-party.
And actually, I'll throw that question out to the interweb listeners.
Are there third-party, are there libraries that don't come with it?
It may come with a lot, but are there third-party libraries?
I know with Visual Basic and a lot of the other visual languages, you can buy third-party libraries that you pay for for things like doing extra graphics functions or 3D graphics and game development, things like that, that you can buy third-party libraries to use.
Is that the same for Java, or do you know the answer to that in our theory?
If you can buy third-party libraries, absolutely.
Yeah, there's tons of them.
For Java?
Yeah, for Java, definitely.
Okay.
Interesting.
Now, if you do that, if you buy third-party libraries to develop, say, I don't know, a game, so you buy third-party libraries that have some tools that help you in programming games like animation or something, and then I want to distribute that.
How do I get those third-party libraries to work on a virtual machine of somebody that didn't have them?
Are they included in the JAR file so that when they get there, they'll load into the virtual machine somehow?
Yeah, you could put them, you could include the JAR files, or you could include those classes in your JAR file.
So, yeah, the distribution of that is all, the package builder, the JAR builder that you have in Eclipse will handle all of that kind of stuff for you.
Now, see, that, now that I know that, that, I think, would alleviate a lot of my frustrations if more people did that.
Is that, sounds to me like that should be something that's a standard programming practice, include any external libraries.
Because, when you, when you put something to a JAR file, I assume there's some sort of packaging process that will put everything you need into that JAR file?
Yeah, exactly.
Hmm, very interesting.
That?
But, honestly, the, the applications that I've worked with, you know, I, I deploy what's called a WAR file.
It's a web JAR, basically.
Mm-hmm.
And I have some external libraries that are required for that, Postgres library, and, and things along, along that line.
But, uh, I actually just put those on the server, and I don't include them with my, uh, with my WAR file.
So, I haven't done it before, but I'm pretty sure that you can just tell it, include these files, and, and stuff them into the JAR, and it should be just fine.
But if you can't, you can distribute them alongside of the, uh, of the JAR file.
So, there is, there is a way to do it.
But, but you have to go, do you have to go out of your way to tell it to include those, or isn't it smart enough to automatically say,
hey, these are not part of my standard runtime library, these APIs, or something separate, and automatically include them?
Well, you know, like I said, I've never packaged a JAR like that before, but Eclipse is definitely smart enough to know when things are missing.
So, once again.
So, if Eclipse exists, Eclipse doesn't.
So, Eclipse saves the day again.
Yeah, Eclipse actually is supposedly IntelliJ, which is, uh, another editor, or another IDE for Java.
It's supposed to be a million times better than Eclipse, which I don't understand how it's possible, but that's what people tell me.
So, if you want, maybe you should just check that out from the start, see what it can do.
Cool.
All right, well, so far, I'm, I'm enjoying this email.
I'm actually learning a couple things I didn't realize before.
So, Vati, you got the, you got the good email of the week award so far.
Uh, let's see, where else?
And we're only halfway through this email, a little over.
Uh, a note on virtual machines.
Uh, let's see, am I, did I pick up the right place?
Yeah, a note on virtual machines.
Technically, they're portable in the USB sense.
The installer's mainly for file associations, browser integration, and path variables.
You can simply copy the virtual machines folder around with your app and use a shell script to run dot myvm slash bin java exe space jar space minus jar space dot my app dot jar.
I'm not sure about licensing issues on that, though.
Similarly, you can have several different virtual machines on the same box if you run them that way.
So, actually, there's another stopping point, if I may.
Do you know anything about, why, why would you need multiple virtual machines for Java on the same box?
If Java's so great, why wasn't, why doesn't one virtual machine do the job?
Uh, you know, I think one virtual machine would do the job, but I think that there might be some breaking changes between versions.
So, some things may work or be quirky if you don't have the same version they implemented.
But it shouldn't really be that way, but that's a possibility.
The other reason is that maybe you've got one particular virtual machine that's optimized, that runs, like, I know there's, like, the Sun virtual machine, and there's, like, the Blackdown.
I think it's called Blackdown.
It's another Java runtime environment.
It might be optimized better to do certain things.
So, you might say, if I'm running this type of application, let me use Blackdown.
If I'm using this one, let me use Sun.
If I'm using this one, let me use IBM.
From what I can understand, it would probably just be performance that you'd be worried about.
But maybe there are other reasons that I'm not clear on.
Yeah, I mean, you've got to maintain backwards compatibility.
I mean, if you want enterprises and big companies to use this, but every time you upgrade it, it's going to break stuff.
And I have seen that happen on multiple occasions.
And then they have to release patches, and it automatically updates 50 times a day, et cetera, et cetera.
And then the updates break more things.
So, that's poor implementation by Sun.
But it is certainly another thing that frustrates people.
And that's, again, kind of the conversation.
It's not necessarily me or even us.
You know, we've had issues with Java in the past.
We've talked about it on the show.
But the whole point of the show is let's give Java a fair shake.
Tell me what I'm missing.
Explain to me some of the things that are frustrating and I'm confused by about Java.
And explain them to me.
That's why we've got a lot of great email this week to talk about that.
So, I'm picking up a few good things that I didn't realize, but some of them I still haven't been convinced.
Let me finish this email here.
Let's see.
Yes, Java is usually more of a memory hog and a bit slower than native apps.
It's a tradeoff for end-user convenience and rapid access development, RAD, for devs.
Some third-party virtual machines try to remedy that with optimizations.
Also, don't confuse IE's slow applet startup times with virtual machine sluggishness.
I don't know what IE's problem is, but Opera runs applets instantly for me.
I would assume, not theory, that that's because Opera probably loads it when you boot Opera for the first time,
so that when you do hit a Java applet, a jar file or whatever, that it already has it loaded into memory when it booted the browser,
so therefore it can run immediately and IE probably doesn't load it at startup.
Yeah, that's a possibility.
I think also IE has like a weird mechanism for starting up the Java runtime because, you know,
Java doesn't come with Windows anymore, so I think it's kind of like a clunky process for IE to fire it up.
Like there might be some like helper ActiveX control or something that does it,
so there's like an extra layer or there's an extra step that it needs to go to in order to start that up.
But yeah, I've seen Java applet performance in, I mean, even in Firefox seems faster than IE,
so it's probably just some bad programming at Microsoft's part.
I know that's not possible, but...
Well, I was going to say, then we go back to the old Microsoft released their virtual machine
and that whole mess that it came from that.
Yeah.
So, yeah, I don't even want to go there.
Anyway, and actually, and I'm just thinking out loud here, I don't know if I'm saying this is correct or not,
but as far as a memory hog, is that because the nature of a virtual machine is you have to load
all of the possible libraries that may be needed in a virtual machine into memory,
into the runtime environment, in case they're used?
Do you have to load every possible one?
No, it can load them on the fly.
It can, okay.
Yeah.
So what else could be causing...
I mean, everybody knows, it's common knowledge that Java apps are more memory intensive and CPU intensive.
Why is that?
Well, there's a couple of reasons I can think of that.
But the first would be that, essentially, you've got that extra layer of virtualization going on.
Because I think of resources, whether it's CPU or hard drive space or RAM, that's some of it there.
But also the Java garbage collector doesn't always run when you think it should.
So, like, if you create a bunch of objects and then you destroy them, you think you get that memory back.
But in Java, you really don't until the garbage parts are run.
So it could just be that the application is poorly designed and it's allocating too many things.
That's not, you know, not being as efficient as it could, which I don't know if that's just a Java programmer thing to do or what.
But if you have an application that you notice that way and you have the source code to it, you can, you know, sprinkle coal into the garbage.
You can force the garbage collector to run and see if that helps it.
But, yeah, in general, I'm not really sure exactly what causes – I couldn't say with 100% certainty what causes the memory bloat and Java applications.
But it's definitely there.
I see it.
The application that I've heard, like the Bellspot application, seems to be pretty lean.
But, you know, the PHP application definitely took up a bus pathway.
Hmm.
But it also did a whole hell of a lot less.
So it's really hard to compare, I think.
If you're – so if you are very careful programming, are you saying things like making sure you have destructors every time you no longer need an object?
Do you make sure you destruct everything you've constructed along the way and that will free the memory back up and not let it sit there and wait to be closed by the machine itself?
Well, actually, no.
In Java, what they do, instead of you having to worry about, like, destroying your objects and things like that, they do what's called reference counting.
So, like, let's say I create an object, right, that has a reference count now of one.
Right.
Somebody else, you know, I pass a – or I pass a pointer, kind of, not really, but somebody else gets a reference to that object.
So we're both looking at that object.
So now the object has a reference count of two.
Well, when I dispose of it, when I tell Java I'm done with it, Java decrements the reference counter.
If the reference counter goes to zero, it's supposed to kind of take that memory space and say, okay, nobody's using this anymore.
Let me free it up and, you know, give it back to the system.
But running the garbage collector to do that is, like, a CPU-intensive process.
So they try to avoid it on third virtual machines, especially, like, the J2ME virtual machines that run on your phone.
Like, running the garbage collector on a phone is really CPU-intensive.
So they like to avoid it as much as possible.
So even if your object has a reference count of zero and it's been disposed of and nobody's looking at it anymore, the system knows that that RAM is earmarked to be free, but only the next time the garbage collector runs.
And unless you run it explicitly, there's no way to be sure when it runs.
Sometimes it will only run when the machine runs out of RAM completely.
So that's why, even when you're disposed of an object, it's still there until you actually explicitly garbage collect it.
Gotcha.
Does that make sense?
Yep.
Perfect sense.
Okay.
I love you.
Oh, let's get married.
Let's see.
Email.
A note on applets.
And we're almost to the end of this.
A note on applets.
Applets are different from applications in that their powers are limited for security reasons.
And while applications are isolated, applets within a browser can talk to each other and share static classes slash variables.
All right.
I just popped a thought into my head, and this may be way off because I once again admit that I'm a complete noob at this.
But if it's persistent, what happens if you open two different tabs with two different applets in them?
Can they share?
Are they using shared memory locations where they can read and write from something that's going on in another tabbed window somewhere?
A Java applet over here that, I don't know, has my credit card information or something like that?
Can I write another Java app that, if opened in another browser tab, can read said memory and pull it over there and deliver it to a different site?
I think the way that the Java security model works is that applets from, like, different domains probably can't talk to each other.
I'm not totally sure about this.
But I think when they came up with that security model, nobody really had tabbed browsers.
So that's an interesting question.
I don't know.
Maybe if you had two tabs open to the same website, those applications would talk back and forth,
but maybe each tab is considered, like, a separate applet container or something.
I'm not really sure.
That would be really cool.
Yeah, that could be pretty awesome.
Yeah, actually, one thing I learned about Java that I didn't, you know, maybe I did realize it before,
but wasn't totally sure about it, is that Java applications can actually manipulate the page that they're on
and, like, screw around with the DOM.
So I don't know.
There's got to be some type of security application there.
Like, can a Java applet, like, dynamically create JavaScript that does, you know, scary things,
like posting to your home and doing weird stuff like that, you know, cross-site scripting, whatever?
I don't know that either, but I know that definitely Java can, you know, mess around with the DOM
and, like, turn check boxes on and off and do scary things.
So if anybody knows the answer to that question, we should write in and let them know.
Or, yeah, if it can just, if it can do that kind of thing, I mean, you could have a trigger waiting for a certain event
in JavaScript, waiting for a Java applet to do something.
I don't know.
Anyway, now that I understand a lot of this, now a bunch of questions are coming to my head,
and these are probably, you know, people that know Java really well from a security side
probably already know a lot of this too.
So please, by all means, email me, because now I'm, I can't believe I'm going to say this not there.
You might have to fly down here and kill me, but I actually think I'm starting to get interested in Java now.
Yeah, Java's the best language ever.
Whoa, okay, now let's not go all crazy now.
Armageddon, Armageddon!
Let's not, let's keep, let's keep this.
It's the best language ever.
You know what, right now, for me, it's the best language that I'm using, to tell you the truth.
But, uh, but it's really neat to, to program in, and I think, uh, I think it keeps, keeps things running smoothly on my side.
Yeah, it really, no, joking aside, I really am becoming more interested.
I understand a little bit more about it now.
So, uh, let's see.
You drank the Kool-Aid.
I took the red pill, or was it the blue pill?
Whatever.
I don't know.
Um, when people complain that it's slow, I always think of this, this fun exception.
Jake 2, a Quake 2 port.
Check out its benchmark comparison against C.
Uh, and he gives a URL.
I'm not going to read it on the air.
Uh, we'll try to put it in the show notes, if we ever get those up to.
Finally, for a convenient reference, here are API docs and monolithic CHM help files.
And once again, I'll try to put that up in the, uh, show notes as well, because it's kind of a long URL.
And I'm lazy, and we're running out of time.
Can you believe we're, like, well over halfway through the show, 40 plus minutes into the show,
and we're only in a second email?
Yeah, that's pretty big.
Yeah, but you know what?
The second email was really good, that's why.
Exactly.
Vati, not only do you win the Email of the Week award so far, and I still got some more coming up,
but since this is the only episode this month, that means by default you win the Email of the Month award.
And quite possibly, this was a good email.
It answered a lot of questions, it explained a lot of things.
Um, maybe the Email of the Year award so far.
What do you think of that?
Whoa.
We don't really have such awards or anything, but I'm making it up right now.
So, uh, let's move on to another long email about Java.
This email is from Pixel.
Pixel says,
ThankDog and co-host.
Regarding episode 192,
wow, is this back on 192?
We're only on 195 now?
Boy, we are not very fast.
Um, I wanted to help clarify a few of your Java questions.
Please do.
There are three flavors of Java, J2SE, J2ME, and J2EE.
Actually, the two has been dropped with the release of Java 5 and 6.
Oh yeah, that's going to clear things up.
Let's just start fucking dropping numbers, renaming shit even further.
That'll always clear things up.
Clear as mud.
Alright, whatever.
J2SE is the standard edition that allows you to create command line applications and GUI applications.
J2ME is a micro edition targeted at mobile devices.
J2ME is a set of standards for defining additions to the standard edition to allow certain mobile-specific functionality,
such as mobile phone camera access, sending SMS messages, etc.
It is more or less the equivalent to installing the Windows Mobile Smartphone SDK on top of standard .NET.
Alright, so I, okay, Armageddon, hold on, I got a question.
Okay.
I thought on cell phones, and you might know this, I thought on cell phones that all this played in its own sandbox and could not, in fact, access things like sending SMS messages.
No, no, no, no, no, no, no.
Actually, you're going to love this.
Oh, no.
There are extensions for cell phones that let them access different functionality on even, like, different model phones.
So you could have one phone that has a GPS and another phone doesn't, but has some, like, assisted GPS where the cell phone network can tell it where it is and all kinds of stuff like that.
So they have standard, this is semi-standardized called some of these things, and I think they're called JSRs.
I don't know what JSR stands for, but, like, if you Google around for something like JSR 139, I don't know what 139 is, but I'm sure it'll say, like, you know, an interface to a camera phone through Java.
So it's some way that you can use Java and get to that native device hardware, but the device has the ability to limit you.
Like, you can pop up a box to the user, print the JVM, and say, do you want this application to be able to use the camera?
And you can say, yes, always, yes, once, no, this time, or no, always, you know, something like that.
So, yeah, Java applets can get to all kinds of stuff on phone, from GPS to the camera to sending text messages.
Sending text messages is very common in standard of across phones now, but those other things, not so much.
So what I just heard was never trust a Java applet on your cell phone.
Well, here's the thing.
The applets are required to prompt you about certain different things, and a lot of these JSRs, they're not accessible on the device unless your code is signed.
So if you have, let's say, a Verizon Razor phone, if you're just a regular Java developer, you can't get to the location API.
You can't, you know, have the phone figure out where it is by GPS or whatever, and then send that information out over a port and, like, spy on somebody.
You need to send your application to Verizon to get it approved.
They have to, like, check it out, make sure you're legit, and then they'll send you a signed copy back.
You can distribute to people that then has access to those APIs.
It won't just...
But that's how they try to assure you security, because, of course, everyone trusts Verizon.
So I wouldn't worry about it.
And I assume they do code review on that to make sure it's not doing anything fishy?
Actually, I think that they do.
I think there's, like, a certification process if you want to...
Specifically, if you want to use the Verizon vocation-based API, I think that there is some type of code review or some type of approval.
Maybe they give it to people who debated that, but I'm not totally sure.
But I wanted to write something that was, you know, location-aware for Verizon, and I looked at their forms.
You had to fill out all the bullshit you had to go through,
and they have a policy where if somebody else has a similar application already,
that chances are they're not going to grant you the ability to write a similar application,
because Lord knows you couldn't have two applications that did similar things,
but one was better than the other.
So, yeah, there is some form of certification and some pseudo-guarantee that the application is not going to, you know,
go crazy and insult you.
And there's no way to install unsigned applications?
It won't just pop up a dialogue like it does when you try to install certain Windows plug-ins,
saying it hasn't passed Microsoft Authent certification, warning, warning,
and you say, yeah, install anyway?
It was not going to allow me to do that?
You know, I'm not totally sure.
There may be hacks to do that, or maybe certain, like, maybe Sprint will let you do that,
but maybe not Verizon.
And I'm not sure how that portion of the security model works.
But I'm sure somebody out there does, and hopefully they'll email us, but it's not.
And we'll get to it in another month or two.
Yeah.
Okay, so let's see.
I left off J2ME.
J2EE is the Enterprise Edition and provides a set of standards for Enterprise features,
including web servlets, message queues, and clustered features.
Okay.
J2SE is created by Sun, and obviously I'm back reading the email here from Pixel,
in case you didn't figure that out.
J2SE is created by Sun.
J2ME and J2EE are implemented by other vendors on top of J2SE to provide specific installations.
For example, Nokia mobile phones have a Nokia implementation of J2ME written for their hardware.
Oh, that's interesting.
Any application which is written to the standard will run on any of the appropriate platforms.
There are some issues with J2ME, but these mostly relate to the different screen resolutions of different devices.
For example, a web application written to standard will run on either Tomcat or Jetty web servers on Linux, Windows, Solaris, or even Mac.
A simple J2ME application would run on a Nokia or Sony Ericsson mobile phone.
Obviously, this is broken when you start including vendor-specific code, but this practice is only really common with J2ME.
And that's kind of what I was alluding to about Java applets in general and vendor-specific code.
In this case, he's talking about cell phones in the ME environment.
But the same potential exists or does not exist in the PC environment.
Like I said earlier, if you've got external third-party libraries that you can buy or something like that, won't the same situation come up?
Or support for PC hardware, drivers, things like that?
I mean, does it use – see, we're probably getting into way too many nuts and bolts details of it at this point, though.
So maybe I should just back off those questions for another day.
If you're looking – if your question – I'm not totally clear on what you're asking, but if you're asking,
is there a way for a Java applet or application or something like that to get to, like, hardware-specific functionality on your PC,
like maybe access some type of USB device?
Yes, there is, actually.
Right.
And would that – if you use those – and it's not part of the standard API – if you use those on Windows,
they're not necessarily going to port over.
So not theory, obviously, just got dropped.
So I'm going to keep talking and wait for him to call back in or hope that he calls back in.
And then I'm probably going to have to repeat all of this to him when he does call back in.
So let's see how long I can stall and keep the show going and hear my wonderful, wonderful redneck voice
before we get the Yankee back on the phone.
Hey, what's up?
I am on the beautiful New York State subway, and I just got cut off at mile marker 117.
So I'll remember it next time.
117, it says bye.
There you go.
All right.
Well, I was just talking and saying that, you know, if there are drivers or whatever to interface with a USB device
or whatever you talked about, they would work in Windows, but they would or would not necessarily work
if you wanted to port that same Java applet over to Linux.
I would think that they wouldn't because the way Windows interfaces with devices is different
than the way that Linux interfaces with devices.
So therefore, I would think that that makes your code immediately non-portable.
Well, hold on a second.
Okay.
I forgot exactly where I saw this, but I think it was Microsoft Robotics.
If you Google Microsoft Robotics, I believe they have a board that you can hook up to your PC
that has like, you know, 10 relays or something on it as you control different devices.
Now, you can program this thing in C Sharp or Visual Basic.net or whatever,
but they actually also have Java support for it too, which confused me.
I was like, okay, USB piece of hardware that's got some weird stuff all over it.
How does that fit Java?
Well, they wrote drivers for Windows and they wrote drivers for Linux,
and there's this thing called JNI, which is the Java Native Interface,
which is basically a way that Java can have an interface on Windows, on DLL,
or on linuxa.so file.
So the thing is, your application's always talking to that JNI object,
so it doesn't care whether it's on Windows or Linux.
Your application is portable.
You just need to have that DLL or SO on the machine and that JNI library to do it.
So you do need, there is like kind of like a middleware piece that connects them,
that connects Java to the driver, but as long as you have that,
the actual application that you deploy doesn't change at all.
So it's a piece of middleware.
It's another, basically a plug-in or another part of the virtual machine.
It's another virtual machine, or it's, you have to have the libraries.
And that's why I was saying earlier about can't those be packaged into the JAR files
so you don't have to deliver or expect people to have those extra things.
I don't think that those can be packaged into the JAR files because, again,
I think for security reasons they don't want you to be able to distribute something to somebody.
Like the whole point of Java is that you're sandboxed.
So unless the person wants to go out of their way to install this library that can get direct access
to their USB hardware, you're not going to be able to get to it.
So I think that in that case you wouldn't be able to do that to install that create your JAR file.
I think that makes sense, though.
Like if you want to get to the hardware, there's got to be,
there has to be some type of connection for you to get from this protected language to, you know,
C or whatever the drivers have to do.
That I'm fine with it.
I think that's okay.
Well, especially that makes sense, and that goes back to what he was saying in the email about for mobile environments,
yeah, you have to have the stuff from Nokia to access their hardware, et cetera.
So that makes perfect sense, yeah.
All right, we are never going to get through, we're not even going to get through the emails,
let alone the main topic.
So I'm going to try to read faster and not stop every five seconds, Armageddon.
Armageddon.
All right, let's see.
When talking about Java, everyone gets hung up on the virtual machine.
While it is true that you have to download and install a Java virtual machine in order to run any Java application,
you also have to install the .NET framework to run a .NET application.
I think we said that before.
.NET uses the CLR, or Common Language Runtime,
which executes the .NET equivalent to Java bytecode on the system.
This is how .NET code can be written in C Sharp or VB.NET and even run on Linux using Mono.
The same goes for pre- .NET VB days when you need the Visual Basic Runtime files installed.
Absolutely, I don't think we mentioned Visual Basic, but we have absolutely the same thing.
To run a J2EE application, you don't use a J2EE virtual machine.
You use the standard virtual machine, the J2EE container, e.g. Tomcat, such as Comcat,
which will have the J2EE libraries.
It is even possible to get microchips with Java virtual machines on them,
allowing them to execute Java at a hardware level for embedded systems.
For example, the IMSYSNAP model, TinyURL36QEQD, is a tiny embedded system like the Gumsticks,
G-U-M-S-T-I-X.com, which runs native Java.
I've got to tell everybody, by the way, if you haven't seen the Gumsticks platform before,
I used it a little bit in my last job.
It is really cool.
It's pretty cheap, and it's got a decent amount of functionality, and they're pretty damn reliable.
So I think it's like $99, and there's like a $50 add-on sound card, stuff like that.
If you want to play with an extended Linux device cheaply, that's the way to do it.
Another one is BlackSpan.
If you Google BlackSpan, you'll see it.
But like this guy was talking about, there is hardware out there that implements Java natively,
and one of them is called the JSTAMP.
There's a company called Parallax.
They make a basic stamp that runs basic, but they make a JSTAMP, I believe, that runs Java as well.
And I think it's decently fast.
So Java isn't just for these big slow business apps.
Like, you can really do a better program with it now, and it runs just fine.
Cool.
Let's see.
Any class in Java extends from the base object.
A Java bean is simply a Java object, which contains strings, numbers, and other objects,
which meets the bean specification of having get and set methods for all its public variables.
Ah.
Interesting.
I did not know that.
You know, because I've asked a lot of people, what in the world is a bean?
And nobody can really tell me.
It sounds like it's just a predetermined specification, and if it falls within those parameters, it's called a bean?
It's just a label?
Well, I mean, it sounds to me like maybe something that's considered a bean has no publicly accessible data members
except through, like, get and set method.
So if you had, like, an elevator object, you could have, like, a get floor instead of accessing, like, you know, elevator.floor directly,
something like that.
So everything is wrapped behind one of those functions.
So that's what it sounds like to me, but I could be wrong.
Well, and that's something that, again, I would expect the IDE to have if I tell it,
okay, I know in advance the application that I'm developing,
and I know it to fit within the limitations of a quote-unquote bean.
So I would think that there would be a way for it to make it easier for me to develop that by limiting
or helping me get started writing something that falls within those bean restricted functionality.
Yeah, I don't know that Eclipse does that, but Eclipse does make, you know,
writing, like, getters and setters like that a lot easier.
Like, you can just define all of your variables, and you can tell it generates all the getters and setters for me,
and it just goes off because it writes a lot of code for you.
So Eclipse is kind of there, and I guess if this really is conforming to the bean standard,
Eclipse is kind of there and doing it all for you.
But I'm sure that, you know, maybe there's some plug-in that I don't have that really does take care of all that.
Okay, let's see.
An applet, let's see, did we do that?
A class, a Java bean.
Okay, an applet is deployable Java application designed to run client-side in a web browser
and has a restricted functionality for security purpose.
A servlet is a Java application designed solely to run inside a web server.
I think we did get those right.
While it is possible to use JSPs, JSPs, JSPs, JSPs in the same way as ASP,
with code included in, quote, scriptlets.
Oh, yeah, great, another Java term, just what we needed.
This is not the preferred behavior.
The normal method is to have a servlet, which performs all the logic of an application
and then calls a JSP, which will format and display this information.
This is similar to the .NET method of, quote, code behind,
where the ASPX page calls a DLL to perform business logic,
but from a, quote, code in front method.
Now, I'm not familiar with those terms in relation to .NET,
but that makes sense to me, so.
JBoss, WebSphere, and WebLogic are all Java application servers,
which implement the complete J2EE specification,
whereas Tomcat and Jetty are web servers
and only implement the more basic web-based parts of the J2EE specification.
For hosting a web application, JBoss and the others are seriously overkill
and only really necessary,
where the web presents a small proportion of your application requirements.
By the way, JBoss was bought by Red Hat about 12 months ago.
Thanks for the excellent show, Pixel.
Okay.
Another good email.
Yeah, definitely.
I learned a lot more from that one, too.
Thank you, Pixel.
Excellent show because you guys are writing in great emails,
and, you know, once again, this show is about us learning a lot of this stuff, too,
you know, and opening the dialogue with people out there
that definitely have more, obviously have more experience and knowledge
in a certain subject matter,
and this is definitely one of them for me.
So, that is cool.
Now, we're like an hour in.
There is another enormously long email.
I'm going to,
I'm going to try.
We're never going to get through with it,
so I'm going to read this one super fast,
and I'm probably going to skip over some parts.
So, this email from Pernikin,
I apologize.
I'm going to chop it up for the sake of time.
Let's see.
Pernikin says,
Props to the DDP for showing that hacking is about gaining knowledge
and understanding through experimentation,
not about abusing technology for personal advancement.
I've been listening to the Minerip podcast for a good while now,
and I've learned a lot.
Also, props to Stankdog and Not Theory for giving Java a chance.
Armageddon!
Oh, no, wait.
I guess we are giving Java a chance.
Actually, I give everything a chance.
I just need somebody to answer my questions.
When I say,
Why the fuck doesn't this work?
Or, Why doesn't that work?
Or, Why is this happening?
And no one can ever explain it to me.
Then, yeah, I have a tendency to dismiss Java and say,
Look, nobody seems to know what the hell Java is all about.
So, yeah, I kind of get frustrated and dismiss it.
So, I'm glad we did bring this back up.
Let's see.
Now, he asked the audience to write in and explain some of the main ideas.
I've been programming Java for about five years.
It's professional and it's a hobby.
First of all, the word Java is used as a sort of universal moniker that can cause a lot of confusion for newcomers.
When someone says Java, they can be referring to at least one of three things.
One, the Java language.
Okay.
I understand the difference.
Java API, which depends on your platform.
I'll explain below.
And the Java virtual machine.
And we talked about all of them earlier in the show.
So, let me skim through some of this because we've already clarified those three separate portions.
Which I'm glad, him breaking it down is very good too though.
So, the Java language refers to the actual language, etc.
On the show, you talk about the Java object class.
This is kind of a technicality, but the base Java class, the object class, serves as a super class for all object types defined in Java.
And it has a number of public methods.
Every object type or class in Java inherits these methods.
And they choose to override some subset of them.
I think that's getting into some detail about Java coding.
And I'm going to have to, we don't have time to go into that, unfortunately.
Without getting into the details of object-oriented program, here are some differences between Java and C++.
Which most BinRev listeners are probably familiar with.
One, Java is type safe.
Java is strongly object-oriented.
All user-defined data types are derivatives of the object class.
We just said that.
There's some built-in language support for multi-threaded applications.
Better exception handling.
And garbage collection, which you talked about earlier as well.
And he puts in parentheses, which is actually implemented in the virtual machine, but the language assumes that garbage collection occurs.
So, we did mention that earlier.
Right.
Okay, the second, the Java API refers to the library of classes that are available for the programmer to work with in the Java language.
Again, sorry to chop up your email, but we did talk about that a little bit earlier.
And that's where we talked about using the standard APIs that come with it to do just about anything you want to do.
And it sounds like, from what I've heard from everybody, that they'll do just about anything you want.
If you're going outside of that standard API, you're doing something different and unusual where you have to use these other things, like the Nokia development kit or whatever specific thing you're doing.
You're going to need something on top of that.
But generally speaking, it sounds like it's got quite a bit of the base stuff with it.
If you want to write for your mobile device, you're going to have support for that.
Okay, yeah, we just kind of alluded to that.
As not theory put it, J2EE is for building huge bloated enterprise apps.
And I'm still not sure what a Java bean is.
Well, guess what?
Now you know.
So, see, we're all learning, see, as we go along here.
The third thing that people use the word Java for is the Java virtual machine.
Again, sorry, we talked about that.
Actually, no, I'm going to read this because he's got some things in here I think he's more clear about.
Java is, in theory, right, once run everywhere, which is definitely an overstatement.
See, here's an experienced Java person admitting and agreeing with me.
It's an overstatement.
It uses a software interpreter program called the virtual machine to allow cross-platform support.
Basically, Java code is written to run in the virtual machine, which handles all or at least a lot of the platform-specific details.
When one compiles a Java program, the Java source code is compiled into an inter...
And this is important.
When one compiles a Java program, the Java source code is compiled into an intermediate format called bytecode,
which is in turn executed by the virtual machine.
The idea is that by writing a program in the Java language using the Java APIs for that platform,
it can be run on any platform device that has the virtual machine software installed.
There are many virtual machines available, but the most popular is Sun's Hotspot JVM,
but that's not to say that it's the best.
Okay.
I don't...
You know what I forgot to do?
I forgot to get on my iced tea before we did the show,
so my voice is starting to get out here a little bit.
Don't forget, you can scream at Armageddon at any time, even though I'm going quickly.
No, I didn't want to interrupt you, so...
Okay.
Also, you touched on this in the show, but Java is useful for more than just web stuff.
Yep, we did talk about that.
Applet, Servlets, JSP, we just went through that, unfortunately.
Gosh, I hate...
This guy's...
He wrote a long email.
I might post this in the forums or something, because it's got a lot of great stuff,
where he breaks down the differences between applets and servlets and JSP,
but I think we were right about that the first time.
I think when we talked about all of them, we were pretty accurate with that,
and we've confirmed that, so I'm going to skip that.
The last thing he mentions here is, going back to write once, run anywhere.
Java is very far from being entirely cross-platform.
The quote, write once, run anywhere, quote, end quote,
is completely impossible to achieve on the breadth of platforms that Java supports.
And that's all I've ever said.
I wasn't dismissing it.
When I say that statement, I'm just saying, let's be truthful.
It's write once, run in a lot of places, but not quite anywhere.
That's what I think I should say.
That's true.
Run most anywhere.
Run most places.
Of course, you're not going to be able to write software for your Linux box that runs on your phone,
but if you wanted to write a graphical application that runs on both Linux and Windows,
you can do so with Java.
This is why I first got into Java for my personal projects,
because I didn't want my programs to be limited to just Windows or Linux.
Of course, very admirable, you know, what it's attempted to do, very admirable idea, just not quite delivered.
Java offered me a way to do that.
Sure, you have to download and install a virtual machine.
Big deal.
And, yeah, I agree with that, too.
Big deal.
You have to have an operating system with properly installed drivers on your computer for other software to run,
and this is obviously commonly accepted.
Oh, wait a minute.
No, holy crap.
I got...
Yeah, okay.
I didn't...
I thought I skipped a sentence there, but no.
I agree with that completely.
So, let me...
In case I came across wrong before, it's not a big deal.
I'm not saying it's a problem.
I'm just saying that people need to understand that you do have to go out of your way to do some installation
and to do prepare your environment a lot.
I'm not saying it's bad or wrong.
I'm just saying let's not forget to make that point when we talk about how great Java is
that you do have to do a lot of setup work.
We also mentioned on that last show that you'd have to do the same thing for .NET.
I'm not naive.
I'm not saying it's better, worse, different than anything else.
It's the same.
It's similar to everything else as far as that goes.
Last paragraph here.
But the write-once-run-anywhere idea breaks down for another reason.
Even if there is a flawless virtual machine available for every Java platform,
which perfectly implements the Java API for that platform,
it's still hard to make your own code cross-platform.
A lot of the shortcuts that you might want to take won't work well in every environment,
and that limits the portability of your code as well.
But in my experience, Java satisfies my niche requirement of cross-platformity between Windows and Linux quite well.
Anyway, I guess this turned into a long email.
Gee, I think.
And I skipped most of it.
But I hope it helped explain some more about Java.
I really dig this show.
Another great email.
Wow, this is probably the best email show we've ever had.
So, Pernikin, big shouts out to you.
Great email.
Sorry I had to jump through quite a bit of it.
But I might have to put this up in the forums if you don't mind.
Or maybe I'll ask you to post it in the forums.
That way you're inherently giving permission to post it there.
Anyway, let's see.
How are we on time here?
We did have a couple other emails.
I'm going to skip over those because I think we've beaten Java to death for this episode.
So, that's definitely our main topic.
Ended up being Java, the redux, redux, redo, whatever.
I've heard it.
Let's see.
We'll do a couple quick emails since we have a little bit of time here.
An email from Iron Geek.
Iron Geek says,
Hi, stank-a-dank-a-dee-dank.
And co-host.
One caveat to the asking about a person's accent.
To try to endear yourself to them while S-E-ing.
So, he's referring to the social engineering episode we did last, well, last month, I guess.
I can't say last week.
Last episode.
Sometimes an accent isn't really an accent.
It's a speech impediment.
I have people ask me all the time where I'm from.
My buddy says I should tell women I'm from Latveria.
Keep up the good work.
And he has a link to Wikipedia.
You can go to Wikipedia and look up Latveria.
But, of course, Latveria is the home of Dr. Doom himself.
So, I don't know.
If I lived in Latveria, I'd have to kick Dr. Doom's ass and take the place over.
But that's just me.
You ever been to Latveria?
I've never even heard of it.
That's because it's fictional.
I know that, but you've obviously heard of it.
I was wishing you would say yes.
That would have been cool.
But, no, you can't play along with the joke.
You've got to be difficult.
Why do I ever have you on the show?
I swear to God.
I should just hang up on you right now.
Wait a second.
We're on the show.
Actually, it would have been funny there if you would have hung up on me.
Okay, but don't do it now.
Okay, we're almost done.
Here we go.
Next email comes from CyberPig.
CyberPig says,
Been listening to BinRev for a while now and enjoy the show.
I'm listening to episode 194 about social engineering.
And a question popped into my head.
How does one know they're being socially engineered and to counter it?
P.S., in case someone hasn't told you,
the reference to LAMO was connected to the government-run computer forensic school
in Hoover, Alabama in episode 193.
I was wondering where the hell that came from.
So, thanks for letting me know that, CyberPig.
How do you know?
Not theory.
I'll let you feel that one.
How do you know that you're being social engineered?
Well, here's the thing.
I can't ever be sure that I'm being social engineered, so I have a tactic.
Anyone that I'm talking to, I lie about everything just in case.
Just in case.
That way, if they can social engineering, they're all they want.
They're never going to get the truth out.
Well?
It's, you know, it's obviously, it's hard to tell somebody who's social engineering,
because that's the whole point.
Like, they don't want you to tell.
I actually do have a trick for this.
I have a great trick that works for me every time.
I carry with me at all times, no matter where I am, at all times of the day,
whether I'm in my car, I'm in the office,
I carry with me a small cactus.
And any time I'm talking to people, and I think they might be lying,
I just look at them and I go, cactus, cactus?
And if they're telling a lie...
All right, look, I'm giving a little shout out there.
Shut up.
All right, next email.
The answer is, you're right.
You can't know whether you're being social engineered.
It's just a skill.
I mean, it's just like, can you ever tell that you're being lied to?
And if somebody's really good at it, it's harder to detect.
The way to find out is to always question them.
Don't let them use some of those techniques.
If they're asking, if they're giving you vague responses or evasive in their answers,
press a little bit harder.
Don't be afraid and don't give up.
Don't be lazy.
A lot of times it's to your laziness you get tired of being asked questions.
And I even mentioned that as a tactic to wear people down until they finally give up and don't care anymore.
Don't let that happen to you.
And yeah, it's just a feeling.
It's just something you have to be able to tell and to have in you.
So I really wish there was something easier to tell you how to detect it.
The only answer I can say is to be thorough and ask a lot of questions.
Make sure you ask enough questions so that you're comfortable.
And now I have the hiccups at the end of the episode.
That's going to be great.
All right, perfect.
This is good radio.
My voice is giving away.
I have the hiccups.
I'm talking really fast.
And we haven't had phone sex or yet, so.
Why don't you cry about it?
I just might.
I'm going to wait until I get off the air, though.
I'm not.
I promised myself I wouldn't do this on the show.
I'm getting perclept.
Okay, it's fine.
Next email comes from Crate.
Crate says, okay, what the hell happened to episode 193?
Is this the Children of BinRev episode?
Actually, I quite enjoyed it and found it a refreshing reprieve from Stank's random innuendo,
proving once again that Stank really is a dirty old man.
I resent that fact.
I am.
No, I guess I exactly am a dirty old man.
Everyone did a great job.
I laughed.
I had fun.
And I learned, as I'm sure others did, wonderful job.
So shout outs to everybody who helped out on episode 193.
People did enjoy that.
So good to hear some props every once in a while.
Everybody likes to hear that somebody listened to and appreciated their work.
So I will second that email from Crate.
And let's see.
Two more emails.
Next email from DJ Mollisk.
DJ Mollisk says, while listening to episode 194, Social Engineering, I had a BinRevgasm.
Um, okay.
All right.
I've been waiting for the topic of what is social engineering to be addressed.
Back in the days of Radio Freak America, there was an episode where this was discussed.
Rax, who I have respect for, gave one of the most horrible responses, and that has stuck with me.
Rax said that social engineering was a fancy euphemism for lying.
Armageddon.
Okay, let me interrupt.
I agree with you completely, and Rax saying that, and he and I would argue about that off the show all the time,
and he'd always make jokes about that's all it was, and I always hated that,
so it's another reason I wanted to do that episode.
So I feel you on that one.
I noticed on episode 194 that things started to go in that direction as well,
putting social engineering in the bed with lying.
You can use social engineering without lying.
I think we purposely tried to emphasize that.
My whole thing was about social engineering with integrity.
You do not have to sell yourself out and completely lie.
You can tell someone the truth, but adjust the way you speak so that the person thinks it's a lie.
Also, if you break it down, social engineering really is just using psychology.
Absolutely, there are aspects of it for sure.
Anticipating the response of others based on your actions.
Once you break it down like that, it should be clear that social engineering is used everyone,
everywhere, I think he means to say, with everyone.
It is just part of our psychological defense system.
Just because hackers can use it and use it to their means doesn't make it a hacker qualifier.
So, thank you, DJ Mollusk.
I don't think there's really anything more to say to that.
And our last email this week is actually, this is actually an email from the future, not theory.
This is actually kind of interesting.
This email comes from King Vegeta.
King Vegeta, I think it's pronounced Vegeta, I remember.
King Vegeta, who says, in response to episode 220.
Dear Stank, I'm writing to you in response to the piece of shit episode 220.
That sucked, man.
Your rants on how you prefer latex to rubber and butt plugs instead of cock pumps were sick.
You are a perverted man.
I will never listen to your show again.
Note, this message is from the future.
So, I guess we have to adjust.
We actually had planned ahead for episode 220.
It was going to be called the butt plug episode.
And I guess, should we change that and risk changing the future?
You know, if you kill a butterfly in the past, should we risk changing the topic for 220 now in advance, now that he's told us?
Has he killed the butterfly and doomed us for all eternity?
Or, are we now committed that we have to absolutely do episode 220, and it has to be about latex versus rubber and butt plugs and cock pumps, so we don't change the course of time?
That's a lot of pressure to put on me, man.
I'm just trying to do a radio show.
Well, I just hope that we're forced to do that episode.
It sounds like a great one.
We might just do that one next week, Mr. Man.
We might do that off the air.
We might do that as soon as we stop recording in about five more minutes.
Okay.
So, yeah, well, one thanks.
Back to the future you, by the way, King Vegeta.
Thanks for the handjob.
I appreciate that.
That worked out really well.
And also, I've got to ask, though.
I guess sometime between now and episode 220, he changes from Prince Vegeta to King Vegeta.
So, there's, somebody's kicking the bucket between now and 220, so I'm not sure what the backstory to that is, but he's King Vegeta in this email, and previous emails were, I think, Prince Vegeta.
But, if he's the king, then, actually, I guess I should ask him, I wonder how I'm doing in my future position as supreme ruler of the universe.
Because I'm hoping that by episode 220, I should be ruling with an iron fist.
So, I guess let us know how that works out in the future, King Vegeta, if you do feel the need to write back.
So, that's going to wrap up the show for this week.
Let's see.
No main topic.
I guess that was our main topic, like I said before, so we'll bump this topic for a future episode.
And I won't even say what it was, so how do you like that?
Shouts for this week.
I'll go ahead and give my shouts to all the people who emailed us earlier.
Great emails.
Probably the best email content show we've had in almost four complete seasons now that we're coming up on the end of our fourth season.
Probably the best email episode we've ever had from day one.
So, my shouts go to our listeners, one and all.
Even if I didn't read your email on the show, you guys are giving a lot of great feedback, and I'm learning from the show every week as well, and that's why I enjoy doing it.
What kind of shouts you got there, buddy?
I got shouts to the people I got feedback from, Thorpe Freaker and the other guy whose handle I can't remember because it's too long, and Rigel.
I haven't talked to Rigel in a while until this week, but caught up with him a bit.
Seems to be doing well.
I'll give some shouts to Decoder.
I haven't done that on the air in a while.
We talked a couple days ago.
We talk once in a while.
Shouts to Decoder.
You know what?
Shouts to Rosebud.
Pass some shouts on to Rosebud for me, will you?
All right.
And let's see.
Hosting for Binary Revolution Radio is provided by caro.net.
So, if you need hosting managed or otherwise, check them out.
We appreciate them providing our bandwidth and hosting.
Site of the week for this week is streetviewer.com.
That's S-T-R-E-E-T-V-I-E-W-R.com.
That's not W-E-R.
That's V-I-E-W-R.com.
And that is some pretty interesting pictures that people have found using that new Google
Streets functionality Google added to Google Maps where you can actually see what it looks
like from the street level.
You can look at buildings and people on the sidewalks and stuff.
And they actually captured some pretty interesting things that they probably didn't mean to
or realize and didn't catch in the editing process if there was one.
So, a lot of people have found some pretty funny pictures.
So, go check that out.
And by all means, share any other ones you may find.
And, let's see, email us feedback of any kind to radio at binrev.com or you can contact
nottheory directly at ntheory at bellsmind.net.
So, if you have any feedback for Bell's Mind, as he said earlier, he only checks the forums,
what, once a week, a couple times a week these days?
Maybe twice a week at this point.
Not the best place to get in contact with him.
Email him if it's something about Bell's Mind.
Don't let it be down for a week and not tell him about it.
How many times have I called you and you're like, how long has it been down?
No one has told you anything.
Yeah, that's been quite a few times.
Yep.
And then we have phone sex until 3 a.m.
Closing music this week is from, I don't think I've used this before.
If I have, well, you're getting it again.
This is from Emergency Pizza Party.
This is actually a local, local to me here in Orlando or near,
I think they're in the Orlando slash Tampa area, local nerdcore group, if you will.
Emergency Pizza Party, the, well, the name I have on here is GAL.
I don't know if that's an acronym or initials for something,
but that's the closing track for this week.
And, not theory, we are running out of time.
We've got a couple minutes.
You got anything else?
You got any words of wisdom to impart?
I've kind of been talking over the whole second half of the episode trying to pound this through.
So, what else you got for us?
Anything good?
No.
No, I'm just drained on the shell of my former self.
There's nothing left to me.
You want to sing Baby, Baby, Baby, I'm a Hacksaw?
Baby, Baby, Baby, I'm a Hacksaw.
How about Lollipra?
You're good.
You want to sing Lollipra?
There's songs in that.
I got Lollipra on.
You want to sing Lollipra on with me?
Maybe we'll save that for the...
Come on, sing it with me.
Grow a pair.
Let's go.
We're going to sing.
Ready?
One, two, three.
Lollipra on, Lollipra on, oh, Lolli, Lolli, Lolli, Lollipra on.
Oh, that makes it gross, though, the popping sound.
Yeah, well, gross, hot, whatever you want to say.
Gross, sexy, you know, whatever floats your boat.
Seriously.
How's that for a meme?
Am I going to have everybody across the global interweb singing Lollipra on now?
I sure hope so.
I hope so, too.
Please send in your renditions to RadioFinRev.com.
And that is going to do it for us this week, possibly this month, this year.
I don't know when we'll do another episode.
We'll try to get one out next week.
But if we don't, we will see you sometime in the near future.
Same hack time.
Same hack channel.
Lollipra on.
Your music is poop.
We're wrapping the poop.
Benjamin Bear, why do you hate nerdcore?
Benjamin Bear, he's covered in cold sores.
Well, if you don't like it, listen to the track.
Don't be flippin' on me, cause my music is whack.
I didn't know that I was so disliked.
Maybe I should just put down the mic.
Benjamin Bear, you need to get a life.
Benjamin Bear, you're a big fat jerk.
When you spit your shit, the microphone gets covered in turns.
Everybody on the BBS knows you suck.
And stop feelin' up on my boyfriend's butt.
It's time for you to get a life that you don't care.
Cause you're gettin' more plays than the average bear.
Put your panties back on, we don't wanna see that.
Don't flaunt that red-haired baby rap.
Why you got me spittin' on this?
Benjamin Bear sounds like a bitch.
Skip this track, I'd rather smoke crack.
Compare me, yeah, that's fair.
110% better than B-Bear.
I'm the one that brings the flair.
Benjamin Bear, I hit and miss.
I'd rather drink a jar of piss.
Your music is poop.
We're wrapping the poop.
Benjamin Bear, why do you hate nerdcore?
Benjamin Bear, he's covered in cold sores.
Well, if you don't like it, listen to the track.
Don't be flippin' on me, cause my music is whack.
I didn't know that I was so disliked.
Maybe I should just put down my mic.
Benjamin Bear, you need to get a life.
Yo, B-Bear, time to make you a bitch.
Red hair, so we burn you like a witch.
You got a smaller dick than any bear should.
This track gives both feet the end.
Shellwood, oh, does it burn?
Does it sting?
Does it hurt?
All the good stuff and darks.
I came from rain thirst.
Does a bear shit in the woods?
You might ask.
Nah, B-Bear, he shits on the track.
Benjamin Bear, you need to get yourself a life.
You need to stop hittin' rocks from the crack pipe.
You've been hurtin' nerdcore from day one.
Your raps are poop and your beats are dumb.
But I don't give a fuck.
All this, you don't beat all.
Look, you've been banned from the nerdcore documentary.
It's gonna be a fault if we lose a song fight.
Suck, B-Bear, you need to get a life.
Your music is poop.
We're rapping to poop.
Benjamin Bear, why do you hate nerdcore?
Benjamin Bear, he's covered in cold sores.
Well, if you don't like it, let's send the track back.
Don't be flippin' on me, cause my music is whack.
I didn't know that I was so disliked.
Maybe I should just put down the mic.
Benjamin Bear, you need to get a life.
Hangin' tops like a new kid on the block.
Benjamin Bear, he be givin' no fuck.
You're a stupid dumb cock.
You can't even make this mic rock.
Tryna bust a flow.
You're an happy ass hoe.
You blippin' us and I'm not that soul.
Don't even try to rap.
You're a nerd called Pussy, change your maxi pad.
Make way for the worst in the game.
Benjamin Bear, send it in for lame.
I got the worst rhymes and the worst beats.
Movin' a fight in the dark cold sea.
When you're back down, Ben, you know what you can't rap.
Self-enjoyin' when you rock that crap.
Everyone knows that you're the worst in the land.
Come up here right now, we're starting to jump in.
You Conan O'Brien, AB1-lookin' motherfucker.
You call yourself a bear.
Benjamin Bear, you suck.
Move an act when you rock that crap.
Thank you.