Slashdot Mirror
Preview of Java 1.5
gafter writes "An early access prototype implementation of
the proposed new J2SE 1.5 language features is
available. The prototype includes
generics (JSR 14),
typesafe enums, varargs,
autoboxing, foreach loops, and static import
(JSR 201). In other words, all the new language features
planned for 1.5 except
metadata (JSR 175). The
prototype includes full sources for the compiler,
written in the extended language. You can download the prototype from
java.sun.com.
It requires J2SE 1.4.1 and provides some examples of how to use the new language constructs. The prototype includes an experimental type
system (variant type parameters)
for Generic Java that is being considered
for Tiger (1.5) based on a paper by
Igarashi and
Viroli at ECOOP 2002 .
Comments and votes for the new type system are
being gathered at
bugParade."
! But, . And finally, .
Just had to get that trolling out of the way. Now let the educated and well-formulated arguments begin.
While, as a java developer, I'm looking forward to most of these changes, I'm a bit afraid that java may lose it's positions as simple OO language which can be used for teaching in schools. Java was originally built with idea that you can read every java program in the world without problems. A lot of expresive power was sacrificed because of that - most notable preprocessor (to avoid people designing their own 'languages' for each project and library, as it is done in C).
Anonymous inner classes was first major ugliness which came into language - not very clear, hard to explain to a newcomer. But with all these new proposals, significant complexity is added to code in terms of visual overview. This is not critical for developers - perl hackers are faring very well, despite of having language 10 times as complicated as java as far as syntax is concerned - but pure-OO, java-is-new-pascal-for-algorithms academic society will probably start looking for a new language soon... (ok, maybe not really 'academic', I'm thinking more about secondary-level school programming basics).
Java can walk on water and I'm still not going to use it to develop anything I expect anyone to use. Give me a native optimizing compiler and I just might reconsider.
You mean like GNU gcj?
For languages that are intended for general purpose use and especially for situations where performance/efficiency is important they're just a BAD idea.
You seem to think that by compiling stuff to native code things magically run fast when the problems are actually library design, class loader design, bad memory management, and other issues. Java's JIT is about as fast as natively compiled C code and Java's lousy performance is living proof for the fact that making a great native code compiler is not sufficient for getting good performance.
Python and Perl programs often run rings around equivalent Java programs in terms of actual, end-user visible performance and memory usage, despite being interpreted. If anything, the compromises people need to make to make languages easily compilable into native code make it much harder to build efficient systems in them.
Of course, it's not like we needed any more proof of that: the inefficiency and bloat of systems like Windows, Gnome, and KDE demonstrate the same point, as did several generations of systems before them. And generation after generation of programmers repeats the same mistake you are making.
I'm surprised to see that there are still people out there which use 'interpreter' argument...
Anyway, there is a plenty of native compilers for java. I'm not sure if you have heard about certain compiler from free software group called Antilope or something like this - I think it is called gcc. They have a frontend for java, gcj, which compiles java source/bytecode to same intermediate stage as other compilers, thus sharing optimizing backed. If you don't care about paying few bucks, JET is very good compiler, written specifically for java, supporting 1.4.1. There is also few others, but I can tell only about these two from my experience.
Both these compilers are available for few years now. Problem is not with lack of native compilers, or performance of java in mixed mode offerred by Sun hotspot - problem is with mindset of poster. If you are not willing to use java - no problem. But please say it is 'religious' - everybody will agree with you, as you can have any beliefs you want. But do not try to back up religious statements with fake arguments.
isn't syntactic sugaring all about making code more readable? I think boxing , generics, typesafe enums, static imports make the java language more simple to use.
It's just looking over the fence to the "sibling" languages (c++, c#) and copy what they do better.
...because there's nothing like running a 2kb calculator and a 2kb notepad and both have them run on separate 10-15mb VMs. That is a real drag for any non-monolithic use of Java (yes I do know of servlets etc.)
Kjella
Live today, because you never know what tomorrow brings
There certainly is a tradeoff: If a language gives too many options to do one thing, it becomes confusing. A programmer usually develops a certain coding style. She prefers certain constructs over others. When you read code, you have to adjust to the style of the programmer who wrote the code, and possibly recognize constructs which you're unfamiliar with because they're not part of your coding style. Take the proposed for-loop extension as an example. Every Java programmer instantly recognizes the head of an "iterator for-loop". It's an idiom. The proposal adds syntactical sugar to supposedly help identifying this very frequently encountered situation, but it does the exact opposite: There are now two ways of looping over an iterator, and you have to be familiar with both if you want to quickly understand other people's code. If you want a good real-world example of what too much syntactical sugar does to a language, take a look at some Perl programs.
These additions seems to put Java on par with C#, but to make a quantum leap in expressiveness you need a dynamically typed scripting language.
Most applications these days can be written in higher-level languages, resulting in 5-10 times less source code compared to Java/C#, and making them correspondingly simpler to code and maintain.
Java doesn't really have a kick-ass companion scripting language. In MS world, VB plays this role. VB is really popular, but (I think most people would agree) a crap language and not really that high level. JavaScript just doesn't seem to cut it (pretty much only used in browsers).
Why doesn't Sun take a hint and phase JavaScript out in favor of a powerful multi-purpose high-level language like Python or Ruby? That'll put them miles ahead of Microsoft in terms of increasing programmers' productivity... and programmers' quality of life.
"Without seeing (in the Java source code) how the templates are implemented I can't say that I agree or disagree with your statement that they will be inefficient, though I'm inclined to disagree based on your example."
:-(
.NET you just store a 32bit value in an array, which is a single operation on most processors.
.NET templates will create a different class for each primitive type, so that primitive types will indeed be stored in their corresponding primitive arrays without creating objects on the heap. For classes, the .NET implementation behaves similar to the java implementation: There is only one internal class created for all reference types.
.NET does it, by the way.
Slashcode swallowed some brackets even though I was in text mode
What I mean is the following: If you create for example an ArrayList of ints, the most efficient way to store these ints internally would obviously be an int[] and not an Object[]. But even though java uses templates, it still stores primitive types such as int in an Object[], so there is a huge temporary object creation overhead. Whenever you store an int in your IntArrayList, a new Integer object is created on the heap and an old Integer object has to be garbage collected. In
The
"Templates or not, objects are going to be stored the same way. The difference is how those objects are retrieved. Right now you have to cast everything coming out of an ArrayList (unless the Object reference is sufficient)...not only is that being moved to the language but you also gain compile-time type checking. That will only serve to reduce errors and make the software more reliable. Templates are optional anyway - you don't have to use them. I'm looking forward to them."
Me too. It is not that I dislike the new features. I just think that they could have been implemented better, faster and earlier.
"I don't think you're ever going to see VM sharing. If applications can share VMs then one rogue app could bring down other apps by trashing the VM (never supposed to happen) or by poor thread management."
VM sharing does not mean that all java programs must run in one process. But for most desktop applications this would make a lot of sense. You are right about the thread management, but you could always restrict the number of threads an application can create. Just have a nice XML file which describes how much resources each application may allocate. That is the way
If sun will not do VM sharing, you will never see decent client applications written in java. Just think about it: for each java application you start, the whole swing library has to be JIT-Compiled anew. What a huge waste of processing power!
Private property is the central institution of a free society (David Friedman)
Java rarely wins in any particular niche. Relatively simple GUIs and COM objects are owned by VB (and Delphi). C++, C, and assembly rule in performance. Perl rules text processing. Python rules in ease of reading. ANSI C, Perl, Python may be more portable. Smalltalk, Eiffel, Lisp, Ruby, ML, Haskel, Forth, and a variety of others are a lot more true to a pure language concept. However, Java does an adequate job in most cases, and when you start crossing boundaries, it'll often be easier to do so in Java-land.
Java isn't innovative. However, it's constantly being improved. Sure, things like JDBC, Collections, SWING, NIO (async I/O), generics, threads, and concurrent garbage collection were available in some form elsewhere previously. They're all packaged into nice, free, portable, well documented, easy to use parts of Java though, and I'm happy to have them.
Java isn't as free as Emacs. However, it's mostly free as in beer, and it doesn't force it's freedom on you. It's certainly a whole lot freer than most things from Redmond. I admit, I don't care if a language is handled by a standards body, unless the company in question holds other monopolies it can abuse. I seriously don't think Sun is going to do anything so wacky as polluting the language to make COM (*cough* MS) or Object Pascal integration (*cough* Borland) easier.
Java's support base and (free) developer tools are just plain great. I love Eclipse, and IDEA and recent JBuilders are pretty nice too. VS.NET is good stuff as well, but contenders like Python are sorely lacking in this arena.
I still write plenty in other languages, but every year the percentage I write in Java goes up.. They keep filling holes (soft references, regexes, async I/O, .1s GC pauses) that were keeping me out of Java. I'm happy to see some more syntatic sugar in Java.. The things they're addressing will make a whole lot of code more readable.