Slashdot Mirror
Summary of JDK1.5 Language Changes
An anonymous reader writes "Over at java.sun.com, there's an informative article about the new features in JDK1.5. Some of the changes like generics are nice and should make some things easier. Some of the enhancements to me are purely sugar, like enumerators. When it comes down to it, once the code is compiled, it's the same. The thing I hope is, some of this new syntactic sugar doesn't result in more obfuscated code. Unlike some people, I feel using programming shorthand leads to increased maintenance. This is especially true when you have to debug a complex application."
enumerators are much better than just plain ints. Even though they may compile to the same thing, the compiler can do a little more checking on the enumerators, since it know the valid ranges for the enumerator so you don't have to explicitly check the range. You do check to make sure you get passed a valid value for all your int-as-enumerators? Don't you?
I think Generics is going to be a really nice long awaited feature. I am wondering if this type of change is going to require a modification to the bytecode specification. If that is the case, then new code bytecodes will not work with older bytecodes. Does anyone think that Sun can pull this feature off without a change to the bytecode spec? Would this be major compiler change?
...he's forcing improvements in Java.
668: Neighbour of the Beast
check out eclipse -- a very sweet java IDE.
http://www.eclipse.org/
I agree. This is why I never create my own functions or methods. Evey program should be just one big function.
The metadata, auto-boxing, enhanced iteration looks like catch up with C#'s attributes, foreach, etc.
Where are true properties though?
Emacs, of course. Syntax highlighting, integrated compiling, etc.
*puts on flamesuit*
http://www.xemacs.org ;-)
what more do you need?
If you want a *real* IDE, I'd check out IntelliJ's Idea product. It's a few hundred $$$. Lots of folks like Netbeans and IBM's Eclipse as well (sorry, no url to eclipse, but I'm sure you can find it). The latter 2 are opensource.
May no camel spit in your yogurt soup.
Eclipse is "the awesome." It's feature-filled and relatively easy to use. Being free is a nice plus, too.
My roommate told me about it, and once I started using it I never looked back.
GeekNights!
Late Night Radio for Geeks!
I feel using programming shorthand leads to increased maintenance
:)
My code was hard to write to it should be hard to read.
Hi,
FYI: Generics are _much_ more than mere syntactic sugar (as are enumerators, a weak form of algebraic datatypes, if handled type-correctly).
These are actually the kinds of things that make program maintenance considerably easier, since they allow more concise specifications of intended semantics to be done. No longer having to typecast (and thus expect run-time exceptions) when using a "vector of FooObjects" gives more power to the type checker, and thus allows a much richer class of programming errors to be detected at compile-time. This is the one major improvement in Java that's been missing since its very inception.
But note that "generics" or "parametric types" have been present in languages such as Eiffel or Sather for well over a decade, and for much longer in ML. In a way, it's embarrassing that such an essential feature was added this late during development.
Is anybody else irked by generics? One of the arguments in C++/Java discussion that I've read was: "Java removes complexity of C++, while remaining OOP". Well, generics remind me of C++ templates, which where a bit hard for me to swallow. Not to mention that attached to variable name doesn't make code any more attractive to look at.
It appears that Java's way to solve run time errors is to screw the bolts as tight a possible during compile time. Will generics become THE way, or just remain one of the options?
AFAIK they will not be breaking existing code... If anything, they had to go out of their way (e.g. the ugly foreach statement) to ensure backward compatibility. In 1.4, the assert keyword might have caused problems, but now I don't think that's the case.
These new java features or shortcuts whatever reminds of C++... Is Java going to come with "Pointer" manipulation features later on? Will java become the next C++ and will be extremely tidious to program with? Overall, change is good... :)
buffering...
Java adds four new syntaxes, Python's for loop, Perl type checking at compile time, something called 'metadata', and C enumerations, all of which impove compile time type checking at the expense of making the source code look and feel like perl.
I sure you have a valid point in general, but I'm not sure if this is a concern with the changes described. The description of the features in the article indicate to me that your concerns were taken into consideration. For instance, they explicitly mention that foreach and in weren't added as keywords to avoid killing programs that may have used these as variable names (kinda lousy variable names if you ask me, but I'm sure it happens).
Looking at the examples in the article, I didn't see anything that would break the semantics of already existing code... assuming the generics feature uses Object if no other class is used.
Do you have an example of the proposed semantics breaking some existing code? I would be interested in any examples and I'm sure the JCP would be too. I'm certainly not willing to go along with the JCP blindly if there is a practical, concrete example of where they are going wrong.
======
In X-Windows the client serves YOU!
Because the compiler, unlike the programmer, never makes mistakes, the resulting code is also more likely to be free of bugs.
That's right, none of us has ever seen bad code generation or an internal compiler error. But, he does have a point. The compiler is less likely to make a mistake than a programmer.
I might have missed something in the article, but as far as I could tell nothing existing breaks. They even mentioned that they worked very hard to make sure that was the case.
What part of the new syntax would cause old code to break?
I think the new additions are great (except, perhaps, the autoboxing stuff). But I'm missing a fix for that extremely common javabean convention: get/set methods.
/**
/**
/**
/**
To add a property, say a String called name you have to write:
* The name of this object.
*/
private String name;
* The name of this object.
*/
public String getName() {
return name;
}
* The name of this object.
*/
public void setName(String name) {
this.name = name;
}
That's 16 lines of code for one property! This is tedious to write, and more importantly, very hard to read when you have many properties.
This could easily be reduced to something like:
* The name of this object.
*/
property String name;
expanded to exactly the same code as above by the compiler. Incredibly useful if you're, say, writing a lot of value objects in a j2ee scenario.
#define FOREVER for(;;)
#define BEGIN {
#define END }
#define ONE 1
#define PUSHORT unsigned short *
#define DONE goto end
The first thing an amateur programmer does when assigned a new project in C/C++ is to go redefine the language and all the types. I scolded them for these kinds of things, knowing that once they were forced to read other people's code often that they would realize how stupid these kinds of things are. Unfortunately, once I started my career in embedded development, I quickly learned how stupid I must have been to think that people left these behaviors behind in college... (all the above examples are taken from "professional" code that I've seen in the last few weeks)
...just my 2 gil.
Java is an OK language for teaching programming basics, but it's just too much bondage and discipline for my taste.
You're forced to do object oriented programming. OK, I can respect that - but Java is not consistent. Everything is not an object, and it's just so damned ugly when you have to wrap an int in an Integer.
Also, it's statically typed. It's so fucking annoying to have to typecast everything - I know I have a damn String - quit holding my fucking hand!
Furthermore, Java's text processing abilites suck so bad, I don't even know where to begin.
Give me Python any day. It can do any job Java can do, and probably better.
It sounds like C# uses a lot of stuff from Ada (and I'm sure countless other languages), but forgot to honor prior work. :-)
Seriously, the "C# copied from Java/Java copied from C#" argument misses the point. There's a lot of prior work, and finding the right balance between usability and clutter is difficult. As much as I loved writing stuff like "for (value'range) do..." I would rather see a conservative approach to features since it's always easier to add stuff than remove it.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Some of this other stuff has been going on for ages - I'm curious about the metadata/declarative programming features. I've developed complete code generation systems for Java - the number of situations that require reams of very repetitive code in your average large-scale Java app is huge, and much of that can be automated. It would be great to see a consistent, standard system for doing this built in as a language feature rather than having hundreds of home-rolled systems everywhere, but the nature of many problems lends themselves to home-rolling. I can't tell you how many times I've written simple SAX parsers that spew out Java code, and rolled up an ant target to run it on some schema and package up the result. It's not clear from this brief example whether this is only for XML/RPC or whether there's an extensible metadata system that you can build on top of.
Then again, we should be careful not to roll too much into the language itself. I think generics, autoboxing, and enumerators are fabulous. Iterators I could give less of a shit over. Other stuff is great, but I question whether extending the language is the right mechanism. Much of the power and flexibility of Java comes from its simplicity. And most importantly, the ease of reading other people's code - there's far less stylistic variation because there are only N ways to do a task, rather than N! ways to do it, like in C++ (don't get me wrong, for a lot of tasks, I'd never dream of doing them in Java, like 3D programming). But it takes me about 1/4 to 1/3 the time to assimilate and learn a new Java API or library as it does to learn your average C++ API or library, and that's the appeal of Java.
Of course, I'll be thanking the gods that I never have to deal with the fugliness of casting and wrapping to move stuff between typed arrays and untyped Lists again.
As others have pointed out, moving move type information into the declaration allows the compiler to help eliminate several kinds of type errors generated by programmers.
Now, if you want a weakly/dynamically/non-typed language, you should use one, and deal with the inevitable tradeoffs. It's not like there's a shortage of non-strongly-typed languages out there.
While eclipse is great, Netbeans has more features. I prefer eclipse because it uses a native interface and has refactoring. The most feature-rich IDE I've used for Java, however, is netbeans. If you don't mind a slow user interface it's a great tool to look at.
Developers: We can use your help.
As a pro Java developer, I want to use the native 'int' type in order to save memory, have less garbage collection, and perform better. Catching errors at compile time is helpful too. I think it is unreasonable for Sun not to include specializations for native data types. If I want to have an ArrayList of 10,000 ints I should be able to use 'int'.
The link on this page states up to 10x performance but I've seen it work up to 30x performance - and you can run the code below to see this for yourself.
NOTE:
30 = 7272727/236966 where:
1. 7272727 = 2nd iteration of Int2IntHashMap!
2. 236966 = 15th iteration of HashMap (Hot spot had 12 more iterations to optimize)
http://fastutil.dsi.unimi.it/
package com.wss.utils.test;
import java.util.*;
import it.unimi.dsi.fastUtil.*;
public class TestFastUtil {
public static void main(String[] args) throws Exception {
int count = 400000;
int timerCount = 20;
long start, end;
Integer tmp;
HashMap hashMap = new HashMap(count);
for (int timer=0; timer timerCount; ++timer) {
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
hashMap.put(new Integer(i), new Integer(i));
}
end = System.currentTimeMillis();
System.out.println("HashMap put(Integer, Integer) count:" + count +
", put/s:" + (count / ((float)(end-start) / (float)1000)));
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
Integer in = new Integer(i);
tmp = (Integer)hashMap.get(in);
if (!tmp.equals(in))
throw new Exception("failed equals()");
}
end = System.currentTimeMillis();
System.out.println("HashMap get(Integer) count:" + count +
", get/s:" + (count / ((float)(end-start) / (float)1000)));
}
timerCount = 100;
Int2IntHashMap int2IntHM = new Int2IntHashMap(count);
int j;
for (int timer=0; timer timerCount; ++timer) {
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
int2IntHM.put(i, i);
}
end = System.currentTimeMillis();
System.out.println("Int2Int put(Integer, Integer) count:" + count +
", put/s:" + (count / ((float)(end-start) / (float)1000)));
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
j = int2IntHM.get(i);
if (i != j)
throw new Exception("Int2Int failed equals()");
}
end = System.currentTimeMillis();
System.out.println("Int2Int get(Integer) count:" + count +
", get/s:" + (count / ((float)(end-start) / (float)1000)));
}
}
}
Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ (Java Web Startable)
...especially since the assert keywork is, on Sun's JDK, only compiled to a bytecode construct if you request it be at compile-time.
It'd be about time Sun ported it to FreeBSD (the ONE thing lacking from it) but as you know, FreeBSD is dying so why bother.
This isn't the forum for a detailed discussion, but I actually prefer enumeration classes now over simple enumerations. The basic idea is to write a class something like:
final class Color {
String c;
private Color (String color) { c = color; }
String toString() { return c; }
static final Color RED = new Color("red");
static final Color BLUE = new Color("blue");
static final Color GREEN = new Color("green");
}
You can then treat this class like a type-safe enumeration. It doesn't have all of the nifty features that you'll see in languages like Ada, but it has the nice property of allowing you to attach whatever information you want to the enumeration class.
You can also use this approach to create self-initializing classes, e.g., a list of states (including full name, postal abbreviations, shipping zone, etc.) from a database. You can access the enumerated values through a collection class, a "lookup" method, or even reflection.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
One of the coolest new features of JDK 1.5 is the completely reworked concurrency stuff (JSR 166). I just listened to Doug Lea (spec lead) give a talk on this very subject and I'm pretty convince this will rocket Java performance way up for a lot of the collections stuff, concurrent programming, etc.
/ oswego/cs/ dl/util/concurrent/intro.html
:)
Bascially, the goal of JSR 166 is to do for concurrency programming what JDK 1.2 did for data structurs (Collections stuff). The gist is, you'll never need to use "new Thread()" or "synchronized" anymore, but rather you'll execute Runnables, use Locks and Semaphores, etc. Also, queues are *completely* reworked to be ultra scalable.
JSR 166 is based on Doug's concurrency package:
http://gee.cs.oswego.edu/dl/classes/EDU
OH, and there will be classes like AtomicLong which guarantee atomic 'compare and set' options for primitives.
Cheers!
Interested in Generics?
A Compiler for generic Java has been available for years:
You can check out Pizza/GJ here or here
Generics
The new Java generics are really weak compared to C++ template support. This is probably partially due to difficult in compiler support and also complexity (templates are without a doubt the most complex feature of C++). I was disappointed though in Java generics mainly due to lack of any kind of specialization support and also about the strange paradigm used for Iterators (instead of an iterator being class defined with a consistant interface, it's an external class that just behaves that must wrap a behavior around the class).
Enhanced for loop
This is for_each() in C++. Now, with for_each, you have to use function objects which is arguable as to whether it's more readable. Fortunately, Boost has developed a boost::lambda class that allows for code to be used as the third parameter. This is _really_ neat.
Autoboxing/unboxing
I presume this means that primatives can't be used in generics.. That's kind of sad. This isn't a problem in C++.
Typesafe enums
This would be a nice linguistic pattern to have in C++. As it stands, the equivalent would be:
struct Coin { enum { penny, nickel, dime, quarter }; };
Static import
This can be achieved via using in C++. Of course, Java doesn't even really have a namespace paradigm so it's not really a fair comparision.
Metadata
This is.. well.. strange. I didn't see the syntax for doing something like this. If it is just keyword/code replacing, then an #include directive would work just as well.
int func(int a);
func((b += 3, b));
AC, I agree that the current approach is a PITA. I would also be very happy to see a more terse way to express properties. But what you are doing in your example, is throwing the baby out w/ the bathwater.
Note that you now don't have anyway to specify access and protection! I had given a little thought to better ways to handle this, and even had an interesting brief email exchange w/ a C# engineer about it. For the protection aspects you could do something like [this is just a quick idea I cam up with:]
property access String name;
where access is one of {read, write, readwrite}
But note taht right away you have a problem -- no way to assign protection levels to the various access, which is really a cross-product. What happens for example if you want the getter to be public, but the setter to be private?
Also, note that you would also need semantics to handle overriding the property accessors. You could just say that the property access defines an equivalent to the getter and setter methods, but that can get weird and confusing very quickly. Think about the situation where you have an interface defining getters and setters and then you implement it by just providing the one-line property definition. That would not be very transperent TSTL.
All this is just to say that it is a noble goal, but not as trivial as it sounds at first glance. IMO, the C# "solution" is particularly ugly, and qualifies strongly for the "syntactic sugar" label.
FInally, as in my other note, good IDEs like IntelliJ provide very convenient ways to auto-generate these things. I care much less about this issue now that I am not having to type all this stuff out by hand!
This looks to me like they are changing a language so that existing apps no longer compile which is a bad idea.
Huh? Where did you see that?
It looks like they're making changes so that new apps won't compile on older compilers, not that old apps won't compile on newer compilers.
They risked a backwards compatibility problem when they introduced that "assert" keyword in 1.4 but there is a compiler switch to turn it off if you have variables with that name. Before that, they haven't messed with the syntax since 1.1, when they added class literals (syntactic sugar) and inner classes (a major change). The new syntax was so bizarre that no older programs were affected. I don't see how the 1.5 changes are any different. Some of them look like a cat walked across someone's keyboard.
My company is stuck with having to support Java 1.1 because of Mac OS 9. (In fact, according to our demo download stats, the number and percentage of Mac OS 9 users is only going up.) So we use modern compilers when developing (no decent IDE works well with 1.1) but the nightly build script uses 1.1.8.
Inner classes were an immense change compared to most of this sugary 1.5 stuff (except generics). Work here a few months and you learn about all the bugs in the 1.1.8 compiler with respect to inner classes. There are a number of perfectly legal constructs that get flagged as errors. But I bet the same kind of thing will happen with generics.
In my mind, this is _exactly_ the kind of thing that should be avoided in Java and that has sown so much confusions and monkey-business in the C++ community. Yea, you _should_ be defining those interfaces and abstract classes. That's why they call it OO. :D
Personally I like strong typing. The current approach of casting to (implicitly) and from (explicitly) Object violates this. IMHO, static typing saves far more pain in the long run than dynamic casting. If you like the general language, use JavaScript if you want to throw all that away.
When it comes down to it, once the code is compiled, it's the same.
If you're compiling, shouldn't you use a language which wasn't designed to be interpreted?
This is what he said about Java and the likes.
Also here.
From the article: "... you'll have to get used to providing additional information in declarations. Instead of merely saying:
List words = new ArrayList();
You'll have to say:
List<String> words = new ArrayList<String>();"
The way he says "you'll have to" suggests that old collection class construction might break. Let's hope that something like new ArrayList<Object> becomes the implicit default if you don't otherwise specify a type.
x++ is the standard way of writing the statement, used by most coders in preference to ++x (in my experience anyway.) The fact that there is such a convention is reason enough to use it IMHO; if I see ++x in a piece of code, it's a warning that something unusual is going on.
As for your equality test examples, putting assignments in if statements in Java gives you a compile error. Also, it's quite rare to ever put a specific number in an if statement, and if you do it's likeley to be 0.
One of things that makes older more mature languages like Common Lisp (and perhaps Smalltalk) nice to work with is a feeling of both having really solid implementations and not breaking legacy code.
I like the idea of boxing and generics, but, these changes will affect old code (probably?) and the platform in general.
My vote would be to freeze the Java language (perhaps after 1.5) and concentrate on the following:
I would not like to see Java become a language designer's playground.
Because of great infrastructure software like servelt/JSP containers, (perhaps EJBs :-), XML utilities, solid web services support, etc. Java is a great platform.
Leave it alone (the sooner the better) except for improvements in the implementation.
-Mark
I've been using Java for most of my projects for years because it didn't let you get away with many of the confusing things that you can do with a preprocessor. I may sound like a big geek for this, but I was actually weeping while I read the article. JDK 1.4 broke the ice with the assert keyword and now everything bad about C++ is going to pollute Java.
To the many cooks who spoiled the broth: "Thanks a lot, assholes."
... but man do I hate the enhanced for-loop syntax. At some point you have to give up perfect backwards-compatibility for readability. One or two new keywords would do a world of good.
for (TimerTask task : c)
task.cancel();
becomes
foreach (TimerTask task in c)
task.cancel();
Thanks a lot Sun for posting absolutely no information about the progress of this JSR. At least Doug Lea has posted a little information.
what if microsoft buys sun?
.NET, and Solaris is the biggest commercial competitor to Windows Server.
What happens when matter meets anti-matter?
1) Microsoft wouldn't have a clue how to manage Sun. Sun is a hardware-engineering firm with a different corporate culture than Microsoft.
2) Most of Sun's employees would either quit or sight tight until they can quit.
3) Sun's customers would leave for IBM or HP; they would not eat MS' dog food.
4) The Justice Dept. would actually do something for once, because J2EE is the only big competitor to
what if ibm buys sun?
Bye bye, UltraSPARC. This would probably alientate lots of Sun customers.
Java would cease being as open as it is. The JCP would close down.
Healthcare article at Kuro5hin
Aside from the opportunities for abuse of operator overloading, I don't think it's really that important in Java since it was never intended as a language for anything heavy on calculation (being interpreted and all).
This space intentionally left blank.
There was a preprocessor named jpp floating around a few years ago that supported operator overloading for Java. It seems to have vanished off the net in the meantime, though I'm sure I have a copy somewhere. True operator overloading is supposed to be added to Java at some point, IIRC.
In the meantime, perhaps we should write a new preprocessor, the "Operator Overloading Preprocessor System" or OOPS. jpp seemed like a good idea (it offered several features beyond operator overloading). Java coupled with a good preprocessor is a fine idea. ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
memory leaks (StringBuffer ToString anyone?).
Sorry, not a bug. What happened is the JDOM folks (gambling) relied on the internal implementation of StringBuffer and not its public API. That also broke JDOM for 1.2 jvms, which implemented StringBuffer differently. The internal implementation changed in 1.4.1, hosing the JDOM folks. Sun's only mistake was making this change in a minor version instead of a major one.
"And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."
Do you like seeing "public void setX()...public int getX().." a hundred thousand times to implicitly declare a bound property? Or would you rather see "published int x;" (to steal a line from C#) and be able to refer to x by field name rather than accessor method? I think simplifying code like this is a good idea. However, there is a dilemma created herein, as the example below will illustrate!
Thought Experiment #1
Assumption: Maintenance cost is directly correlated with program size.
Therefore: The more terse the language grammar, the easier programs written in the language are to maintain.
Thus: Perl.
At that moment, the programmer was enlightened.
http://www.intellij.com/idea/
...richie - It is a good day to code.
I'm not sure how locks and semaphores are a step forward from monitors, which is what "synchronized" represents.
Are you claiming "synchronized" is inefficient? Did you see the developerWorks article?
Are you claiming that such a high-level structure as a monitor is unnecesary for real programmers, who know what they're doing and will never screw up using synchronization primitives?
John.
" I feel using programming shorthand leads to increased maintenance."
False.
Shorter code and more powerful idioms makes a program *easier* to debug.
Too much code makes the purpose lost in the noise. Consider:
foreach (@array) {foo $_};
and
my $i;
for ($i = 0; $i < $#array; $i++)
{
foo $array[$i];
}
(I use Perl here since it is well known and I can show the 2 idioms, but really Perl isn't the clearest language of all). One form is much clearer and reveal much more eloquently what is the intent of the code.
Of course, this doesn't mean that shorter code "at all cost" is easier to debug, it means that "less code" is better.
Oh, and also it pisses me off when management tells me I need to use only certains idioms in case someone comes over my code and don't understand it. I hate to have to program like the next maintainer will be clueless and ignorant.
cheers
It's interesting the problem they were having with unboxing. Right now a null pointer would return a int value of zero, rather then throwing an error.
Actually, I think that's a bad idea, since you wouldn't be able to tell a zero you put in a collection with one that you didn't. Personally I'd like to see this as an option, somewhere. perhaps as a parameter to Integer, so you could do Integer<0> or Integer<null> to chose the behavior of the class. The problem there is that it's not obvious what a parameter to integer would do. Although I suppose you could use an if statement.
Personally, I wished they would have thought up a more interesting way to do generics then the C++ model. I wonder if this is going to give us the full range and power of C++ templates in java.
autopr0n is like, down and stuff.
Typesafe enums. That alone makes me quiver with happiness.
You don't get out much, do you?
(Score:-1, Wrong)
I guess you didn't RTFA. Introducing a new keyword breaks programs that happen to use that as an identifier. They broke JUnit when they introduced the assert keyword, and having been burned once, learned something.
I often also enhance myself with sugar.
You know, I've just got to say this.
Each and every point on this list of additions to the languages addresses problems that I have personally run into in my use of Java at work. These things will make the writing and maintenance of java projects small and large much, much easier.
Generics: Thank you God, yes! Having to explicitly cast objects out of Containers is tedious and error-prone.
Iterators/Enhanced 'for': Make iteration much easier to read and understand.
Autoboxing/Unboxing: This helps alleviate the enormous kludge that is the Object/primitive dichotomy. Casting to and from wrapper types just to pass ints, etc. around really sucks.
static import: Not having to fully specify tedious class names to access static members is a big boon for making stuff digestible and easy to read.
Metadata: Writing boilerplate sucks the big one. How many hours have I lost writing boilerplate? Way too many. Having language support for generating code from the metadata cuts my implementation times way down.
I could sit here and argue with folks about the 'new Java' versus C++ or C# or Smalltalk or whatever endlessly. But man, these things sure make Java a whole lot more pleasant to use.
-- Flaw
I consider it to be on par with FrontPage.
Harsh.
Very cruel man.
"Live Free or Die." Don't like it? Then keep out of the USA
It makes me really sad to read this. Java is a long way behind the state of the art for expressive power. These changes are welcome but Sun are presenting them as though they are innovative. Three lines to remove the four character strings from a collection? Look at it in Python:
/= 4) list
filter (lambda x: len(x) != 4, list)
If you object that Java is doing type checking, and Python isn't, look at it in Haskell:
filter (\x -> (length x)
Time to move on I think...
For the gaping holes and pitfalls he has created in C++. Everyone who has read books from Effective C++ and Exceptional C++ series knows this. In Java or C# you've got to try to shoot yourself in the foot, in C++ this comes by default, you don't even have to do anything. Some insanely simple situations shoot you in the foot so bad, it's not even funny. Not that C++ doesn't have its uses, but its usage should be limited and punished for. Thanks to Bjarne's "excellent" design, devs punish themselves every time they use the language for something non-trivial.
my favorite language (extension) for the vm has always been pizza. It gives you said generics, but also
- first-class functions and
- algebraic types (think functional pattern matching)
all three compatible with the original jvm 1.0 specification.But to be honest: this seems to be a real great step for java. programmer with a certain need for aesthetics (and self regard) can now really use this language...
They need to include an option to not include bounds checking in arrays. Right now Java is becoming very popular in physics because it's easy to use and portable across systems. I know a lot of people in physics who program in Java and I've worked the past two summers as a summer student writing code for physicists. The biggest complaint both they and I have in the bounds checking it does. It's a great option for debugging, testing, and for running most applications. But when you are running a large program the overhead of bounds checks in arrays can be prohibative. Ideally I would like either a runtime or compiler option where you can specify to run it without bounds checks. Obviously this wouldn't be a good idea for a great many apps but it would be extremely useful when running an array heavy application that takes hours or days to complete.
I stole this Sig
This is exactly what the new Java enums do. You just get to type a lot less and you can use them in case statements.
autopr0n is like, down and stuff.
Arguably the most terrifying sig I've ever seen.
In the old days when people talked about Linux, there was an expression "What about the big pink elephant in the middle of room" and it was referencing the fact that Linux did not support truetype fonts and font aliasing. Now some of that has been fixed, but Java still has its big pink elephant. Here are some of the things that people don't talk about.
The memory foot print for loading Java is 20meg + and growing. I am part of a team that has been developing a complex Java application for the last few years and we have created about a 3meg library (and it probably does at least as much as the more popularily used Java classes). I have looked at some of the source code for the core Java libraries and it is clear that a good rewrite could reduce this footprint by a factor of 2 to 4. Currently, C# loads with a footprint of 2 meg to 4 meg. Most other scripting languages usually have engines that are about the same size. To put it simply, the base core Java libaries are unjustifiably large. Maybe if Java were truly open source this could be addressed, but of course Sun doesn't even believe in submitting Java to a standards board.
You cannot load the Java VM once and run multiple processes (note "processes", not "threads") from the same Java VM memory footprint. I hear that such a thing is becoming possible for C# on Linux. You would have to build all the core Java classes into a "DLL" or ("so" on Linux), but that shouldn't be so difficult.
You still cannot do basic OS operations in Java without writing your own JNI library. The one that stands out is the inability to get the ID for the current running process. The "nio" package has corrected some of these issues, but the "nio" package should be the "io" package instead of having two separate packages (similar to AWT vs. Swing).
Window focus handling is still terrible. Ever have two frame windows up, have a modal dialog pop up on one frame while you were looking at the other? The frame window without the popop modal dialog becomes unresponsive and the other frame cannot be reached by tabbing through the windows. Only if you are lucky and that window is still visible on your desktop can you successfully reach it. Also, if a user clicks on a button that generates a modal dialog, the frame is only locked out from user input once the dialog manifests. This creates the infamous "double" clicking problem.
Java's package management is still primitive. If you want to do anything more subtle then using the classpath to load in custom libraries, you have to write your own class loader. Having an auxillary file specifying parameterizable rules for class loading would be nice. It would also be nice if you could ask a running Java process what packages it had loaded (and metadata about them such as location and version). Compare this to C# (or the way some of the web server oriented scripting languages work).
Some of the basic core library functions have some major weaknesses. For example, the Hashtable should be written as a native object when using String lookup keys and also allow you to dictate the algorithm for creating hashes (ex: use first 8 characters, last 8, or middle 8). There should also be a non thread safe version as well as a thread safe version. The lack of such a natively implemented primitive object is one of the big reasons why some less cleverly implemented scripting languages (such as python) can beat Java in performance on many web applications. In general, the core collection classes should be implemented in pure optimized (down to the actual chosen assembly code) native code.
Many of the utility libraries are broken in fundamental ways. Send back a badly formed response to the HTTP library and you go into an infinite loop when it falls into its keep-alive/retry logic. Date parsing is still behind what is available in the C standard library. Locale specifications do not allow you to independently specify date formats, language, floating point format, currency format, and time zone. You get o
When will Java support shared jar files that work like shared objects or DLLs in operation systems?
IMHO this is one the main shortcommings of Java. Every jar file is loaded into every process causing a huge memory footprint and long startup times.
When playing around with some java shells, that only load classes once and simulate processes as threads, I saw simple swing applications load in 0.1 secs and other significant speed ups.
I was hoping for it in 1.4.x and now it seems it won't even make it into 1.5. I realize that it will be hard to implement this in a platform transparent way.
Unfortunately, this doesn't quite make Java competitive with C# yet. Major missing features are:
Also, Sun's patents on core Java technologies and the lack of a well-defined, open Java standard are still serious problems. The fact that Swing is de-facto part of the Java standard but that Swing is as ill-defined as the Windows API is another problem because it makes it hard to create open source implementations of Java.
An other awful consequence of operator overloading is that code like thisis unsafe, since the && may be overloaded.
(The above may not be valid C++ syntax. I left C++ for Java many years ago and I'm never going back!)
Don't forget about the JDEE!
I always get the creeps when I see if( xxx ).
It is as if "if" is a function putting the parentheses like that.
foo( xxx ) is a function call
if ( xxx ) is a statement which gets a block in parentheses.
I couldn't resist. I have to fight this good fight every day against some of my colleages.
In a strongly typed language, there are no cast operators, and hence no ClassCastExceptions. You don't have these even in dynamically-but-strongly typed languages, like Lisp or Python.
Java doesn't give you type safety, just type errors when you try to be smarter than the compiler, which isn't that hard. That is no surprise - it has been shown that proper type inference runs into the halting problem, by research on languages that at least try to be helpful rather than just annoying while maintaining static typing (like ML or Haskell). In this regard, Java combines the worst of both worlds, just like C and C++, even if it is otherwise better than them in almost everything.
Programming can be fun again. Film at 11.
Any language which cannot be redefined is, much like any programmer who says languages must not be redefined, fundamentally wrong. If you can't rewrite your language on the fly, then what good is it? :)
Signed,
A Very Happy LISP Programmer.
.
.
.
.
.
.
.
.
.
.
No, really. Redefining the language is one of those things which sounds like a bad idea, up until the time you learn functional languages. Once you grok functional languages, redefining the language becomes second nature to you: for any given serious programming task, you modify the language into a special-purpose language meant specifically for solving your problem. For instance, I wrote a crypto library in LISP recently, and I needed to do a lot of addition modulo 2**32. In any other language, I'd have to write a function to do the additions... in LISP, I just wrote a macro.
Redefining the language is an astonishingly powerful technique, and once you grok it, the idea of a language forbidding you the ability to redefine itself seems like an Apocalyptically Bad Idea.
All of these proposials have been around forever, I was attending talks on pretty much the same Generics syntax at JavaOne two or three years ago... and I've been using the same kind of enum classes since Java 1.1.
C# didn't add generics at the start as they were waiting for Java to solidify how to do them.
Also, Java has a bit more of a wait for new features since Java goes through a real standards body instead of just being defined by what Microsoft wants. And of course lots of real production code that can break if you get things wrong.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
who has to implement the new javac.
... wait, that would be me.
Uh,