Posts Tagged Java

Creating an Eclipse Plug-in Update Site – And Fixing Hidden Errors in Plug-ins

Today, I set out to create an Eclipse update site to host Team 449’s plug-ins. (If you’re in a rush for answers, just scroll to the bottom.)

Eclipse is actually one of the less buggy of applications. It doesn’t crash every three minutes like Bloodshed Dev-C++, it doesn’t crash every two minutes like Internet Explorer, and it doesn’t crash every minute like Windows. The Java development environment is beautiful, the task management system is well-designed if poorly-integrated, and the C++ development environment is second only to Emacs, Vim, Ed, and the ever-elusive butterfly technique (its not actually that great). Eclipse has a unique system of managing views and perspectives that allows a huge amount of flexibility to the user. But Eclipse’s plug-in development environment is less than satisfactory to the developer.

To begin with, Eclipse plug-ins are based on a less-than-easy-to-use API. Sure, its easy to do the things the designers anticipated you would be doing – like compiling their sample projects. But there’s no level of abstraction between “here’s a method to do exactly what you want” and rewriting half the API from scratch. Furthermore, the Eclipse developers insisted on creating their own system for everything, from user interface functionality to file system access. A good deal of the documentation is totally obscure, and the sample projects are no help.

Now suppose you’ve suffered through the experience of writing a plug-in, you’re almost done, and you’re ready to export. Or more likely, you’ve just begun, and you’re ready to export just to see what happens. There’s just one little problem – that tiny icon over in the “package explorer” with the red X or the yellow exclamation point – Eclipse doesn’t like something. Such was my situation as I was trying to export my plugin, so that I could export my feature, so that I could test my update site.

Read the rest of this entry »

Tags: , , , , ,

1 Comment

Java OpenGL Example – Spheres

For those who want to take advantage of both hardware acceleration and Java’s cross-platform compatibility, Java has an OpenGL binding, known as JOGL. This binding is exactly the same as the C version – the only difference is that Java requires all methods to be ‘object-oriented’. In order to call an openGL method, we first have to acquire a GL or a GLU object (depending on which library the method would come from in C), and then call the method on that. For example, instead of the C code below:

  1. glBegin(GL_LINES);
  2. //some stuff here
  3. glEnd();

we would have the Java code:

  1. GL gl=autoDrawableObject.getGL();
  2. gl.glBegin(GL_LINES);
  3. //some stuff here
  4. gl.glEnd();

This makes it easy to convert C++ to Java code, and vice versa. In fact, if your code is longer than 100 or so lines, it’s probably best to just write a script to do the hard work for you. The packages to include are javax.media.opengl.* and javax.media.opengl.glu.*. As far as I know, there is no support for GLUT, at least with this particular Java OpenGL binding. Read the rest of this entry »

Tags: , , ,

2 Comments

Event-Driven Programming in Java

I recently noted that several students in a beginning computer science class at my school had been learning event-driven programming by themselves, without bothering to use google or any textbooks. While I approve of this experimental learning approach in general, in this case, the result was less than good.

The programmers in question wanted to design a system in which, so long as the number of button presses was less than the number of lines in a certain file, pressing the button would retrieve the next line, process it, and print out the result. They did this as follows (I’ve made some modifications for readability):

  1. button.addActionListener(new MyActionListener());
  2.  
  3. Scanner s=new Scanner(new File("values.txt"));
  4. while(s.hasNextLine()) {
  5.   while(!button_pressed);
  6.   button_pressed=false;
  7.   processLine(s.nextLine());
  8. }
  9.  
  10. private class MyActionListener implements ActionListener {
  11.   public void actionPerformed(ActionEvent e) {
  12.     button_pressed=true;
  13.   }
  14. }

From the programmer’s standpoint, I suppose this actually is the intuitive way to do it. If the user wasn’t involved, we would just loop until there were no more lines, but since the user is involved, we have to wait for the user to press the button, hence the while loop. Nevertheless, this is a Very Bad way to do it. While in the loop on line 5, we are using 100% CPU, even though all we are doing is waiting. If we want to do another operation at the same time, we are doomed.

Read the rest of this entry »

Tags: , , , , ,

2 Comments

Java Plugin Architecture with ClassLoader

For a program I was writing (GCenter – a productivity tool – saves you time by minimizing the time it takes to load your games), I found it necessary to create a plugin architecture with Java and ClassLoader. (I expect Scout449 to eventually use a similar system, although probably with cleaner code.) My code has several cheap hacks, but remains an effective demonstration of a decent plugin system.

Java lends itself particularly well to plugin systems, since classes are loaded dynamically anyway. The idea of a plugin system is to modify how Java loads things. Normally, Java will load your program from the class files in its directory or jar file. When creating a plugin architecture, you want it to also load classes from different jar files (generally the jar files in a certain directory). The solution is to create your own version of the ClassLoader.

Most of the code below is just to navigate the jar files. In the execution of the application, a PluginReader is created for each jar file in the plugin directory. The read() method is then called (line 39), which first fetches a manifest file named “MANIFEST.GMF” which contains the name the actual plugin class (the class that has information like author’s name, as well as functions for starting the plugin running). This class is then loaded, and the class itself is registered with PluginUtils, so that it shows up as an option on the application screen. Then, all the other classes are loaded via the same method (but they are not registered), so that they can be used by the plugin. Finally, copyFiles is called, which copies the entire contents of the jar file to a temporary directory, so that the plugin can fetch graphics and stuff if it wants (using a path conversion method that takes a jar file path and turns it into a temporary directory path).

The real meat is at the very end: line 206 and on. Here, we define a ClassLoader that takes as an argument to its constructor a JarFile, and can be used to load classes from that JarFile. But the real beauty of the ClassLoader is not simply that we can load classes from a jar file, its that when those classes then want to load more classes or find more resources, it is still done within the context of the jar file. Which means that we don’t have to be 100% thorough, we just have to get the plugin going – Java will be happy to handle the rest for us.

Creating a class is simple. We just have to read in a .class file and call the ClassLoader’s defineClass method – in this instance, using our own createClass method as a proxy (just for convenience).

Read the rest of this entry »

Tags: , , , ,

No Comments