Tim Boudreau's Blog

Community: Java Tools Archives

What if we built Java code with...Java?

So he created the Gosling project. It's pretty embryonic - and I think some of the file and resource classes could be replaced by straight usage of things like javax.tools.FileObject, but it has a nice simplicity. Here's the constructor for Gosling's own build to build itself. It has a similar feel to what Jon did in designing Wicket's APIs:

    public GoslingProject() {
        final Folder root = new Folder("/Projects/gosling/workspace/gosling");
        final Folder source = root.folder("src");
        final Folder lib = root.folder("lib");
        final Folder target = root.folder("target");
        add(new JavaApplicationBuilder() {
            @Override
            protected Set getDependencies() {
                final ResourceDescriptorSet dependencies = new ResourceDescriptorSet();
                dependencies.add(Apache.apache.wicket.core.development.resources());
                dependencies.add(Apache.apache.wicket.extensions.development.resources());
                return dependencies;
            }

            @Override
            protected Set getJars() {
                return lib.nestedJars();
            }

            @Override
            protected Folder getSourceFolder() {
                return source;
            }

            @Override
            protected Folder getTargetFolder() {
                return target;
            }
        });
}

I mean, the appeal of things like Ant is that many things are built in a pretty similar way; Maven is even more "my way or the highway" in that regard. I use (and sometimes like) both of them. And in theory an Ant XML script (xml script - now there's an oxymoron) is human readable - although I challenge anyone to make heads or tails of this in ten minutes. It certainly beats Make and tab vs. space madness. There's an argument that it's toolable - that a tool can analyze an Ant script. This seems to me to be a red-herring if you do a design like Wicket or Gosling use - where you know that the entire state you need to analyze is going to be set up in the constructor of a known class of a known type. The Javac Tree API may not be for the faint of heart, but analyzing the closure of a constructor is perfectly doable.

My point is that Ant doesn't really deliver the clarity it promised except in the most trivial of cases. You could have at least as much clarity with plain-old Java code - you just need to start from a good design so the code can speak for itself. And a design where all targets will be added to the build in the constructor is pretty darned clear. Isn't one of the things the agile crowd talks about a lot letting code speak for itself?

Not to mention that running javac in-process ought to be blazingly fast. And that such a project could import and call existing Ant tasks to do things with a thin adapter layer - so anybody's custom tasks or missing functionality could be handled leveraging stuff that's already out there.

It seems like a pretty nice idea to me.

Most Poetic Commit Log of the Year Award

Hopeless in my own destiny, strugling to really improve the speedup of startup at least a bit, but always loosing my improvements as Sisyphus his stone, I am adding this little change to prevent tons and tons of ClassLoaderCache objects from creation. Now only a resonable number shall get created during 2nd and subsequent startup.

Of course, you can only do this award once - after that, everyone will be trying to be poetic in their commit messages and it all becomes meaningless :-)

Directory: /core/startup/src/org/netbeans/core/startup/
=======================================================

File [changed]: ClassLoaderCache.java
Url: http://core.netbeans.org/source/browse/core/startup/src/org/netbeans/core/startup/ClassLoaderCache.java?r1=1.2&r2=1.3
Delta lines:  +2 -2
-------------------
--- ClassLoaderCache.java	4 Aug 2005 13:13:48 -0000	1.2
+++ ClassLoaderCache.java	5 Aug 2005 13:18:28 -0000	1.3
@@ -171,8 +171,8 @@
                 return null;
             }
             
-            
-            node = find (next);
+            // effectively node = find(next);
+            node.pos = next * NODE_SIZE;
         }
         
         return resIndex;

Usages tree view for NetBeans

So last night I wrote it, and you can download it here. AFAIK it's solid, but I wrote it from start to finish less than 10 hours ago, so a wart or two is possible.

It's testimony to NetBeans APIs that it took me about 3 hours to write (most of that time testing things), and the entire module is a single .java file plus some icon image files.

The source is in contrib/javaUsagesNavigator on netbeans.org, and of course, covered by the open source Sun Public License as is the binary.

It's probably a testament to the power of the internet that I can do this from a hotel in Beijing while I'm on a business trip :-)

NetBeans 4.0 is out and it rocks!

Javapolis was clearly a great show to be at - I wish I'd had more time to see more of it, not to mention Antwerp in general. Also I finally met Vincent Brabant, who's been active in the NetBeans community for years and made the French localization of NetBeans happen.

It's always nice to do a presentation where you have something to demo you know people will just love, and I had not one but three:

• The JFluid Profiler - Imagine a profiler that you can tell to only profile one method - and it leaves the rest of your app alone! No going out for a cup of coffee while the app starts in a fully instrumented JVM, and no filtering out reams of metrics about all the stuff you didn't want to profile.
• Ant-based projects - the kicker is when I take the downloaded sources for jEdit, and do New | Project with Existing Ant Script, and within two clicks I can press F11 and it compiles, and press F6 and it runs. No muss, no fuss.
• Mobility - A really really easy to use solution for the "device fragmentation" problem (where you want to use platform specific classes to take advantages of something like Nokia's FullCanvas class that won't link on non-Nokia phones).




This work is licensed under a Creative Commons License.



Powered by
Movable Type 3.01D