Dreaming in Java

by Robert Cooper

I kind of want to do something different today. When I write I tend to write, in cliche blog form, in two modes: "Hey, look at this!" or "I'm going to be snarky and rant about this!" Today, I would kind of like to have a narrow conversation.

The advent of the invokedynamic JSR, as well as the continuing RoR vs whatever hype and framework proliferation in Java has brought a question to the forefront: where is Java going? I have some ideas that I would like to express. This isn't necessarily a highly structured treatise, but more of a braindump.

However, I would like to hear what other people would like to see. I don't mean this as an exploration of other programming models or an academic conversation in language design. Rather I would like people to look at (a) what tools are they using all the time that should just be there, and (b) what would really make your day to day life better, both of these taken in terms of the JSE -- lets leave the web framework wars out of this for a little while.


2006-03-30 00:58:45
Regarding limiting values - why not just subclass String, Integer or whatever you need? Why change the language or use annotations, when object oriented programming solves this easily?
2006-03-30 02:29:59
In C# forks can do something like:

int I{ get{return i}};

which i think is awesome.

Dalibor Topic
2006-03-30 03:39:24
You won't get better integration with native systems, since that would reduce Java from a platform to just a programming language.

If Java is used only as a neat programming language to interact with native components, then Sun can not sell you big sparc servers when you need to scale up, so they don't make money.

dalibor topic

2006-03-30 10:36:45
Regarding limiting values - why not just subclass String, Integer or whatever you need? Why change the language or use annotations, when object oriented programming solves this easily?

All the basic types in Java are final.
2006-03-30 11:31:03
with it’s “freeze dried” objects --> with its “freeze dried” objects
David Smiley
2006-03-31 10:54:14
I've had the very same thoughts as you do on the JRE, Swing and JNDI. And definitely for some sort of Maven-JavaWebStart like repository to make runtime library management easier. It seems there is a lack of vision at Sun for Java. On XML language integration... it is not clear where you stand on that. I think that XML language integration (such as like what E4X does for JavaScript) is a very good thing. XML is perhaps the most important markup language and so for that reason I think it is a good idea for languages to have more native support for it instead of just libraries. And on XML Schema... it's true that Java doesn't have the constraint system that XML Schema has but I don't think XML Schema should drive languages to add compatible constructs. XML Schema enforcement is something that I think should be done as is done today--implemented by libraries.
~ dsmiley at mitre dot org
Dalibor Topic
2006-04-02 18:22:58
On a side note, gcj already offers you the 'JVM as a system service' option, as you can compile your bytecodes to native, run gcjh to create CNI headers for them, and then happilly call you Java code (now sitting in nice shared native libraries) from other languages, like perl, python or ruby. See PyLucene for how to do it python, http://search.cpan.org/dist/GCJ-Cni/lib/GCJ/Examples.pod for how to do it perl, http://jakarta.apache.org/poi/poi-ruby.html for how to do it in ruby.

Much, much better than dealing with a JVM in the first place.

dalibor topic

2006-04-04 08:24:23
> why am I a moron?

