Java Programming Tutorial - Unit 1 - Hello World!

You've probably already seen this little "hello, world" thing somewhere on the Internet.  It is the most popular phrase to write to the display when learning a new programming language and has been around since the 70's.

Before we start heading into the development part of this unit, we shall install what is known as the Java Development Kit (JDK).  The JDK is an excellent set of of tools that includes compilers, runtimes, libraries - a lot of tools and buzzwords.  It's enough to know that it is necessary if you plan on programming in Java.

Installing the JDK

A explained in Unit 0, the JDK is compiled for every platform and architecture.  As a result, you'll have to select the JDK for your system.  I would assume you are running Windows, but I'll also consider Linux.  If this is already too much, just follow the steps which I label as for Windows (although I'd suggest you read up a bit on Operating Systems and general computing before proceeding).

Pre-flight checks

Before you go through a 100MB+ download, make sure you do not have a JDK installation already.  To check if you do, follow these steps:

On Window (or if you're unsure) press the Windows key (the flag icon on your keyboard) and R simultaneously.  The run dialog will open up and in it type cmd, which will open the console.  On Linux or UNIX systems, open the terminal as specified in your distribution (I expect you know this by now).

In your console (whether it is Windows or Linux), enter javac -version.  This is the command for the Java Compiler, so no there are no typos there.  If you get some meaningful output (i.e. a version number such as javac 1.8.0_4), then you can skip this installation part.  If you get an error on the lines of "not found", then you'll need to install the JDK.

Downloading the JDK

Selecting and download the JDK

The JDK setup is trivial; download it, and install it.  That's all there's to it.  So first of all, head to Oracle's website and select your version.  If you're totally unsure, just select Windows x86.  In case you're simply not sure if your system is 32 or 64 bit, do the following (if you system was made less than 4 years ago it's probably 64 bit):

Windows

Windows architecture

• Right-click on "Computer"
• Select "Properties"
• Under "System", the "System type" tells you whether it is 64 or 32 bit (refer to image). 

Linux/UNIX

• Open terminal;
• Type uname -i
• If it is i586, i686, or any 86, then it's 32 bit.  If it's 64 bit you'll get x64.

  

A note on Ubuntu and its derivatives

If you're working on a Ubuntu (or Mint, elementary or other derivatives) an excellent and very short guide can be found on webupd8.  I suggest following that guide for JDK on Ubuntu.

GUI Installation

Once downloaded, it is only a matter of running it and clicking next, however this setup is unfortunately bundled with unwanted software too.  So before hitting next, make sure you uncheck any field that tells you to install toolbars or whatever.  These are absolutely unnecessary and are included only for marketing.

Installed 

Now that the JDK is set up we're ready to do some work.  Despite the elaborate system, the development kit is a very simple to install.  From the installation comment, "The Java Standard Edition Development Kit includes both the runtime environment (Java Virtual Machine, Java platform classes and supporting files) and development tools (compilers, debuggers, tool libraries and other tools)" so as you see, its a great platform to work with.

Make sure everything is fine by again running javac -version.  This should print out the version number of the Java compiler.

Hello, world!

Everything is now in place and all that remains is your first class!  First what?  Java is a pure object-oriented programming language (with brand new elements of functional features since Java 8).  These are a lot of buzzwords for now, so I'll keep it simple and then elaborate on these as we go along in the series.

For now suffice it to say that everything you do in Java in contained in what is known as a class.  If you're interested, read up on object oriented programming, but for the first few units we'll keep it low.

Our first program will look like the following.  I'll explain each line afterwards.

Comments

The first thing to note is the fairly natural language in this snippet.  This is the easiest concept to grasp.  Comments in code help make your code more understandable and easy to follow.  It is of utmost importance to document your code especially when your projects get larger.  One day you'll just leave it out and when you look at your code after a month you'll regret it - so it's better to get used to it right now.

Comments can be identified by being wrapped between /* and */ (a single star, I'll explain the double ones in the code too).  Alternatively, for a single line of code, it is enough to start it with //.  Java is adamant about standard and correct coding and documentation, so much so that a particular category of comments are know as JavaDocs.  

JavaDocs are basically the multi-line documentation blocks (those between /* and */) with a very small difference and requirement.  JavaDocs have an extra * after the opening /* and are to be written in specific areas. 

After defining the other basic parts of the code, I'll go into more details on JavaDoc.  For now, it is fine to understand that we can write normal text in our code to help us understand what is happening.  Note that the compiler will ignore your comments, so complaining in code is futile :P

Class

As explained earlier, everything in Java is defined as a class.  Classes are a blueprint for an object in an object oriented system.  For now, it is not that important however it is wise too keep this in mind.  

In our case, we have just one class named HelloWorld.  You may have noted the 'public' keyword.  This will make more sense later on, so for now think of it as a requirement for your program to compile.  

In Java the file must be named as the class, so our program here must be saved to a file named HelloWorld.java.  This 'limit' actually makes thing much simpler - you don't have to remember a bunch of names for the same program.

Method

Methods are where we define functionality.  Think of this as the method in your food recipe; it tells you how to put things together to get something done.  In an object oriented system, objects (which are instances of classes, I'll explain this soon) are made up of values and methods.  Methods operate on these values to return some other value.  This concept will be explored in the next unit, however it is important to note that these values are called variables.

But let's get back to methods.  In our case we have just one method, named main, and in it we explain what to do to print our "Hello World!".  In Java a method named main is the primary starting point of the program.  Think of programs as a water hose - the main method is the point at which the water starts flowing; the origin.  This main method, though, has some extra details which we will include but will be explained later on in the series.  As you can see, we started it again with public, followed by static and finally void.  It also has a String args[] in the brackets.  Let's dissect this declaration:

• public static are keywords for the VM which will be explained later in the series
• void is the return type.  Remember from the definition we said that methods work on variables to return a value.  In some cases, there is no value returned by the method after it runs.  In those cases we say that the method does not return a value, so the declared return type is void.  Return values, etc are not important for now, but I'm mentioning the terms so you can get used to such concepts in context.
• main defines the name of method.  For now it is best to use unique names, however as we'll see later on, we can use duplicate names with some limits.  You'll use the name to call the method.
• (String args[]) is defining the method as taking one parameter or argument.  Arguments are given to your method when it is called.  In the recipe book, think of it as the book instructing you to put 100g of flour in the bowl.  The 100g is a parameter to the method "put flour".  This defines context and extra information for the method to work on.  The method can access the parameter as if it were a variable.

System.out.println 

This might seem a bit complex but let's analyse it like we did for the main.  It is good to go over this again later on after we cover more topics, so you can better 'get it'.  It is OK and expected that you will not understand the specifics right away.  However, we shall go through the line:

• System is a class, just like our very own HelloWorld.  This class is provided with Java, so we did not have to write it.  There are various methods and variables in this class.
• out is a variable, or member, defined in the class System.  It is not important to know the specifics, but the name is indicative enough as pointing to the output of the program.  So up till now we accesses the output of our program from the System class.  Note that a variable can also be another class.  What you need to recall now is that a variable is an instance of a class (i.e. an object, whereas the class is the type of the variable).
• println is, finally, a method inside the out class.  This is the one which does the writing, and as you can see, we gave it a parameter, which is the text to write.

As I said, try to get the idea, but for now we'll keep it very simple and it is enough to know that System.out.println("my text"); will print "my text" to the output.

Structure Summary

So let's wrap this up after which we'll compile and run our hello world!  

Recall that in Java everything is a class.  Each class defines methods and variables (we haven't used these yet).  Variables can be other classes too.  When we create an instance of the class (which we haven't yet neither), it is known as an object.

In our basic case, we have just one class named HelloWorld with a single method named main.  Here's the pattern now: the JVM is calling HelloWorld.main().  It does this behind the scenes and as you can see it is identical to the way in which we called System.out.println().  The pattern is <class><dot><method>.  It is possible and normal to have multiple classes in one call, such as the System.out.println, which has two classes.

Going back to the JavaDoc, you can now see how the @param args is referring to the parameter passed to main.  So what we are doing in JavaDoc is explain the use of each parameter in a method.  Note also how the JavaDoc blocks are explaining the building blocks; the classes and the methods that we define.

Again, it is not vital to know these details yet, however as we go along they will start making a lot more sense.

Compiling

Compilation is fairly straightforward in Java.  Let's go back again on this process as explained in Unit 0.  Compilation in Java converts our code into byte code.  We'll use javac to accomplish this, after which we will run it using the java command which will fire up a JVM to execute the byte code.

So, in order to compile, open up your console or terminal and navigate to the directory which contains your HelloWorld.java.  For example if it is at C:\Users\james\mycode, enter cd C:\Users\james\mycode.  The same goes for Linux and UNIX systems.

Once inside the directory, enter javac HelloWorld.java

This will not do much other than compile your code silently and that's it unless you have some compilation errors.  You should note a new file now, called HelloWorld.class.  This is not a source file now but an executable for running in the JVM.  That's all there's to compilation in Java, so now onto the best part of this unit - running the program.

Running

Running your program is even simpler than compiling it.  All you need to do, in the same directory where you have the HelloWorld.class, is enter java HelloWorld in your console.  Note that we do not add the .class extension.  We are running the class, not the file per se.

If everything went well, you should see your first code running perfectly on your system, shouting Hello World! at you!  Do not underestimate this simple code.  It's where almost everyone began.  It would be ideal to experiment a bit, that's the key for your success.  Note my explanations, but doing extra reading will help you grasp concepts which you may not have correctly understood in your first reading.

Conclusion

This is your first step in a very long and never ending journey.  Do not expect that a few years will go by and you'll be done learning.  Programming is a very active field and it is best to keep looking for new concepts, languages, methodology, etc.  But this is the vital first step.  

The code for this unit may be found on the github repository.

Soon I'll be putting up Unit 2, where we shall be going into variables and more methods.  Some text in this first hands-on unit may be disorientating for the absolute beginners, but do not give up.  In a few weeks you'll be much more proficient in Java!

Java Programming Tutorial - Unit 0 - The Basics

Unit 0?  If you're new to this world, it might seem odd, but you'll see why we start 0.  If not, well you probably might skip this post for now.

If you decided to stay and read on, then welcome to the world of computer programing, where media reports are exaggerated and computers are very dumb ;)

A brief intro to programming

Cheesy Java code

Programming is "the act of instructing computers to perform tasks".  Computers don't get it when you tell them "write text".  What they do understand however is a series of bits, which ultimately lead to the text being written.

I'm not going into the great detail about the origins of programming, however the following is a very brief overview to put you in context.

The first computer programs consisted primarily of punch-card.  These were the earliest forms of bits, holes to represent 'on' or '1' and solid wood for 'off' or '0'.  As time went by, digital valves were used and nowadays we use semiconductors and integrated chips.  The concept has remained the same though.  Writing ones and zeros is of course complex, so much so that no one has ever actually programmed in ones and zeros.  What they did do was devise a system to write meaningful text and then convert it to ones and zeros.  For example, the earliest code, in Assembly Language, would have looked like this

It is complicated, unless you're an engineer in the 50's (although it's fair to note that it is still used today for very specific reasons).  The development of programming languages was just like this exact case.  A language becomes too unwieldy (projects gets larger and reaches the practical limitations of the language), so a new higher level language is created to cater for new features.

The next language then uses a single command to represent a group of lower level commands.  As you might expect, it is vastly more complex than just wrapping the lower level, but you get the idea.  A tool that converts the high level language to the lower level is called a compiler.

Once computers became mainstream, more and more different kinds of architectures were created.  An architecture is a CPU design which usually has its own machine language (the way 1's and 0's are organised for it to understand). As each CPU typically understood different instruction sets, different compilers were written to "wrap" architecture-dependent code.

Now the next problem was that it's not as simple as writing the code once and compiling it for each architecture.  The code usually had to be modified for each system it was intended to run on, so portability was lost.  Having a large project would render this process impractical so a new language came along that tried to solve this problem once and for all.

Java

Java was a language developed in 1995 by what was once Sun Microsystems (now Oracle).  What's interesting about Java is that it is much more than just a language.  Java is a whole ecosystem, having the language syntax, compilers, environments, SDK and community.

Duke, the Java mascot

But how did it solve the portability issue?  As I mentioned, it is a whole ecosystem so there is a more elaborate system at play.  What Sun did was create a language that is then compiled to a byte code rather than machine code.  This byte code is then executed by the Java Virtual Machine (so, yes, it's still machine code, but a different kind of machine).  This JVM is the only part which is differently coded and compiled depending on the architecture.  

So we now have a language which can be written and compiled just once and being confident that it will run on any kind of CPU as long as the JVM exists for that CPU.  This VM is also known collectively as the Java Runtime Environment (JRE), of which the byte code interpreter plays a major role.

Along the years Java was prominent on the web in what are knowns as applets.  Nowadays with the emergence of HTML5 and JavaScript (which has a relation of 0% to Java, so don't get confused), applets have become a thing of the past.  Java is also popular on desktop applications, mobilephones, TV set top boxes, DVD players, etc.

Java today

Java has a very strong community and many standards go through what are known Java Specification Requests (JSRs ), much like Request For Comments (RFCs) if you're familiar with network protocols.  Basically this is a process for definitions of ideas, standards, protocols, etc.

Through this process, Java has become arguably one of the top languages for high end websites (technically known as web apps).  Twitter for example, runs on Java, so you get the idea of the strength of Java.  Throughout this series we shall cover, quite in depth, how to write enterprise web applications in Java.

Java used to, and still does in a revived way, dominate the mobile aspect to.  This sheer adaptability, from top range servers to mobile phones, without doubt, makes Java the most versatile language ever.  In the early days of smartphones, Symbian was the king of mobile operating systems.  It used to run a version of Java known as J2ME (Mobile Edition).  Today the Operating System with the largest active user base is Android.  Surprise surprise, apps written for this OS are also in Java and use almost the exact same tools - it's a bit more complex - but we'll see as we go along  how seamless it is to adapt your Java code to it.

Next Steps

So now you have a very basic idea of what programming is and how Java relates to it.  Of course, a lot more resources can be found elsewhere if you're interested in more history and details.  Wikipedia is one of those sites so you can head over there to further whet your appetite.

Following this post we shall start off with a basic Java environment set up; from the quick installation to your first Hello World! 

Tutorials on Java and related subjects

Like many others in the field of IT, specifically software development, my passion for coding started way before I even considered looking for a job.  I was probably 13 or so when I wrote down my first few lines of code in Pascal and the moments of glory in class when my mates looked in awe at that spanking grey-on-black "Hello World!".

Could have launched a satellite with this!

Many things have changed since then, but coding has remained a central part of my life...mostly because it pays my bills (more than that too :) ).  One thing which got me to this point is the Internet community.  I wouldn't have been able to write the second line of code had it not been for that tutorial on some obscure website.  Of course, teachers and lecturer played a big part - they are not to be underestimated.  But once you're out the door, the tutorials on the Internet are your "only hope".  This only hope, though, is a treasure trove full of resources, from zero to hero.

So, after all these years I now feel able, and willing, to contribute back to the awesome community.  My experience is vastly Java and so I hope I shall contribute valuable information to those aspiring Java programmers.  I shall start publishing a crash course in Java, starting with the venerable "Hello World!" and ending up who knows where.  I'm aiming at enterprise Java, but we'll see.  The target audience would be hobbyist, student, and even professional developers, but having of course a basic understanding of a computer.

Thanks for coming by and I hope to welcome you again for the Java Tutorial Series!

Accelerated Mobile Pages

Browsing the web from our phones is nowadays a common thing.  In fact it is now likelier to browse from your phone than from a desktop computer.  Personally, I find myself using a desktop browser only while I'm at work or while doing some desktopy thing (such as coding or messing with VMs and networks).  If I'm just browsing during the evening, for instance, its 99% from my phone.

My preferred way of browsing is via the forum kind of applications, such as reddit or hacker news, so at that point I'm not really using a browser.  However, the majority of the content is delivered from websites so you see and interesting title, tap on it, and the in-app browser or the main browser is opened.  This typically works fine, until the site you're accessing is a megalith and takes tens of seconds to load.  After at most 3 seconds, if barely any content has loaded, the link is forgotten and I move on the the next link.  That's it.

The problem is that these websites are offering too many features for them to be practical on a smartphone.  Sometimes websites take even longer because they need to load the comments section, then come the suggested posts, with ultra big resolution images, followed by the author's biography...  It's unnecessary, I just want to see content.

A team of internet companies, including Google, have come up with Accelerated Mobile Pages (AMP).  It is primarily a technological development (not exactly unheard of, as we'll see), but  through its restrictions it tries to limit the amount of unnecessary crap on pages.  As I said, it's a development, however much of this development is in terms of standards and rules rather than faster networks, or something like that.

In fact ,the focus is on basically banning a whole bunch of heavy and also some outdated HTML elements.  Unsurprisingly, no more <applet>, no more <frame> and no more <embed>.  There are also strict limitations on JavaScript, however the most surprising (but great) banned elements are <input> and <form> (with the exception of <button>).  It may not directly impact immediate performance of HTML, but it will surely stop developers from adding useless "post a comment" forms.

The focus is primarily on immediate content.  If I get a link while chatting and I open it up, I don't have more than 3 seconds to read the title and move back to the chat.  Thankfully, on Android, this experience shall now improve with the new chrome tabs introduced in Marshmallow.  It's a technical thing, but basically it avoids having to use either an in-app browser (which is isolated from your standard chrome) or opening up chrome (which is slow).

Chrome tabs are much faster, at least in this demo (via Ars Technica)

But let's get back to AMP.  As I said, it is content that the majority wants, so in this age of platform webapps, single-page sites and all the rest, simplicity, again, trumps features.  Despite the lack of features, static areas of a website are hugely important.  If you're interested, here's a short how-to, however it is fair to note that static this time is mostly client side, so no JavaScript - which means you'll probably need server-side processing if you have "dynamic" content.

AMP avoids the common JavaScript the web is used to and realises the idea of Web Components.  These do have JavaScript under the hood, but since they are managed differently, it makes the page load faster without synchronous blocks by JavaScript.  AMP also restricts inline styling, conditional comments and some CSS attributes (although CSS is not so limited compared to JS).

As yet, (being days or hours since being announced) I personally do not consider this as a major breakthrough technologically - it's only a set of rules to reduce the bloat on webpages who primarily host content.  However, I am very glad with the way things are going and I do hope it gains traction.  

The benefits I see are greatly improved user experience with much faster load times and no nonsense web pages along with better development.  The more modular the pages, due to web components, the easier it is to develop.  There are no messy inline styles or randomly placed JavaScript.  Things are put in their place and the rules are strict - otherwise you'll not qualify for AMP and your page won't make it to the top of search results.  

Unfortunately, I don't have that much control on this blog, otherwise I would have AMP'd it right away!

For further details, there are quite some resources:

• Documentation
• Technical Description
• A post by Google

The Volatile Security of Volatile Memory

I forgot about yesterday...

It is the black box in every system, even our brain.  Volatile memory goes by many names, working memory, temporary memory, RAM, even just memory.  Whatever your preference, when you mention it you're most likely referring to the area of a system in which data is stored for a relatively short period of time until it is used and then discarded (or transferred to persistent storage).  One cannot possibly imagine a system without some form of memory; even if it is the same are where it is stored permanently, there is still some area used for temporary calculations.

Among the major differences between RAM and persistent storage is that RAM typically contains data about the processes that are currently in execution along with the data we are working on right now and will be discarded soon (yes I hear your screams, persistent storage does that too, but it also has data that we haven't looked at for months).  Along with this fact, hard disks enjoy the possibility of being totally encrypted.  They cannot be read unless the key is provided.  This is not possible in RAM, primarily because the CPU cannot work with encrypted commands.

I do not mean that the CPU is not able to process encrypted data and convert it to plain text, what I am referring to is the inability of the CPU to understand encrypted commands (opcodes) or work on the encrypted data as data rather than a decryption payload.  Let's say we have the binary value of 13 = 1101 and we want to add that to 5=101.  Our simple XOR encrypter will give us the values 0111 and 000 for the keys 1010 and 101 respectively.  Adding 0111 and 000 does not give the actual result for 18=10010.  The values have to be in plain text before actual processing.  XOR is simple and integral to CPUs so it is the simplest operation for it to decrypt the values.  Once decrypted it is then possible to add the values.

But here is the problem - where is the key stored?  Of course, working memory.  What is the point of encrypting the data in RAM when the key is in the same RAM?  What is the point of encrypting RAM after all?

Boom!

We encrypt disks because they can be removed or because they are portable, yet still contain data, unlike RAM which hold it until we turn off the system (or a bit longer if you're into memory freezing and forensics).  So, we think, RAM is inaccessible to would-be hackers.  Or so we used to think.

Recent research by various people and organisations (Sophos, Brian Krebs, Volatility Labs, among others) have identified a simple and small malware that simply looks up processes, maps their memory regions, copy paste and onto the attackers server for them to enjoy.  And by the way, the kind of data was not you're ex's text messages, but the PIN to you credit card, so it's a bit more expensive I would say.

Use only for great dinners.

I did my own research (and eventually BSc. thesis) on this subject, and it is quite scary knowing that the very heart of your system may be so easily compromised.  What's worse is that when you enter your PIN into any other system on which you have no control...God knows what's running on them and where your data goes.  Anti viruses barely have an idea how to capture such an attack, and neither do firewalls, internet protection or whatever you have.  If they did, they would block your debugger too, because that's how it works - like a debugger.  It's like a kitchen knife used for a murder - you cannot ban knives.

Here's a short and sweet step-by-step on how you can scrape your memory.  It's not intended to attack anyone, and it wouldn't be easy any way.  It's successful only if your target cannot protect their networks and you manage to get in.  The sample was done on Linux;  Windows would be totally different but still very possible (the Target attacks were in fact on Windows).  So here it goes:

A dummy little program was written in C.  All it did was store a username and password (entered using getpass() for increased security) along with a series of credit card numbers that are "swiped" into the system.

Swiping cards

We then find the PID of this running process just by ps aux | grep scrape (the program is named scrape, but it may be something like POSSwiper for example)

Getting the PID

Now we can get all the memory regions and maps used by our processes.  The /proc directory gives us a hand there.

/proccing to analyse the memory

We are interested in the heap space of our program which shows up nicely in the fourth line;  ranging from address 009580000 to 00979000 (both hex).  Next thing we do is fire up the actual scraper (which is, in our case, a kitchen knife.  A legitimate gdb debugger).

Dumping memory in just one line!

GDB shows a bunch of text; we're only interested in how we started it (gdb -pid <PID>) and how we stole the memory (dump memory <to where> 0x958000 0x979000)  As you can see, using the exact heap space memory range we got from /proc.  The memory will be dumped to the file we choose.  Of course, this requires administrator rights, but as one might expect, tens and hundreds of POS devices will most likely share the same password, and will probably have the default one too (such a typical case of a security breach - I found the password to my ISP's router on a public forum...).

Now, onto the next step - the analysis, if you call it that.  Data dumped into the file is from RAM, so as expected it is binary.  Linux simplifies this analysis by providing another tools - strings.  All it does is see what's in a file and spit our all the strings it could find.  That's it, so we pass the dump to it and we get a nice list of string, including the password (you didn't see it in the first screenshot because of getpass()) and all the numbers and everything.

The gold mine

That is all.  Now go and whitelist the list of processes on your system, before someone gets to scrape the memory off it.

HDMI over WiFi

No not really, no such thing exists.  Well you can stream HD media over WiFi but not in a plug and play way as a common HDMI cable.  There are various ways this can be accomplished but the idea is simple;  run a server from a device and play it on another, as long as there is a protocol, typically DLNA.

Recently I came across a new video format which looks quite interesting and powerful.  HEVC was released a few months ago (only drawn up sometime in 2013) and is now gaining traction.  I was surprised to find that an hour long HD video can be compressed down to 200 megabytes or so.  Being so new not many players can really decode it, as expected.  If you're on Linux, great news! It's not so hard to get it to play.  As always, VLC is your best friend so the solution I have/found is for VLC.  All that's needed is a new library from a PPA and you're good to go.

sudo apt-add-repository ppa:strukturag/libde265
sudo apt-get update
sudo apt-get install vlc-plugin-libde265

That takes no more than a few seconds; minutes if you're on a slow connection (which makes the HEVC format ideal in your case).

I wrote this little post about this format because I am quite interested in how the far we can compress HD videos, but also because it was a bit inconvenient for me to not be able to play it pretty much anywhere (BubbleUPnP and chromecast appear to handle it though).  It may spare you some time hunting for a way to watch that latest episode next time :)  Yet still, my original thought (and title) of this post were actually meant for something totally different, but hey, two birds one stone!

I need to learn to HDMI

Having organised cables is quite important if you intend to keep your sanity.  Not long ago I did rewire my homelab and after a few hours everything look perfectly in place.  Except for one thing; WiFi.  It was constantly disconnecting and apparently going offline and back again for no apparent reason.  Restarting, re-configuring and switching ports fixed nothing.

A few hours or days go by and I started noting red pixels showing up on my screen at particular points where the image was darker.  Then it hit me.  There must have been some interference between my WiFi router and the HDMI cable in its vicinity (hence the title ;)).  Looking around on the internet seemed to prove my theory, even though similar cases appeared to be quite uncommon.  I have not completely fixed it yet however messing around with the cable is a good workaround.  That's until the shielded HDMI cable arrives in my mailbox, which should hopefully fix the issue.

Remote Desktop Viewer - The cheap way [Part 1]

Microsoft RDP, RemoteFX, VNC.  That is the real stuff.  Solutions such as those will allow you to secure your connections, log you in to your desktop, compress the connection, etc.  But have you ever thought if it is possible to implement something rudimentary, totally in Java.  Actually it is possible.  But it's nothing much, and what I'll be doing here is a very, very basic implementation of an idea.  Obviously one can go on and enhance it, but it's almost totally impossible to produce a real solution, since Java does not have direct access to the OS, so for example you cannot remotely log-in, as you would for example using ssh.  Well it might be possible, but it would be an overkill.

As I said, I will simply implement an idea, so even though I know we won't be building the next Remote Desktop protocol, it is still interesting.

First we shall lay out some basic requirements.  Basically we will build a server and a client.  The server shall receive a request, it will then grab a screen shot, and send it back.  Meanwhile the client will wait for the server to reply with the image, and will then draw it.  This will go on until we disconnect.

So create three packages first, com.jf.rd, com.jf.rd.client and com.jf.rd.server.  Obviously you can name them whatever you want, but ideally you should have xxx.xxx.client and .server.

We'll start off with the server.  That way we can define what we expect from the client and what we intend to send back.

Now, in the server package create the JRDServer class.

package com.jf.rd.server;




public class JRDServer
{
public static int PORT;

public static String USER;
public static String PASS;

/**
* Parameters:
* Port, User, Password
* @param args
*/
public static void main(String[] args)
{
if (args.length < 3)
{
System.out.println("Usage: JRDServer Port User Password");
System.exit(0);
}

PORT = Integer.parseInt(args[0]);
USER = args[1];
PASS = args[2];

System.out.println("JRD Server sdtarted.  Will listen for connections on " +
"port " + PORT);

JRDServer server = new JRDServer();

server.start();
}

private ConnectionListen listen;

public JRDServer()
{
this.listen = new ConnectionListen(this);
}

public void start()
{
System.out.println("Service Thread starting...");
listen.startServer();
Thread srv = new Thread(listen);
srv.start();
}

public void stop()
{
System.out.println("Service Thread stopping...");
listen.stopServer();
listen.destroy();
}
}

This class is basically an entry point to the server.  I expect some basic Java knowledge so I will describe this only briefly.  We start the server by passing 3 arguments; the port to which we will bind, a username and a password.  The port is the real necessity, and as yet the user and password will not be really used, and will be there so that one day we can implement some sort of security.

There are also the start and stop methods.  start will initialise a listener class which will be running on a separate thread.  That way we can serve our clients in a parallel fashion and also prevent any user from blocking us to the rest of the application in a manner which will stop us from stopping the server.

stop simple stops the listener class and releases its resources.

Next up is the listening class.  This class will loop while the server is running and every time a connection is requested, an other, separate thread is created and the client is served.

package com.jf.rd.server;


import java.io.IOException;
import java.net.ServerSocket;


public class ConnectionListen implements Runnable
{
private boolean running;
private ServerSocket serv;

public ConnectionListen(JRDServer server)
{
try
{
serv = new ServerSocket(JRDServer.PORT);
}
catch (IOException e) 
{
System.err.println("The ServerSocket could not be initialised.");
System.err.println("Reason : " + e);
}
}

public void startServer()
{
running = true;
}

public void stopServer()
{
running = false;
}

@Override
public void run()
{
while (running)
{
try
{
Connection conn = new Connection(serv.accept());
Thread tr = new Thread(conn);
tr.start();
}
catch (IOException e) 
{
System.err.println("A connection could not be accepted.");
System.err.println("Reason : " + e);
}
}
}

public void destroy()
{
try
{
serv.close();
}
catch (IOException e) 
{
System.err.println("The ServerSocket was not closed.");
System.err.println("Reason : " + e);
}
}
}

This time, a server socket is passed as a variable to the constructor. This is the socket which will listen for and accept connections.  The run method, which is the implementation of the Runnable class is what will be running on a separate thread.  Therefore we can simply put a while loop and, kind of, forget about it, since it won't be blocking us (the main thread).  It shall keep on looping until the running flag is false.  So when we start the server we must set running to true and then start it.  To stop it - well - set it to false, and the looping will stop.

Of course, if we won't be listening for any more connections, we should close the server socket.

Finally, the Connection class is created.  Once this is done, the server is basically complete.  Now I should explain what will happen when this is actually run.  Any client that shall connect to this server will receive a byte stream resulting from a screenshot.  It is irrelevant if the client is a web browser, a mobile app or a simple socket.  Also, we won't be checking what the client is actually requesting, so as you can see, the username and password are irrelevant.   That means that you should either practice, and implement an authentication system (easily done) or simply avoid running this server if you fear someone might connect to it and, sort of, spy on you (aye, this is easier).

So, to the connection class.

package com.jf.rd.server;


import java.awt.AlphaComposite;
import java.awt.Dimension;
import java.awt.Graphics2D;
import java.awt.Rectangle;
import java.awt.RenderingHints;
import java.awt.Robot;
import java.awt.Toolkit;
import java.awt.image.BufferedImage;
import java.io.BufferedInputStream;
import java.io.InputStream;
import java.io.PrintStream;
import java.net.Socket;


import javax.imageio.ImageIO;


public class Connection implements Runnable
{
private static final int IMG_WIDTH  = 960;
private static final int IMG_HEIGHT = 600;

private Socket connSock;
private static final int BUF_SIZE = 2048;
static final byte[] EOL =
{ (byte) '\r', (byte) '\n' };
private byte[] buf;


public Connection(Socket connSock)
{
this.connSock = connSock;
buf = new byte[BUF_SIZE];
}


@Override
public void run()
{
try
{
InputStream is = new BufferedInputStream(connSock.getInputStream());
PrintStream ps = new PrintStream(connSock.getOutputStream());


for (int i = 0; i < BUF_SIZE; i++)
buf[i] = 0;


int nread = 0, r = 0;


outerloop: while (nread < BUF_SIZE)
{
r = is.read(buf, nread, BUF_SIZE - nread);
if (r == -1) return;
int i = nread;
nread += r;
for (; i < nread; i++)
{
if (buf[i] == (byte) '\n' || buf[i] == (byte) '\r')
break outerloop;
}
}


System.out.println("Done reading.");


Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
Rectangle screenRectangle = new Rectangle(screenSize);
Robot robot = new Robot();
BufferedImage image = robot.createScreenCapture(screenRectangle);
int type = image.getType() == 0? BufferedImage.TYPE_INT_ARGB : image.getType();
image = resizeImage(image, type);

ImageIO.write(image, "JPG", connSock.getOutputStream());


ps.flush();


connSock.close();
}
catch (Exception e)
{
System.err.println("Error, somewhere...");
e.printStackTrace();
}
}


private static BufferedImage resizeImage(BufferedImage originalImage,
int type)
{
BufferedImage resizedImage = new BufferedImage(IMG_WIDTH, IMG_HEIGHT, type);
Graphics2D g = resizedImage.createGraphics();
g.drawImage(originalImage, 0, 0, IMG_WIDTH, IMG_HEIGHT, null);
g.dispose();
g.setComposite(AlphaComposite.Src);
 
g.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
RenderingHints.VALUE_INTERPOLATION_BILINEAR);
g.setRenderingHint(RenderingHints.KEY_RENDERING,
RenderingHints.VALUE_RENDER_QUALITY);
g.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
 
return resizedImage;
}


}

