Slashdot Log In
Sneak Peak at Java's New Makeover
Posted by
chrisd
on Thu Feb 06, 2003 02:38 AM
from the call-it-chai dept.
from the call-it-chai dept.
SadatChowdhury writes "Aside from templates as already reported in a past slashdot article , a little snooping around revealed the details of the following newly revealed features in the upcoming release of Java 1.5 (codenamed: Tiger) : Autoboxing , Enhanced-For-Loop, Enumerations and Static Imports . Must read for Java fans."
In related news: jdkane writes "Sun Microsystems delays a much-anticipated Java specification by three months to comply with guidelines designed to keep Web services interoperable. Says Ralph Galantine, group marketing manager for Java Web services at Sun: "We thought that this change was important for the industry, so that there was no conflict between J2EE 1.4 and the WS-I, "We thought it was worth taking out to the summer." It's very refreshing to hear that a big software company is looking out for the industry, instead of just their own."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Yay! (Score:2)
At least *I* think it's reason to rejoice...
Re:Yay! (Score:2)
s/Python/C++/g
Re:Yay! (Score:2)
Of course, I'd prefer the revers. I'd rather have python become more Java-like in terms of its standard library... like, say, a GUI library?
Re:Yay! (Score:2)
Actually Python is already a feature of Java and Java is already a feature of Python. It's called Jython and you can code against any java package, including SWING or the Eclipse SWT, in Jython.
Re:Yay! (Score:2)
I sure as hell wouldn't use python to call Swing...
No what I meant was that I would like to see some (very thin!) wrappers in python for native OS widgets, sorta like SWT. wxWindows just doesn't cut it, IMO.
Don't forget Generic Types (Score:2, Interesting)
I'm not too sure I like them, as they do add a completely new and different and more cryptic syntax to Java, but I can definitely see the use for them. No more clumsy casting when you retrieve something from a List.
Daniel
Yes, although generics != templates (Score:5, Insightful)
Templates were C++'s way of simulating generic types. The difference is that templates are essentially macros in fancy clothing, and generate a different flavor of the class for every combination of type parameters, while generics are a much cleaner, more abstract construct, better grounded in the theory of types, which use polymorphism to achieve their genericity.
Don't know if that made any sense....
In any case, this will be a fantastic feature, and they're done a much better job with it than C++ did with templates.
Parent
Re:Yes, although generics != templates (Score:3, Informative)
That's one definition of generics, but hardly the only one in use in the programming world. "Polymorphism" is one of those fantastic words that has had so many meanings attached to it that it no longer means anything useful without further qualification. Templates in C++ can do a little more than boring old macros these days, too.
If you're going to troll, could you please at least provide some sort of supporting evidence? On paper, the Java implementation is similar to C++ templates but with the usual Java trade-off that some of the power is sacrificed to improve the simplicity. However, in this case, that leaves Java generics without several useful features, and consequently without the ability to do most of the useful tricks that leading edge C++ can do. How do you see Java's generics as better than C++ templates, other than being simpler, and using OO-style polymorphism (which isn't really a generics issue, it's a C++ type system vs. Java type system issue)?
Re:Yes, although generics != templates (Score:2)
"Generics" in this case means "type abstraction," which has been well-known to type theorists (the people who invent advanced type systems for programming languages and prove things about them) for some time. Type abstraction refers to the ability for a function to be "abstracted over types" by making the type depend on some input type in the same way normal functions are abstracted over values by making the function's return value depend on input values. There's a huge body of literature on this topic.
Maybe more than boring old macros, but not more than exciting new macros! Seriously, if by "macros" you mean "C preprocessor macros" then you're right, but to a real Programming Languages Weenie the term "macro" means something much cooler. Some languages, most notably Common Lisp and Scheme, allow source rewriting in a much more powerful and less gawdawful way. The standard example of how powerful true macros can be is that in Lisp, you can implement an entire object-oriented programming system that appears every bit as built-in as Java's object-oriented programming system using just a user-written library of functions and macros. New class syntax, appropriate error messages, everything.
It turns out that templates are kind of a 'Vogon liver' phenomenon: in the same way Vogons had a mutated liver that evolved to serve brain-like capacities, C++ templates are a bad solution to the problem of type abstraction that mutated and became a bad macro system. Seriously, download a copy of DrScheme, read up in the help files about 'syntax-case', and watch yourself be amazed as you realize the power of macros done right.
Re:Yes, although generics != templates (Score:2)
Nah. The parent post was written by a standard, mark I "Java-biased C++-bashing weenie", a particularly tedious subtype of Programming Language Weenie whose sole purpose in life seems to be to post not-quite-accurate comments about C++ and Java with the sole aim of slagging off C++, whether or not said comments are actually relevant to the conversation at hand.
But thanks for the tip. :-)
By the way, I too am something of a programming language weenie, and quite familiar with the literature on formal type systems and such. However, I question the merit of even raising such issues in relation to languages such as C++ and Java. Neither language has a particularly pure type system, and it makes much more sense to compare and contrast corresponding features of those two (such as C++ templates and Java generics) than it does to have a dig at the fact that other languages have a theoretically sounder basis.
New and Improved for()! (Score:3, Interesting)
Re:New and Improved for()! (Score:5, Insightful)
I am in awe of the new for() statement. Java was designed to be logical and readable, but unfortunately for (String s : c) means nothing to most developers.
The JCP is a classic case of committee design: everyone has their own ideas based on their experience, and doesn't really understand the purpose or path of the Java language. Most JCP suggestions are calls for Java to look more like C++ or Python.
Parent
Re:New and Improved for()! (Score:4, Insightful)
Parent
Re:New and Improved for()! (Score:5, Insightful)
Parent
Re:New and Improved for()! BAD IDEA (Score:2)
One of the most important things in coding is readability. Frankly,
for ( String blah : bleh)
doesn't really say anything on it's own, the reason they call it a programming "language" is because it reads like a language.
"for , string c colon f " means shit.
"for string s equals c iterator
Please god don't butcher this language.
--noodle
Re:New and Improved for()! (Score:3, Insightful)
The fact of the matter is that it's a show of the weakness of Java that to add any feature- however small- the syntax has to be extended. More mature languages in the same/similar class as Java can achieve this without adding a new syntactical element everytime some little feature is requested. Smalltalk and Lisp manage fine. Hell, even languages that may be arguable as less mature as Java like Python and Perl can manage to add features without adding new syntax.
Also Concurrency/Memory/Threads/Isolation (Score:5, Informative)
There are some other interesting changes coming to provide a more coherent memory model [jcp.org], vastly improved concurrency support [jcp.org], and intra-JVM application isolation [jcp.org]. Java is getting much better at providing access to the capabilities of the underlying OS, and the JVM working more like a little multi-process OS itself...
Larry
Re:Also Concurrency/Memory/Threads/Isolation (Score:2)
Re:Also Concurrency/Memory/Threads/Isolation (Score:2)
Autoboxing (Score:3, Insightful)
Hmm... extremeley Microsoftesque. Much like VB5 and 6's variant data type and C#'s boxing rules.
Seriously, with a language like C you can feel like you actually know ALL the rules, and it makes you feel safe. With the beasts that are VB.net/VB6 and C#, and the one that Java is becoming, you always have that lingering "What If" in the back of your head. Seriously, you end up programming with the idea "Nah, they wouldn't let me make that mistake" constantly in the back of your head.
Re:Autoboxing (Score:5, Interesting)
I agree with you fully when it comes to VB and Java, but C# does not deserve to be lumped into this category. Everybody knows VB wasn't really "designed", it just sort of "happened" over the years. Java had a lot more design work behind it, but it still suffers from weird evolutionary lumps that always "feel wrong" when you're using it. However, C# went through a very long and intensive design period, with more well-defined goals than Java (the set-top-box language), and I believe with a LOT more R&D-phase input from the real world (as anybody who participated in Don Box's .NET listserv discussions can tell you).
C# is a lot like C in that the language itself is limited and well-defined, although not to the extreme basics of a 12-keyword universe like C, owing primarily to the additional keyword overhead needed to express certain modern concepts, many (most?) of which are OOP-related. In that sense it's a little like C++.
For an experienced programmer, the trick is to first understand the .NET class hierarchy (hint: avoid books that harp too heavily on web services buzzwords; web services are just a few pieces of the very large .NET puzzle). Next, understand the C# language on it's own. Most of the books out there seek to tackle both of them simultaneously, and that's a big hinderance to learning, and probably what causes people to make statements like that made by vandel405, above.
Don't judge the subject matter by the quality of instruction...
Parent
Re:Any recommendations? (Score:2)
Re:Autoboxing (Score:4, Insightful)
The price you pay is that you have to write a lot more rules yourself, which takes a lot of time (and hence money). The "beasts" as you refer to them (not that I think VB is a serious development language) do not require you to reinvent the wheel every time.
Yes, in C you can use libraries, but the more libraries you use, the more rules you have to know and the less you feel like you can know them all. Let's face it, programming is a complex task. Either you get the complexity out of a can or you provide it yourself.
Parent
Re:Autoboxing (Score:2)
Happy to see Java gain features. (Score:3, Informative)
I for one will like the new features Java is gaining. All too often when programming in Java for school (the main place I use Java), I often find myself wishing and wanting some of the features of C++. I've even gone so far as to write a perl script to allow me to create my own templates and have it convert the template to a proper .java file. Has anyone else resorted to this hack?
On the other hand, Java still is not my preferred language. C\C++ will probably always be my language of choice. They are what I learned first, what I enjoy programming in most, and which I plan to never quit using. Being able to use several design paradigm's is extremely nice, which is why my other favorite language is OCaml. However, I am still picking up its nuisances so things are subject to changing.
I would like to know, however, why the professors at my school bash C and C++. I for one can see the weaknesses of the languages, yet I can also find weaknesses in many other languages including the languages of functional and declarative paradigms. I think a lot of their disdain for C and C++ are due to memory management. However, manual memory management has never really been a huge problem with the way I write my code. Anyone else care to respond on if this is an academia thing to hate C and C++ or just my school? Perhaps all my teachers have their heads on tripods just like the people they complain about. Especially since, they do not work to try and improve the current programming languages.
Re:Happy to see Java gain features. (Score:4, Interesting)
Personal biases are, imho, always a good thing, as long as it's not BASIC. (sorry, couldn't resist)
The view here is that Java is by far *enforced* on most courses, although most lecturers I personally speak to seem to prefer Lisp/Scheme and C/C++ over Java. For instance, we had a course on data abstraction where the labs were in Java, but the lecturer taught in pseudo-code (claimed he didn't know any language other than C). Worked fine for me; I aced a project on image manipulation using only pseudo-code! B-)
Parent
Re:Happy to see Java gain features. (Score:2)
Color me goofy, but is the joke the whole line, or just the BASIC part? I thought it was just the BASIC part, in which case: how do you figure that personal biases are a good thing? I always thought of them as slightly-negative or possibly neutral, something which simply is.
Re:Happy to see Java gain features. (Score:2)
To take a natural language metaphor, I speak five languages, but prefer writing poetry in only two. I hope I'm making my point clear.
Re:Happy to see Java gain features. (Score:2)
Hitler killed people of many religion, races, creeds and sexual orientations, but he preferred killing Jews. I don't see how that illustrates the idea that strong personal prefs are good than your natural language example does.
Re:Happy to see Java gain features. (Score:2)
It does seem to be a popular academic past-time. I suspect it's similar to the slashbot groupthink effect. Most of these people have the luxury of working in a theoretical world, where the sorts of practical issues that make C, C++ and their ilk so useful are not relevant. They then reinforce each other's beliefs and preconceptions when they discuss things, without outside influence to put the opposite point of view.
A couple of the researchers at the computer lab where I did my diploma were like this. (The lab has several well-known names from the ML world there, BTW, and functional programming is very much their thing.) I also saw a few lectures given by others in the department that touched on C and C++, and they were pretty similar to what you see in bad books and uninformed comments around here: based on the languages of 10-20 years ago, and with no effort made to even investigate how things might have changed since then.
It's the old problem: academia produces some potentially very useful theory, but never does anything practical with it, while industry labours along using pragmatic techniques that are decades behind the times, because it's too scared to move away from known safe ground and investigate the applications of academic theory for itself...
Exactly. The question is simply whether the weaknesses are actually important to how you're using the language. The answer is very different for an academic researcher and a full-time professional software developer.
I think a very cool feature would be.. (Score:3, Interesting)
anonoymous inner classes can be used a little bit like blocks in ruby, only the syntax for anonymous inner classes is so verbose. Imagine this:
ArrayList list = new ArrayList();
ArrayList list2 = list.map(new UnaryOperation() {
public object call(object o) {
});
ArrayList list2 = list.map({ |object o|
It may not be possible because the exact interface to implement in the anonymous inner class would have to be derived from the method being called, which might be overloaded.
Anyway, I'd love to be able to use the terse rubyesque style in java, it feels a lot more declarative and communicates much better than all the explicit looping in java, c, C++, C#, VB, VB.net etc.
Re:I think a very cool feature would be.. (Score:2)
Thanks to C# (Score:4, Insightful)
C# comes out with a better language, and suddenly for the first time since inner classes were added in the mid-90's, the language starts evolving useful C#-looking features....
What I want next from Java is for Sun to invent delegates and properties.
Competition is a wonderful thing, and it's good to finally have some in the Java space.
Java# (Score:5, Interesting)
Autoboxing
the for-iterator [for(Sting s: Collection)] statement is actually "nicer" (in that intent is clearer from the code) in C# [foreach(String s in Collection)]
Generics
Enumerations
I propose they go full how and add the extremely powerful attributes from C# as well
In short
Re:Java# (Score:3, Interesting)
also, i don't think java is really "copying" C# features. you could say the same thing about most of C#'s features. in reality, both environments borrow heavily from years of computer science precedent.
Re:Java# (Score:2)
And using gcc instead of javac.
And writing in C++ instead of Java!
Yuck. (Score:5, Insightful)
- templates from C++;
- a new style of emun that does everything the Pascal enum does with a syntax that looks like a C enum except that it can have methods, AND MORE;
- a whole new foreach syntax that has the stellar advantage that the syntax doesn't resemble anything on God's green earth except Smalltalk, which is a pure prefix language like Lisp instead of an algol block language like C, C++, Java, C-hash, pascal or Ada (where the other features come from);
- generics using the template model from C++, which was a horrible hack on top of C++ because it was hard to make a backward compatible syntax (so instead we got ANOTHER class of macro to add to the #define) when C++ was a horrible hack on top of C so that at least C++ could compile C programs (except now it can't);
- a grammar that is going to be about LL(497) (doesn't anyone remember how ugly parsing C++ got to do templates, and how long it was before it worked?);
- and a whole wonderful new term ("autoboxing") for the notion that primitive types and class types ought to both have all the properties of types.
I know I'm probably just getting old, but Jesus!, why do we need to repeat all the mistakes of the past?Re:Yuck. (Score:2, Insightful)
Re:Yuck. (Score:2)
Re:Yuck. (Score:2)
anObject getsMessage: withArgument andAnother
is parsed purely left to right --
True, but irrelevant. A prefix syntax is one in which the operator precedes the operands. Smalltalk, like most OO languages, places the first operand, the subject of the method call, before the operator, and the remainder of the operands after, making it infix.
Compare that to a LISP version, say
Common Lisp's method call syntax is identical to the function call syntax, roughly (method arg0 arg1
To be fair, though, it's true that there is some infix syntactic sugar in SmallTalk: for example
a + b
is an alias of
a add: b
I fail to see why 'a add: b' is less infix than 'a + b'.
Covariant return types instead of full Generics (Score:3, Insightful)
overall, I'd rather have this than nothing...
What's wrong with a while loop? (Score:3, Informative)
Iterator i = obj.iterator();
while (i.hasNext()) {
}
If you need a count, then add it at the top or bottom (depending on need) -- This just seems like syntactic sugar gone awry.
Re:What's wrong with a while loop? (Score:2, Informative)
The problem is that i is outside the scope of the loop. However, it is only needed within the loop. If you don't have any other loops in the vicinity, then you are okay, but consider this:
Iterator i = obj.iterator(); ...
... ...
while (i.hasNext()) {
}
Iterator i = obj.iterator();
while (i.hasNext()) {
}
Whoops, this doesn't compile. There's a few ways out of this:
Iterator i = obj.iterator(); ...
... ...
while (i.hasNext()) {
}
i = obj.iterator();
while (i.hasNext()) {
}
The problem with this is that if you delete the first loop, you have the remember to change the second loop. (This is why reusing variables to do different things is not a good idea.) Here's another approach:
Iterator i = obj.iterator(); ...
... ...
while (i.hasNext()) {
}
Iterator i2 = obj.iterator();
while (i2.hasNext()) {
}
The problem with this is that you might forget to change all references from i to i2. Now consider the "standard" solution:
for(Iterator i = obj.iterator(); i.hasNext();) { ...
... ...
}
for(Iterator i = obj.iterator(); i.hasNext();) {
}
Here, each Iterator is in its own scope and you can easily refactor one loop without dealing with the other.
Re:Silly Java... (Score:3, Funny)
Wait, LISP programmer?
Ah yes. You can always spot them from far. May the Lambda be with you, brother!
(Btw, I completely agree with you. Always a challenge to move to bracy languages from LISP)
Re:Silly Java... (Score:5, Insightful)
The colon syntax is not random. It's well-known and well-understood mathematical notation, namely Zermelo-Frankel set comprehension notation:
Parent
Quit yer trollin'. (Score:3)
OK, OK, I'm just griping -- and I actually, I really like Lisp quite a lot -- but I do think that sometimes it's easy to judge by familiarity, and Lisp pundits seem especially guilty of that.
There's rarely a single One True Right Way of implementing a language feature; we really need to judge each implementation in the context of the language it's implemented in, and look for a clean, consistent, orthogonal, well-closed meshing of the feature into the language's feature set.
With that in mind, to your items:
(1) The new Java enums are not C-style enums at all (nor are they Lisp's symbols). They are a special variant of classes with a stronger class-level contract than normal classes (a fixed instance pool being the big one), an approach which works very well in an OO language with strong static typing. (For those of you following at home, Lisp is, for the most part, a dynamically typed language.)
(2) Lighten up. The for(x : c) syntax is lovely to a Java programmer's eyes, and fits the existing constructs well. Lisp's approaches, unsurprisingly, fit Lisp well, but wouldn't make much sense grafted into Java. I am glad, however, that Lisp also solves this problem. That is good to hear. Thank you for sharing.
(3) Java's original designers had two concerns: first, primitives are a potential performance gain; second, the semantics of arithmetic get sticky when integers can be null. Other language (e.g. Smalltalk) have addressed these problems reasonably well, but it's still a very debatable issue.
If I had it to do myself, I'd probably not have introduced primitive types. However, as a Java programmer, what really matters to me is that they pick an approach and make it consistent. The autoboxing JSR does a good job of adding convenience without breaking this consistency, IMO.
(4) The only similarity between Java's generics and C++'s is in the syntax. Java's generics are "true" generics in the sense that they spawn new types, and rest on polymorphism instead of a sort of specialized macro expansion. (C++'s more macro-like templates make sense for C++, where static binding would preclude many aspects of Java's approach.)
I'm not quite sure what your complaint about them not being "true" is supposed to mean. Perhaps you're worried about the runtime typing semantics of generics? If so, I'd like to see you hold your own in an argument with Gilad on the subject.
But then, what the hell do I know. I'm just a Lisp junky.
I think the answer is fairly obvious: you know a lot about Lisp, and not enough about Java to be as opinionated as you are. I know much more about Java than Lisp, and I'm sure I'm guilty of the reverse.
But I don't think I need to be an expert in either language to say that we should judge each in its own context. Does C suck because it doesn't have lambda expressions? (If you are tempted to answer yes, I hereby sentence you to writing device drivers for three years.)
Re:Quit yer trollin'. (Score:2)
Yes! Damn you Perl types and your "There's More Than One Way To Do It" heresy!!!!
One day, the great god S-expression will catch up with you and you'll get your comeuppance, mark my words...
Re:Silly Java... (Score:2)
There are two reasons off-hand that I can think of for autoboxing or whatever the hell name they gave it.
1) So you can pass-by-reference.
You can't pass primitives by reference in Java so the function:
void increment(int i) { }
is impossible to write. This is solved by wrapping the int in an Integer, because all objects are automatically passed by reference.
This feature is, of course, free in Lisp since everything is, in effect, passed by reference.
(defun increment (i) (setf i (+1 i)))
That works just fine in Lisp.
2) Autoboxing for collections, as they only take Objects.
This, however much I dislike it, will be solved by templates.
The variables and values with types stuff should have been listed under number 4, I believe, as it does apply with regard to templates and Collections.
In C++ and Java, crap like templates are necessary because the language will just take your word that a value has whatever type you say it has.
So, without templates, you have a LinkedList of what? void pointers?
So, now, whenever you iterate a collection you are getting void pointers. What type are they for real? Who knows. You'll just have to either guess, assume, or do lots of typeid() checks, because the language won't figure it out for you.
Given:
void foo(Object o);
void foo(Integer o);
Iterator i = c.iterator();
foo( i.next() );
It will call the first foo, because regardless of what value you put in the Collection, the Variable inside the collection that is holding it is of type Object. So, rather than the value specifying the type, it's the variable.
With templates this is "fixed" because it "remembers" what type your values were, assuming a homogeneous collection.
With real generics, like CLOS, this was never a problem to begin with as:
(defmethod foo (i) 'Unknown)
(defmethod foo ((i integer)) 'Integer)
(mapcar #'foo '(3 4.2)) => ('Integer 'Unknown)
This is because in Lisp a list is just a list. They could be anything. The list doesn't specify what type's the values are. The value's have their own types.
This is probably a poor explanation. I can try and do better when I wake up tomorrow if this made no sense.
Have a good night/day/morning/whatever,
Justin Dubs
Re:Silly Java... (Score:2)
I was familiar with incf, but just never realized that it had to be implemented as a macro. Your reasoning makes sense, and I tested it and you are right.
Thanks again, I love learning new things.
Justin
Re:Silly Java... (Score:2)
But the (unfortunately zero-modded) AC I'm replying too is correct that many people seem to confuse assignment to variables with binding of values.