NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
I came across Vincent's blog posting yesterday and thought it sounded like a pretty neat idea. He notes that all the recent language additions like the foreach, generics, and the new easy getter access (a->foo) are mostly additions to the compiler. His suggestion is to go back to basics. Make the Java language easy to learn again (granted you don't actually have to use any of the new language additions now) and add an API for extensions to the compiler. When you compile your code, you just make sure to include the proper extensions in the compilation line like so:
In many ways, I think this makes a lot of sense. Now that Java is open source, an API to create new extensions to the core language could be a nice way to let all those developers who have clamored for a new feature that could theoretically be handled by the compiler have their cake and eat it too. Of course, what happens to the IDEs when all these new extensions start popping up in people's code?
What do you think? Would an API for extensions (pluggable no less) be better than adding new extensions that not everyone wants or needs into the core code?
Re: Java Language Extensions - How much is too much?
This is only usefull for experimentation for new language constructs and to implement them. Normal developers should limited use this feature as much as posible, else you would end up with hard to read code.
If this would be implemented, this extension api then there should be also a system where you can vote for your favorite extension and then let a group of language designers decide which will be added to the official language specs.
This extension idea is a good reason that shows that open sourceing Java has been a bad idea.
Re: Java Language Extensions - How much is too much?
It would be far better to just NOT ruin Java with all these mindless additions that are thought up for no other reason than that some other language has something similar so it must be a Good Thing (tm).
Re: Java Language Extensions - How much is too much?
Creating an extension framework for a compiler is a nice idea and makes it easyer to add new language constructs but this should only be used by compiler developers and not normal developers, at least not for production use.
If anyone would add new language features to Java, it would end up the same way as c++, power above simplicity.
So the idea for the system is ok but providing everyone access is a bad idea.
Re: Java Language Extensions - How much is too much?
IMHO this is a bad idea. As you said, you don't *have* to use the new language features, so at its most basic level Java is still easy to learn.
An extension API for the compiler is also a bad idea. One reason is just like you said - what happens to the IDEs when these new extensions start popping up in people's code? We can already expect problems and incompatibilities down the road thanks to GPL Java; I honestly think that this would just make the problems come sooner, and be more widespread.
Its a great idea that few people will use.
Its something that existed before to some degree, there are several 3rd party compilers out there that offer features that never made it into the JDK proper.
Using something like this would basically mean fragmenting Java, but that is already happening now with the language change movement. This way, language change advocates can build their own extensions and use them without bothering the rest of us... If something gains enough traction then it might make it into the JDK distribution, otherwise people would just ignore it.
So the guys who like closures could just enjoy them with this tool and if it catches on then great incorporate something thats tested and proven. If not they can still use it and get the full support of Java moving forward.
Obviously this won't be able to offer the full support of changing the entire API implementation etc, but lots of that can be simulated by a proper compiler change and some good 3rd party support.
Shai Almog
vPrise Software makers of vPrise Workgroup
http://wg.vprise.com/ founder of bean-properties the leading OSS properties implementation in Java https://bean-properties.dev.java.net/
Re: Java Language Extensions - How much is too much?
I would never language constructs not included by default in java. This is the fastest path the have a lot of incompatible code althrough it is all written in java.
Re: Java Language Extensions - How much is too much?
I've got a novel idea. If you don't want the new language constructs, use Java 1.4. Classes compiled for Java 1.4 will still work in Java 5, Java 6, Java 7...
This is a fine idea for academics but for those of us creating production code (the vast majority of Java developers) this is is a stupid idea. Call me crazy, but some of us actually like the idea of code compatibility.
Re: Java Language Extensions - How much is too much?
I think a language extension mechanism is a great idea!
I must add, that I *am* a little torn on the extension mechanism. On one hand I'd love to benefit from other people's great language ideas and I'd love to add stuff myself. On the other hand, I don't look forward to have to explain things to my colleagues, and I don't look forward to them and others introducing all kinds of crappy constructs. Anyway, power is good, so long as it's used responsible.
How about being able to insert actual grammar rules. A special grammar file could be loaded that inserts special grammar rules and overrides at certain chosen points in the grammar tree.
I wrote this grammar parser generator thing that I use to translate my own syntax to assembler, which lets me handle assembler a little more efficiently. In the top of my source file, I 'include' a grammar file, which lets me parse just about anything. The tokenizer is changable at runtime which is just a bunch of regular expression rules.
Instead of generating parser code, like how javacc and yacc works, I generate a rule-tree, which is a hierarchy of objects with specific behaviors.
Anyway, if we can build something like this into java, we could perhaps:
- translate specific overridden rules to java, then further parsed by default java parser. Not really like preprocessing, but more like injecting actual grammar stuff.
- completely override some rules to let us handle actual translation to bytecodes.
The grammar inserts could be 'included' at the top of a file, or passed into the command line compiler.
Re: Java Language Extensions - How much is too much?
> What do you think? Would an API for extensions
> (pluggable no less) be better than adding new
> extensions that not everyone wants or needs into the
> core code?
No!
For those who don't like the language extensions that have been recently added, an extension mechanism is *just as bad*. Developer A uses SQL-Embedded-Extension-Alpha, which forces Developer B to also use that extension. How is this any different from Developer A using generics forcing Developer B to at least be aware of them?
And for those of us that *do* like the language extensions (including some of those being proposed), how is an extension mechanism a good thing? Do you really want a hundred different flavors of Java? Isn't that what would happen if the compiler was opened up in such a way?
To be fair, this is sort of like using API -- if Developer A uses ORM-X, then Developer B also must, but in my opinion, much worse.
If you don't like the language extensions, or want to add new ones, fork the compiler and have at it.
Re: Java Language Extensions - How much is too much?
> It would be far better to just NOT ruin Java with all
> these mindless additions that are thought up for no
> other reason than that some other language has
> something similar so it must be a Good Thing (tm).
Java Language Extensions - How much is too much?
URL: DaVinci's Code
At 7:34 AM on Jan 3, 2007, Matthew Schmidt wrote:
Fresh Jobs for Developers Post a job opportunity
javac -langext generics.jar:closures.jar:autoboxing.jar myclasses...
In many ways, I think this makes a lot of sense. Now that Java is open source, an API to create new extensions to the core language could be a nice way to let all those developers who have clamored for a new feature that could theoretically be handled by the compiler have their cake and eat it too. Of course, what happens to the IDEs when all these new extensions start popping up in people's code?
What do you think? Would an API for extensions (pluggable no less) be better than adding new extensions that not everyone wants or needs into the core code?
Read Vincent's full posting for the rest of his ideas.
33 replies so far (
Post your own)
Re: Java Language Extensions - How much is too much?
This is only usefull for experimentation for new language constructs and to implement them. Normal developers should limited use this feature as much as posible, else you would end up with hard to read code.If this would be implemented, this extension api then there should be also a system where you can vote for your favorite extension and then let a group of language designers decide which will be added to the official language specs.
This extension idea is a good reason that shows that open sourceing Java has been a bad idea.
Re: Java Language Extensions - How much is too much?
How do you think you could implement such a plugin system for languages?I'm not an expert in language construction, but lexers&parsers are pretty monolithic entities, especially if you are constructing them using tools.
Also I'm pretty sure that IDE developers will enjoy such an idea.
Re: Java Language Extensions - How much is too much?
It would be far better to just NOT ruin Java with all these mindless additions that are thought up for no other reason than that some other language has something similar so it must be a Good Thing (tm).Re: Java Language Extensions - How much is too much?
Creating an extension framework for a compiler is a nice idea and makes it easyer to add new language constructs but this should only be used by compiler developers and not normal developers, at least not for production use.If anyone would add new language features to Java, it would end up the same way as c++, power above simplicity.
So the idea for the system is ok but providing everyone access is a bad idea.
Re: Java Language Extensions - How much is too much?
Javac is open source, there's no need to propose anything.Re: Java Language Extensions - How much is too much?
> So the idea for the system is ok but providing> everyone access is a bad idea.
Who is going to stop "everyone" from not having access?
Re: Java Language Extensions - How much is too much?
IMHO this is a bad idea. As you said, you don't *have* to use the new language features, so at its most basic level Java is still easy to learn.An extension API for the compiler is also a bad idea. One reason is just like you said - what happens to the IDEs when these new extensions start popping up in people's code? We can already expect problems and incompatibilities down the road thanks to GPL Java; I honestly think that this would just make the problems come sooner, and be more widespread.
I think its a great idea
Its a great idea that few people will use.Its something that existed before to some degree, there are several 3rd party compilers out there that offer features that never made it into the JDK proper.
Using something like this would basically mean fragmenting Java, but that is already happening now with the language change movement. This way, language change advocates can build their own extensions and use them without bothering the rest of us... If something gains enough traction then it might make it into the JDK distribution, otherwise people would just ignore it.
So the guys who like closures could just enjoy them with this tool and if it catches on then great incorporate something thats tested and proven. If not they can still use it and get the full support of Java moving forward.
Obviously this won't be able to offer the full support of changing the entire API implementation etc, but lots of that can be simulated by a proper compiler change and some good 3rd party support.
Re: I think its a great idea
> This way, language> change advocates can build their own extensions and
> use them without bothering the rest of us...
You are not being bothered by anybody.
Re: Java Language Extensions - How much is too much?
I would never language constructs not included by default in java. This is the fastest path the have a lot of incompatible code althrough it is all written in java.Re: Java Language Extensions - How much is too much?
I've got a novel idea. If you don't want the new language constructs, use Java 1.4. Classes compiled for Java 1.4 will still work in Java 5, Java 6, Java 7...This is a fine idea for academics but for those of us creating production code (the vast majority of Java developers) this is is a stupid idea. Call me crazy, but some of us actually like the idea of code compatibility.
Re: Java Language Extensions - How much is too much?
I think a language extension mechanism is a great idea!I must add, that I *am* a little torn on the extension mechanism. On one hand I'd love to benefit from other people's great language ideas and I'd love to add stuff myself. On the other hand, I don't look forward to have to explain things to my colleagues, and I don't look forward to them and others introducing all kinds of crappy constructs. Anyway, power is good, so long as it's used responsible.
How about being able to insert actual grammar rules. A special grammar file could be loaded that inserts special grammar rules and overrides at certain chosen points in the grammar tree.
I wrote this grammar parser generator thing that I use to translate my own syntax to assembler, which lets me handle assembler a little more efficiently. In the top of my source file, I 'include' a grammar file, which lets me parse just about anything. The tokenizer is changable at runtime which is just a bunch of regular expression rules.
Instead of generating parser code, like how javacc and yacc works, I generate a rule-tree, which is a hierarchy of objects with specific behaviors.
Anyway, if we can build something like this into java, we could perhaps:
- translate specific overridden rules to java, then further parsed by default java parser. Not really like preprocessing, but more like injecting actual grammar stuff.
- completely override some rules to let us handle actual translation to bytecodes.
The grammar inserts could be 'included' at the top of a file, or passed into the command line compiler.
This could get very interesting...
Re: Java Language Extensions - How much is too much?
> What do you think? Would an API for extensions> (pluggable no less) be better than adding new
> extensions that not everyone wants or needs into the
> core code?
No!
For those who don't like the language extensions that have been recently added, an extension mechanism is *just as bad*. Developer A uses SQL-Embedded-Extension-Alpha, which forces Developer B to also use that extension. How is this any different from Developer A using generics forcing Developer B to at least be aware of them?
And for those of us that *do* like the language extensions (including some of those being proposed), how is an extension mechanism a good thing? Do you really want a hundred different flavors of Java? Isn't that what would happen if the compiler was opened up in such a way?
To be fair, this is sort of like using API -- if Developer A uses ORM-X, then Developer B also must, but in my opinion, much worse.
If you don't like the language extensions, or want to add new ones, fork the compiler and have at it.
Richard
Re: Java Language Extensions - How much is too much?
> It would be far better to just NOT ruin Java with all> these mindless additions that are thought up for no
> other reason than that some other language has
> something similar so it must be a Good Thing (tm).
+1