you are a moron because:
(1) "The JRE sucks" the JRE download size is fine, the speed is good too. Different profiles for very specific apps make sense, but you must have seen the slides about JRE size from JavaOne - its bang in the middle of the scale for various popular (real world) consumer downloads
(2) Although some kind of native structured data support in Java is worth investigating, bounded integer ranges, and Strings bounded by regex are too trivial to be motivating examples. If you are going to add native structured data support to Java, then it may as well be xml?
(3) "we should be able to create a Dynamic Proxy off an Object class" - occasionally I come across situations where I want to do this too, but normally as a quick fix. Given a bit more time, I revisit the application architecture and see what should have been done differently. Its not always something that can be fixed, but adding a new feature (multiple inheritence anyone) that simplifies some rare cases, and will be abused by many more people than use it properly, is surely not a good thing? (I'm all for language designers being proscriptive in their decisions)
(4) "Do you really want your Java to be running in the CLR?" why not? (if it works - Microsoft should license the TCK). Seriously, IronPython was getting very good benchmarks on the CLR before Microsoft employed the developer and it stalled. Wonder what he's doing?

2006-04-04 08:44:48
Well, If It Ain't Broke Don't Fix It. Avoid hype and framework marketing (smoke and mirror).
2006-04-04 09:47:52
> If Java is used only as a neat programming language to interact with
> native components, then Sun can not sell you big sparc servers when
> you need to scale up, so they don't make money

Such simplistic-black-and-white views are usually incorrect.

BTW, what's the value of using opensource like "gcj already offers you the 'JVM as a system service'", does anyone use in production environment?

I mean having something done is very different from being stable enough and 100% compatible. I still remember the Linux hype days, a bunch of unfinished software portrayed as "the end Microsoft", only when some companies started adding some value to it, like Red Hat or IBM, it became useful for things greater than webservers.

Since then I have some caution with hype, specially coming from opensource folks.

2006-04-04 21:54:35
1. JDOM? Puhlease. That's like XML for dummies. Start with something like dom4j for the beginnings a real XML framework. It has some stuff you don't need, but it's very powerful.
2006-04-04 22:00:20
2. (Oops). Metaprogramming can *never* fulfill DBC. The fact that it's being used for DBC is a great initiative, (apparently on several fronts), but if Java really wants this, it will have to step up to the plate with new language constructs.
3. Scripting languages on the JVM *will* happen. the scripting JSR is gonna enable this bigtime, and it will be an exciting evolution. You can consider it a new step in Java evolution. Who cares if Ruby doesn't show up to the party. That pos language is just a flash in the pan anyway. Python, however, please come over, let me serve you a glass of wine...
2006-04-04 23:58:20
>Lastly, UI needs to be declarative, not programmatic. Avalon and >Sparkle are truly awesome. XUL is really nice. Even ObjC/XCode on the >Mac with its “freeze dried” objects is not bad. Next to all of these,
>SWING has an Everest-style learning curve to work with proficiently.

huh, u think that swing has an everest-style learning curve, others like me don't.
& y don't we use html for swing ui if UI needs to be declarative, not programmatic.declarative approach just *****.

John C. Walker
2006-04-05 04:41:52
I've amazed that Design-by-Contract still is only provided by 3rd party vendors and has yet to make it into the language itself. At a very minimum, having a JSR that would at least define a common set of annotations so that one doesn't have to be forced into a proprietary implementation would be helpful.
2006-04-05 09:54:14
What? No my web framework is better than your web framework??? Sounds like you have given in and think RoR is going to win. In which case you are in for a treat - Grails is the Java answer to RoR. It uses the other official programming language of the JVM Groovy which is an agile language that plays well with your jvm objects written in Java.

The Grails web framework plays well with spring and hibernate so you can plug-in your existing services and hibernate object written in Java. You can also easily write a service to delegate to your EJB session beans with no hassle and inject it via spring to leverage your existing Java investment. I think that is where Java is going to go. Lighter, faster, agile, less 'big framework' code sticking out all over the app. Write your core components in Java and script them with the loosely typed jvm language groovy wherever you can. Also why use an xml config file why you can use a .groovy file that scripts the configuration of your Java internal components as the container comes up by calling their methods directly? Why not unit test with groovy http://www-128.ibm.com/developerworks/java/library/j-pg11094/ to make writing tests more fun?

I agree with you that GUIs should be declarative not programmatic. Anyone that has worked with a declarative UI technology would not touch swing with a barge pole. Any programmer that can build great SWING apps is wasted writing a GUI. They should be writing core business component code and let a designer that can script a little do the UI with a declarative technology.

If you want to see what is really hot with Java and declarative UIs check out ZK which happens to be an mind blowing web framework also. It does not use flash or applets - it outputs d-xhtml or xul depending on the browser and fires events over AJAX back onto the Java objects running on the server. No plumbing or thinking about the http incidental objects is required.

Someone should either sort out a decent XUL framework for rich java apps or fix the mozilla-java bridge so that the desktop space can finally be invaded by java.

What is a Applet again? It rings a bell but I think that it was just another one of those things that you had to learn to pass the exam but you instantly forgot about as it was as dead as a Dodo even back when you used to sit exams...

2006-04-06 03:04:47
XML language integration? xml is for documents not for constraining variables. if you would like to see a feature to handle documents better than perhaps a 'document here' feature for java source code would be nice as exists for bash and php e.g.
$mydoc <<< EOF
this is my document no "strings" requred and
on many lines. just like CDATA sections in xml.
perhaps there could be then be @Document annotation that you could put above it to specify whether you wanted the document variable to be a string or parsed into an xml dom or jdom object. then the compiler to check it is xml and do the parse work for you.

the main tediousness with xml is all those java types. does that just bore you to death? if you use an agile loosely typed language (say groovy) and a bit of programming by convention (i.e. naming your variables correctly) sprinkle in some annotations and aspects and maybe you would not have to deal with all that incidental stuff.

i feel we need a faster, lighter, dynamic more agile language rather than explict xml language support. annotations and apect orientated programming are a good way of avoiding re-inventing the wheel and cluttering your code just to constrain a variable. once again giving you faster, lighter moer dynamic code so that you dont have to deail with routine pumping and 're-invent the wheel' to do validation and show error messages.

check out how Grails which is RubyOnRails for Java handles validation. Grails is all about making your domain objects the main thing in your app keeping the "instantiate yet another Wheel object" code to a minimum by providing conventions by which the 80% of the incidental stuff can be generated for your via their custom ant tasks.

2006-04-06 04:22:17
i dont like is that you have to bundle the whole JDK you cannot just ship a part of it. i think that greatly limits the ability to get it onto the desktop. big fat downloads are not inviting to users. it would be much better if as you suggest the default install is was a mirco edition with just a small core of code - then when you try to run a new app it would see what other core libraires the app needs and pull those on demand. webstart is a smart technology which can be adapted to extend its release technology to the core runtime. i also agree that java should play better with dom, dcom, xpcom, corba, mozilla, et al. if folks want to call native services then that should be up to them. it should be a trivial task to bridge JMS to MSMQ on a windows box by instantiating the MSMQ com objects via automatically generated Java wrapper classes. when Sun saw Windows as trying to invade its market server share this looked very risky. given that what Java actually needs to invade the Windows desktop share to break out of its current server silo such a feature would really level the playing field. if the interoperability was by-directional and worked for mozilla xpcom also then you might start to see loads of cross platform mozilla xul desktop that have core business components written in java start to invade the desktop. instead the current big new hope of opensource on the desktop is novell's opensource implimentation of C# and all its runtimes called Mono. how sad is that that there is no java version of Microsoft Outlook with a big market share. even sadder that the big push on the desktop in Linux is Gnome and it is backing C# not java. lets just face facts. sun "dont do desktops" anymore. i guess it should not really come as a shock that opensource on the desktop is following the windows clone of java not java itself. it would take a massive push by sun to reverse this trend.