There it is then.  The Main screen grabber and sender.  We're not doing much here;  just receiving a request and then write "Done reading" when the process finishes, and then a picture is sent.  The resizeImage method is used to reduce the size of the image so that we do not send an image the size of your screen resolution.  That would be slow and besides, you can also specify what "resolution" you intend to receive.  The socket is also closed here, that's important too.  The lines between printing "done reading" and ImageIO.write are grabbing the screen using the AWT (Advanced Window Toolkit), so what this means is that you must have an OS that supports GUI (i.e. not headless, as it is known) and you must be logged in basically, since it grabs the screen as seen by the current user.  Therefore apart from the fact that we cannot remotely login, we also can't turn off the video card.  You can turn off the screen, obviously (lol).

That was part one of this, erm, tutorial, or whatever it is.  I like doing these sort of mini programs when I am trying to solve other problems, that's why they are not at the bleeding edge of technology.  And then, when I'm done, I just write something about it, maybe someone out there learns something hehe.

The next thing we'll do, is build a client application.  I currently plan on supporting only viewing, but eventually, we might spice it up a bit by adding cursor support so that you may click on the client and it will then be forwarded to the server and eventually consumed by the OS that is hosting the server.

Also, the second part will probably come out either just before 2012, or probably in the first week of January, so until then, Merry Christmas and a Happy New Year! :D