Download DOCX

Introduction to Java
Jasper Zhang
Introductions (slide 2)
Java has been around for a long time. It essentially took birth when C++ kind of matured. It offers many
features that C++ and other “unmanaged” languages don’t have.
The one thing that distinguishes Java from C/C++ and other languages is memory management. You
never have to deal with pointers directly, you can just call new and never worry about delete or free.
The disadvantage is that it will never be as fast as compiled languages like C/C++ because of that
management. It is also “interpreted”, like perl and bash, it is read by another program written into
machine code (usually written in C) and then executed by that “interpreter”.
The speed disadvantage of Java and the bytecode that it compiles out is starting to get smaller and
smaller, closing in on totally trivial. Some mobile devices even have CPUs that reads Java bytecode
natively.
Compiling and running (slide 2)
Java is first written in Java (duh!) before it is sent to javac, the command line compiler that converts
your code into Java bytecode. Java files start as *.java and Java bytecode start as *.class. The *.java
files doesn’t correspond exactly to the *.class files. As the file name suggests, *.class files represent a
single class in your code. If you have multiple classes in a file, you get multiple *.class files for that one
*.java file.
Java 2 (slide 3)
Java, as the slide shows, is divided into the standard and enterprise edition. Both are free and
downloadable from Sun.
The standard version offers everything that a desktop user will want: console apps, GUI apps with swing,
basic socket connections and all that goodness.
Enterprise edition is not directly supported by Java, it’s just a specification. Sun, however, does provide
a framework that will support the specification. Java enterprise edition specifies resources to be offered
by a supporting infrastructure that meets the needs of large web applications. This will be talked about
later.
J2SE, Standard Edition (slide 4)
Java 2 Standard Edition (J2SE) refers to the standard, the bread and butter of, Java. Everything in Java
builds off of this, even the enterprise edition. It offers your basic set of stuff like math, I/O, collections,
1
network, etc. All the basics are here. Please go through the mandatory “Learning Java” presentations
on how to actually write basic Java apps.
Also, take note that there was a huge change in Java 1.5. It introduces things that make transition from
C++ to Java seamless with generics and everything. Please read up on New Java 1.5 presentation under
“Learning Java” for more details.
J2EE, Enterprise Edition (slide 5)
The diagram shown is a diagram that shows basically what each layer of the J2EE infrastructure is
specified to be. It is broken down into the multi-tier architecture (Keyword!! May show up in job
interviews!). It has three tiers: the web tier, middle tier and data tier.
Web Tier
The web tier is purely presentational. It is designed to spit out code for the browser or client. In
this current era, almost all J2EE frameworks are designed to feed the web browser, especially
Firefox (many reasons).
There are two basic sides to the web tier, you have browser code and server side code. This sets
up your basic client to server model. The client is your viewer and the server is the service that
provides the data to be viewed.
The client side usually is all browser readable code like HTML, Javascript, Flash, XHTML, etc.
These code are static and cannot change depending on user interaction. There are many
utilities out there that allows these code to be developed faster and maintained at cheaper
costs, like DOJO and JSON for Javascript that brings widgets and object oriented-ness to
Javascript.
The server side usually includes technologies that generate the client side code. These are
dynamic code that will change depending on the request sent from the client. The messaging
between client and server is usually established over HTTP with maybe HTTPS for security. The
server side includes all sets of languages that include popular buzz names like: PHP, ASP, JSF, JSP
and such. Sometimes the application server (appserver) sometimes bypasses all these and feeds
HTML straight to the client via Java servlets. Servlets are just applications that reads in HTTP
messages and spits back client side code on demand.
The interesting thing to keep in mind for these servers is that every time you make a request to
these servers, it spawns a thread to address the request of a single client… so in the end each
visit or page request will use up a new set of memory just for it.
Middle tier
The middle tier is known as the business logic. These are things that mediate between the data
tier and the web tier. These are things that make book keeping work.
2
The crux of the middle tier is the Enterprise Java Beans (EJB). EJB are resources that act like
servers and can address multiple requesting entities at a time. The reason for this is that the
middle tier can service multiple web tiers from different servers at once. It is mostly divided
into three categories: stateless session beans, stateful session beans and Java Messaging Service
(JMS) message driven beans.
Session beans are driven by the idea of a session. A session is a “visit” from a client. It’s
whenever a specific user establishes a set of requests that are related (or unrelated) to a single
visit. This is the difference between stateless and stateful session beans. The stateless session
bean assumes that each request is not dependent on any other requests in a session, therefore
can be adhoc and lightweight. The more difficult one to develop and maintain one is the
stateful session bean. These beans assume that a request can depend on another; therefore the
whole entire session is interconnected.
The message driven JMS beans are important when it comes to notification. It presents queues,
topics and profiles for messages. The topics are as they say, topics, like topics in a discussion
forum. They indicate a set of message categorizations. The queues are where messages are
sent for delivery. Profiles are what designate the mapping between recipient and topics. I
won’t go into more detail since this is a huge topic… but that’s the basics of it.
The last part of the middle tier worth mentioning is associated with web services. Web services
can stand as stand-alone clients that don’t need to be in an application of this intensity. They
access a remote “service” that will provide functionality in a fashion similar to making a function
call. This will be discussed in more detail next week. This is what allows a specific appserver to
talk to another and share data and/or functionalities.
Data tier
The data tier is the mediator between the data stores and the middle tier. It provides a level of
masking that allows the middle tier to not need to know what is underneath. The two
important aspects of data tier are divided into database connectivity and persistence.
The database connectivity is provided by Java Database Connectivity JDBC. JDBC runs on a
driver system. If you have a database that you want to connect to, just copy your driver into the
driver classpath and change some configurations and BOOM! You are able to connect to another
database. JDBC lets you associate data stores to these drivers with more details that are driver
specific. These drivers are provided by the database vendor and should not be a point of worry
for the developers of a web application. JDBC offers its own SQL that is generic. It will do a
majority of the tasks that you will need and JDBC will translate the special SQL to the proprietary
SQL of the target data store.
The persistence aspect deals with Object Relational Mapping (ORM). What ORM offers is a
mapping between database tables and classes/objects within your application. So essentially
3
what persistence really offers is a way for you to serialize a session. Serializing is the act of
transforming a life, running, object into a savable form, either XML, file or a row in a database.
Java Development (slide 7)
Old school Java developers and other real legit ones insists on VI/VIM or Emacs… but realistically people
develop using Integrated Development Environments (IDEs). These are GUI applications that sets up
and maintains projects for you as well as give you syntax coloring, auto completion, object listings and a
lot of other cool features. I highly recommend developing Java in one of these. They abstract you from
having to deal with not knowing if you are doing things right… BUT! You will still need to know how to
use the command line stuff in case you are stuck with just a Bash session. In the lectures in “Learning
Java” you will be forced to work with ant, the Java version of make, and javac as well as the java runtime
command line tool. Learn these well, you never know when you won’t have them at your disposal.
The IDEs that I recommend are:



Eclipse (my personal favorite)
Netbeans
JBuilder
Application Servers (slide 8)
So I keep mentioning that J2EE is a specification… with resources and all. So what about a concrete
version… something that provides all that? That’s what commercial application servers (appservers) are
for. Many vendors make them, some are free and some are costly, but they are out there. Look around
if you are interested. Refer to the lecture slide for a list of popular appservers.
Others (slide 9)
There are other servers worth mentioning and they are pretty much partial or non-J2EE-compliant
servers that are still useful. The most important one been Tomcat, still widely used to serve up servlet
pages independently of the weight behind a full J2EE appserver.
4