MXBeans include a way to handle inter-MBean references
conveniently. You can use this to build an MBean hierarchy that
is simple to navigate.
I was thinking the other day - what with the Visual Basic compiler for Java, it would make sense for there to be a COBOL compiler for Java. That way we could draw on yet another large body of software to run on top of the Java runtime.
Okay, so I get strange thoughts occasionally.
Java DB and Apache Derby community has been working quite diligently to add support for JDBC 4.0 in their upcoming 10.2 alpha release
Check the Docwrench project , and turn your simple JavaDoc in an AWESOME JavaDoc
The Java compiler doesn't save parameter names in the class
files it generates. This is a problem for Standard MBeans,
because we'd like to show those names in management clients. I suggested earlier using a
@PName annotation on each parameter to specify its
name redundantly. Here's another approach, using annotation
processors, which will work without adding any annotations at all.
Mustang includes the ability to give additional information about MBeans to management clients via "Descriptors". But what if you are not yet able to migrate to the Mustang platform? All is not lost. You can still use Descriptors, though it's more work.
Started this right after JavaOne, then got distracted... hopefully someone gets something useful out of it.
for the complete scoop on JavaOne 2006.
What a week, I'm tired, my feet hurt, and I think I have a headache from the after dark speaker system.
I must be getting too old for this, but I'll be back next year, what am I? Nuts?
Why do people inflict...
JDK 5.0 allows you to make an application monitorable without
writing any extra code, using command-line properties such as
-Dcom.sun.management.jmxremote. But what if the behaviour
obtained using these properties isn't exactly what you want?
ellioth's blog entry on upgrading to Dapper Drake (ubuntu 6.06) makes it sound safe and simple to do, so maybe I'll take the dive. However he talks about installing Sun's Java on the system.
As he mentions, and as we pointed out on the jdk-distros site getting the JRE there is pretty trivially done. Getting the JDK installed is a little less trivial, just poke around in the synaptic package...
Beans binding (JSR 295) aims to make it easy to bind your application model to Swing components. Get the skinny on beans binding, a demo, and how you can help!
We have been accepting code contributions, for bug fixes, from the public for over a year. The program is described on the mustang.dev.java.net project page. Essentially the idea is, if there's a bug you see that you want fixed, rather than wait for a Sun engineer to make the fix that you do it yourself.
At Java ONE three of the contributors were interviewed and a recording of that interview...
I have some web sites that I publish for myself. There's some history to this, but last year I chose the Drupal content management system. It has a great featureset and a large community surrounding it. It is written using PHP and works pretty well.
So... Caucho (the makers of Resin) recently came out with PHP support, and I just ran it through a quick test. Caucho provides a couple tiny examples that show, yup, trivial PHP scripts run. But I wondered whether it would run a serious PHP application, like Drupal.
It works. I made a copy of the PHP for one of my sites, configured the site/default/settings.inc to point to the database for that site, and fired up resin. After a couple issues, I was pleasantly surprised to see it working really well.
... read on for further analysis ..
I'm at Java ONE. I've been up to my eyeballs in work on a project which Jonathan announced this morning. The project had a brief enough mention that I want to explain it to y'all.
If you watched the keynote you saw Mark Shuttleworth come up for a brief chitchat about stuff, and what it's like to be in space. That's interesting enough, but there were a couple pieces of big news in that chitchat...
Making the Java license on Linux less restrictive is good but is it too little too late?
I just listened to Software Engineering Radio Episode 14: Interview Ted Neward and boy that's got a lot of interesting food for thought.
JavaOne is upon us again already! I'll be co-presenting a session entitled "JMX Technology Today and Tomorrow".
I previously wrote about compiling the JMX API in Mustang by extracting the necessary subset of the sources and getting your IDE to make a build.xml for you. Joël Féraud has now posted a description of how to compile the JMX API with a purpose-designed build.xml that's included in the Mustang sources.
The Java Posse gang just posted Interview with Graeme Rocher of Grails which serves as a great introduction and/or overview of both Groovy and Grails (a.k.a. Groovy on Rails). I've used Groovy just a teensy bit, so I won't go into the language at all. If you want to look further, there is groovy and grails home pages chock full of information.
What I want to do is contrast the state of different dynamic languages.
Build your own scripting language for Java covers a topic I had wanted to research and write. Fortunately someone else took up the cause.
At issue is the question of using the JSR 223 features, in Mustang as the javax.script package, to implement a scripting language on top of Java.
I've written about this earlier, but I see this as potentially a very good strategic move. Any language author of a scripting language has a choice of "how do I implement the interpreter?". Typically a language author has to both design their language as well as the underlying interpreter engine. But, I think the required skills are very different. To be a good language designer, and to be a good interpreter implementer, are very different tasks.
With JSR 223 a language designer can now concentrate on the language design. They can rely on the Java VM to provide the execution engine.
Plus, their user community doesn't have to reinvent the whole world ... instead they can reuse the vast library of available Java classes.
In the Java World article I've linked to, the author takes you through the design of a simplistic language and the implementation of two ways to execute that language within Java.
We are pleased to announce the winners of the Mustang Regressions Challenge. From January 30 through March 31, 2006, we sponsored a challenge asking the public to test Java 6 (a.k.a. Mustang) and tell us about any regression bugs that were found. The specifics can be found further down this page. There are five winners in this contest, each of which are receiving an Ultra 20 workstation.
During the course of the contest we received over 130 submissions, of which 72 passed the screening process and were entered as regression bugs. We wish to thank everybody who participated. The contest gave us some very valuable information and feedback to use in improving Java quality.
After careful consideration a team of our senior staff selected the following entries as the winners in this contest. The criteria we used included the clarity of the bug report and the impact of the bug.
For more information go to the contest home page.