It was clearly evident from the new install program. The JDK install prominently displayed Oracle Corporation on the screen. They are the new master now. It remains to be seen whether this is a good thing or not. I do know one fact. Oracle is not going anywhere in the near future. They got profits from their databases and other offerings.
Maybe Oracle can take Java to the next level.
Here is the stickler. I could not recall how to generate random numbers. Sure I can look it up with Google. But a strong Java developer knows this stuff by heart. I seemed to recall Math.random once I saw it. But that is for doubles. I needed some ints. And the java.util.Random class was just what the doctor ordered.
You can instantiate the Random class without any parameters. Or you can pass a seed for the random number generated as a parameter to the constructor. Once you have a Random object, just call the nextInt method and you get a number between 0 and n-1 (n is the parameter you pass nextInt).
Now I had my number guessing program working in no time. I decided to add a little spice to the program that was not required. No I don't have Guess jeans models popping up on the screen. I just let the user keep guessing until they arrive at the solution. And I throw in some taunts as responses when you guess is wrong. Good stuff.
Of course I am going to use Java as the programming language. The eventual product will be a web app displayed in HTML. However the first version might even just be text based. We shall see. I will probably post a link to my alpha version when it is ready for distribution.
There is a new version of a solution called SonarJ that could assist with our problems. It analyzes code and detects your application architectures, and identifies things you have done wrong. You can get a clear view of how bad things are with their metric dashboard.
SonarJ goes even further by projecting the impact of refactoring your code. It does this without disrupting your code baseline. The tool can grab code from your IDE or your build project. And if it was not clear from the name, the tool targets code written in the Java programming language.
By the time Java 1.1 was released, event processing had changed. A new delegation model was adopted which implements the observer pattern. Any components interested in an event implement a listener interface. They register with the system to handle the event. This makes the system's job easier. When the event fires, all listeners registered for that event get notified. More than one component can receive and process the event.
If your component's event processing is going to take any real time, you should do the work in a separate worker thread to keep the system responsive for the user.
Two of the most useful components are the TextField and TextArea. The TextField is a single line of input from the user, while the TextArea is a multiple line edit control.
Checkboxes are components. They can be grouped using a CheckboxGroup class, which itself is not a component.
A LayoutManager interface has been defined to determine how components are placed on a screen. There are 5 different implementations of the LayoutManager provided to you by the AWT.
Let's talk about a few more AWT concepts. A container is an area on the screen which holds other components. A windows is a top level one on the screen that has no menu bar or border. It is used to create popup messages. If the user provides input in a such a window, it is then called a dialog. A frame, on the other hand, is a window that has a title, border, and buttons like maximize/minimize.
The last idea which I shall expound upon later is that of events. The entire AWT system is driven by events. AWT manages these events, and sends them to interested components. For example, an event is generated when the user clicks the mouse button. The AWT catches this, and sends the information to component(s) that had previously requested mouse press events.
The book I read online claims that the AWT is crucial for Java programmers to learn. Initially there were major changes in AWT before it stabilized. Here is a funny thing. Part of the AWT intro explained the origins of the word Java.
Java is actually an island in Indonesia. It is not just any island. A whopping 124 million people live on the island. That is more than half the population of Indonesia. The capital of Java is Jakarta. This explains the naming for the Apache Jakarta project.
Next time I will get into some of the components that the AWT has to offer.
The first exception was that the class "oracle.jdbc.driver.OracleDriver" was not found. Ooops. Then I found out that this class had been deprecated. Fine. I replaced it with "oracle.jdbc.OracleDriver". That also generated an exception. There was also exceptions when I tried to make a database connection. The were due to there not being a driver. I figured that I needed to solve the root problem before proceeding.
There were a number of web pages that said I needed the JDBC driver installed on my system. I grabbed the "ojdbc14.jar" file and stuck it in a number of lib folders on my machine. No luck. I thought it might be due to the fact that I had a later version of the JRE and JDK. Turns out I needed the jar file in my classpath. Once I did that, the program worked fine. Now I am inserting a lot of database in my database. Maybe later I will post some code snippets.
One driver category is a thin driver. It has its own version of SQL*Net. In other words, you do not also need an Oracle client installed on your machine in addition to the driver. This category of driver is written in the Java programming language itself. There is also an OCI category or driver, that uses Oracle's Oracle Call Interface (OCI). The final category is a KPRB driver used for writing stored procedures and triggers in Java.
Besides the categories of drivers, there are also different levels of drivers. The first type is a bridge, where JDBC makes use of ODBC installed on your machine. ODBC is a generic database access technology. Other types are differentiated by whether the drivers themselves are written in Java, and how the SQL code is translated and sent to the database.
Java Standard Edition 6 comes with the "java.sql" package. You should import all the classes in that package. JDBC requires a driver to run. You load the driver in your code with a Class.forName.
Any SQL can be sent to the database using JDBC. By default, the objects used to connect to the database automatically commit after each statement. You should use the close method on the connection object to free database resources.
The first task at hand was to deal with this huge file. It was 10 gigabytes large. Most text editors could not handle it. I wanted to see if my Java classes could deal with it. So I coded up a UNIX head program. It lists of the first 10 lines from the file.
Bamm. It worked. The Scanner class could read the first 10 lines with ease. The first time it did so there was a small pause. But I could read and process the first 10 lines. It seems to reason I can process the next 10 lines, and so on.
I will keep you posted on the progress of my little project. Next step is to figure out how to do database access with Java. I am thinking JDBC. But there may be better or more interesting technologies to try out.
Another problem I have is when a control such as a button is invisible. The other controls rearrange during the paint() so as to obscure the position where the invisible control would be. I don't like this reshuffling of the screen when a control goes invisible. There should be a way to reserve space on the screen for a control that may become visible in the future. However this is not the default behavior.
I normally use appletViewer to test out my applets in development. But I found out that this tool only displays the embedded applet in an HTML page. It does not render any of the other HTML elements. Weird.
Recently I have been creating buttons that have no text. They just display an image that I loaded as the icon of the button. How does the applet know which control generated the event?
It turns out that you can call setActionCommand and pass it a String. This String is when the applet will get when it tries to get the command. It puts you back in control for the event processing.
Here is a tip I discovered the hard way. Make sure you addActionListener(this) on the button you want to handle events for. Otherwise the applet will never get a notification that your button was clicked. This might be obvious. But it is painful to debug when you forget to make the call.
I had an exercise from my textbook dealing with times. In Java, you can get the number of milliseconds since 1970. This feature has been encapsulated with the Date class. The default constructor of Date initializes the object to the current date and time. Use DateFormat to choose how you want to show the date. Even though the class is abstract, you can still call the static members.
You can hide controls in an applet by using the setVisible function, passing in the parameter false. Here is something weird though. Hidden controls are removed from the user interface layout. There is no reserved space on the screen where the hidden control is supposed to be. The output looks as if the control was never there. Other controls will be placed over top of the region where the hidden control belongs.
My IE6 blocks the applet from running by default on a web page. This is probably related to my security settings, and not my specific browser. I still need to click to "allow blocked content" before the browser will run my applet.
I am starting to see a pattern with applet GUI programming. Create a label, text field, and button. Add them all to the content pane. Then you make sure the applet can get the events from the button. This is all happening in my init() function. It is almost boilerplate code for me now.
You create a Double object. Pass the String into the constructor of the Double. Then you can assign the value of the Double to a double variable. The conversion works well. Actually I think this is implicitly calling a member of Double that returns a double. Is this what they call boxing? Or maybe it is unboxing.
The general pattern I use when user input drives the display is to have a member variable of my JApplet derived class. There is conditional logic in the paint() method that depends on this variable. When a user action changes the variable state, repaint() is called to redraw the screen.
I've been doing a lot with buttons that have no text on them. They only have an icon image on them. I have encountered some problems with transparency. I would like the button background color to bleed through any white portion of my image. However does not seem to be the default behavior of the button class. Maybe I need to set some unknown options. I hope I do not need to code or draw my own button face.
You use newlines in the JTextArea text to make the thing jump to the next row in the control. One thing is strange though. The default behavior does not seem to provide anything other than the text in the control. There is no border or scrollbar or anything. Maybe there is some other control that is more like the Windows control I am used to.
Let's briefly look at the trends of Eclipse users. You could say they are comparable to the general Java development community. For starters they are using Subversion as the configuration management tool of choice. They also are using the Linux operating system for desktop development. These developers continually download and use the latest version of Eclipse.
CVS use is on the decline for configuration management. ANT is the build tools of choice. Maven is trying to catch up. Some are just using Eclipse itself to control builds. Web development is done using jQuery (I just got a book on jQuery, so I will be sharing what I learn). The majority of Eclipse users do not contribute to open source. That last statistic surprises me.
I hope I can get my hands on some survey data for Java developers as a whole.
If you handle some GUI events like button clicks, the pattern is to call repaint() to get the screen updated based on the user input. It is funny how quickly I forget my Java basics when I do not code for a long time. These rules have not been committed to heart.
For example, I had to rediscover how to convert a String to an int. You create an Integer object, passing the String into the constructor. Then you can assign the resulting Integer to a variable of type int. Also you need to qualify Math package functions with "Math." to get your Java to compile.
Some topics are universal. Break down complex routines into multiple subroutines (functions). Make use of constants instead of magic numbers. In Java this is done with public static final variables. I will say I am starting to get some bearings on how to do drawing on the Canvas. The upper left hand corner of the screen has coordinates (0,0). Increasing x goes to the right. Increasing y goes down.
Applets do not have a main function. Instead they have an init. They close when the web page that contains them closes. The containing web page is written in HTML. The applet itself runs on the client machine. There are some security restrictions like an applet cannot run a program, read a file, or write a file. You should test your applets on many browsers including multiple versions of the same browser.
The older class for applets is Applet. Go figure. You cannot use Swing with this old style class. You also cannot do icons or menus. Use buttons instead. I found that I could load an HTML page which referenced an applet. However when I recoded and recompiled the applet, an Internet Explorer 6 refresh would not run the new version of the applet. That was annoying. Instead I decided to use appletviewer. Here is another strange thing. The reload function in appletviewer causes the window to disappear and the viewer to freeze. Another funny thing was that I tried to use Graphics2D in my paint method. It compiled but just output a light blue screen. All my graphics were gone. I guess I can make do with the normal Graphics class.
It is time for me to learn applets. I convinced my employer to let me spend a week in independent study on Java. I need some program to keep me busy to really learn practical applet programming. Initially I thought I would write a copy of an arcade classic such as Pacman. However I think I will need more than a week to get deep into applet programming.
My new plan is to actually try to duplicate the main program we have on our project at work. It is a client/server C++ Windows application that connects to an Oracle database. This might be a good sized program to implement as an applet. The thing is over 2o0k lines of code. This will keep me busy for quite some time. I figure I can work on it in the office, and not get too much attention on my sideline activities.
This started a big discussion on what it means to not specify an access modifier for a Java function. In C++ it is easy. C++ class members without an access modifier are private. C++ structure members without an access modifier are public. However in Java, not specifying an access modifier means the function is package private.
Package private has no keyword. It is the access allowed when you do not specify a modifier. This causes the function to only be accessible by other members in the package. This is different than public, private, or protected. I am sure I learned this some time ago in my Java college class. However today it was solidified.
Struts is the most well known framework. It is well documented and has a large following. A drawback of using struts are the big configuration files. You need to use a lot of XML markup files for forms and rendering. I hear that developers are moving away from this framework in general.
Java Server Faces (JSF) is another framework. It runs on an application server like WebSphere. It strives to decouple the components and the view. The most frequently used implementation of JSF is Apache's MyFaces. JSF uses a managed bean to store user info. The bean classes contains the logic. This technology is backed by big companies like the former Sun Microsystems. A few years back I did hear that JSF might not be appropriate for mission critical applications. Not sure whether this opinion has since changed yet.
One thing that struck me as odd was that the authors of the book are young. Or more precisely they are still in school. One of these is an undergrad, and the other a grad. That does not mean they are junior. They seemed to be on the cutting edge of Java right when it came out.
This book does specialize in teaching you how to code network games. The authors believe that object oriented programming is the way to go for creating games. They are going to teach me a lot about AWT (since Swing has not been invented I guess).
Chapter 1 already got me into a lot of Java syntax. It also highly recommends you use arrays instead of lists for speed. Back in 1996, Java ran a lot slower than compiled C or C++. I also learned some basic stuff I was never taught in my Java college class. The import statement allows you to reference classes in packages. However you can still access those classes without an import by using the classes fully qualified name. I did not know that. I am excited about getting into the meat of this book. Who knows? I might be turning out some cool games in no time.
Enterprise Java Beans has been updated. Things have gotten much simpler with it. The beans are "light". Complexities such as requirements for frameworks are gone. This is in line with the scaled down profile version of the Java EE.
Right now I am still concentrating on learning Java Standard Edition. Some Java friends keep asking me whether I am up to speed on Java EE. It might be time to start learning it. Looks like I will have access to a new updated version, which is actually simpler than previous ones.
Normally books like these get obsolete immediately. And this book seems to have code that became obsolete with Java 1.1. However a number of comments on Amazon indicate the book still has a lot of merits. Well it warrants a read by me even though the book might be 25 years old. I placed an order with Amazon today.
The good news is that some of Swing is available. No AWT or JDBC is supported yet. The eventual goal is to port all of Java to the Apple. Right now there is also a JDistro available. This is a desktop which is written in Java Swing. JDistro is a limited version too that can only run 1 app at a time.
The whole thing fits on 3 floppies. Source code will be made public. This seems pretty hard core as the Apple II is some hardware from yesteryear. Now we just need Java ported to the Tandy Coco III, and I will be complete.
All code is interpreted by the Java Virtual Machine. However for methods that are used very frequently, the JVM compiles the code and then you get really good performance. The trick is that the JVM can see how the code is used many times. Then it has the knowledge needed to optimize the compilation.
With the default options, code written in smaller sized methods runs faster. The reason for this is the the JVM will not compile methods that are too large. You can modify this behavior with some options. In fact you can even force the JVM to compile everything. While this might seem to be best, it is not. You should let the JVM interpret the code first. Only after interpreting a method many times can it make the best optimizations for compilation.
Techniques such as SOA are complex. Java frameworks now offer a lot, but have a small code footprint. There are multiple lightweight Java containers. Tomcat from Apache happens to be a free and popular one. This may be the way of the future. Developers are tired of running under app servers like WebSphere.
This solution is aimed at web developers. Servoy will release the source code on their own hosted Subversion servers. The GPL license requires that users of their libraries in turn make their source code available to the public free of charge.
Department of Defense standard DO-178C defines methods to verify object oriented systems for critical uses. In the past, Java has not been normally used for mission critical applications. All that may be changing now.
Java now has JSR-302 which addressed safety critical Java. Safety critical apps are mostly the domain of large scale DoD sponsored programs with big money backing them. This is a good move for the Java world.
A bunch of companies are working on a Java based solution to cloud computing. It will be using the Spring framework. It will run on vSphere from VMware. And it will be hosted on the Salesforce.com servers. This beat will be called VMforce. I guess that means that VMware is the main company behind it.
This solution will be able to host any Java application in the cloud. There are around 6 million Java developers out there. Cloud computing is supposed to boost their productivity. So if this works, this may have a big impact on their productivity. Look for VMforce to be available later this year.
C has a small footprint. So if that is required, choose C. Java has a long startup time. This is the time it takes for the JVM to load and initialize. We are talking on the order of seconds here.
Direct machine access can be done with Java using JNI. However it is clunky. In C, direct machine access is natural. However garbage collection in Java is easier than C's malloc/free. Java also make parallel programming easier.
Be careful when you are comparing speed between Java and C programs. You must ensure both programs are using the same algorithm. You also need accurate stats to make a good comparison. As an aside, C# will normally be a little bit slower than Java.
There are other niche additions to Java in Java 7. For example, in the security world, there will be support for curve cryptography. Personally I care little about JVM support for dynamic languages. Java with its static typing is fine for me.
Gosling did not provide a reason for leaving. Hello? Can you say Oracle acquisition? He is going to take some time off.
Word on the street is that the Java faithful were taken by surprise. Does this mean that Gosling will not be present at JavaOne? You got to go and find out.
There is also talk that the Java SE and Java ME platforms will merge into one. Perhaps that means that mobile apps are becoming common. It is either that or mobile apps are not as important any more.
The JavaOne conference is going to be held in tandem with the OpenWorld conference. You can register and attend events at both conferences. JavaOne will now be held in the September time frame. I guess Oracle has decided what has the precedence. At least they are not ending JavaOne.
I saw an advertisement while perusing a technical magazine. It was for an object database created by InterSystems. The product was called Cache. What caught my eye was the claim that it had technology to persist Java objects with a relational mapper.
The object model for Cache is based on the Object Database Management Group (ODMG) standards. It works with C++ and .NET as well as Java. The marketing boasts 5x the speed of normal relational databases.
Cache is meant for Rich Internet Application development. It uses an application server. However there are multiple ways to make use of the object database. You can use templated classes. There are also lightweight API calls for direct database access. Finally there is the Jalapeno technology.
Jalapeno stands for JAva LAnguage PErsistence with NO mapping. You create your Plain Old Java Objects (POJO) first. Then you use Cache to generate a schema to work with those objects. Cache has a library class to deal with the database. You can apparently just focus on your POJOs, and Cache will do the rest like magic.
When rolling out a Java program, like any other installation, you need to make sure the resources required by the program are installed. The main way to include all the files you need is with a jar. Jar is a utility included in the Java SDK. You can find the program in the Java bin directory. This program has a command line interface.
The output of the jar utility is an archive file. You can run the program contained in the archive using the Java interpreter. Here is an example to create a jar file:
jar cf dL1.jar dL1.class.
Once you have the archive, you can inspect its contents using the following command:
jar tf dL1.jar
You can extract the full contents of the jar file like this:
jar xf dL1.jar
Jar creates a META-INF directory. Within that directory is the MANIFEST.MF file, also created by jar. You need to manually add the entry point for the program on the bottom line of that file as so:
To run the program contained in the jar, you can execute the following command:
java –jar dL1.jar
Eventually a bunch of Java programmers joined the team. They decided the Korn shell scripts had to go. Being Java guys, they turned to Ant to do the builds. The result was a bit more reliable.
The Java guys got bored after a while. They started looking for ways to improve the build scripts. Maven was cited as a cool build tool. There was talk about redoing the build scripts again. However the Java guys left the project before any progress was made on that front.
It might be a blessing that we never ported our builds to Maven. I just read a rant describing Maven as pure evil. The author recommends you code your own build tool from scratch. He advises you to use Rake or Ant if you want to utilize a package. However he abhors Maven.
Here are the reasons to avoid Maven. It has the worst configuration syntax. The documentation is bad or incomplete. Maven is not flexible. It also has a broken dependency management subsystem. Exercise extreme caution if somebody tries to port your build scripts to Maven.