Slashdot Mirror
Java SDK 1.5 'Tiger' Beta Finally Released
kingkola writes "Finally, after about two years of development, the Beta for Java SDK 1.5, aka Tiger, has been released. Features added in this edition include generics support, autoboxing of primitives, syntactic sugar for loops, enumerated types, variable arguments, sharing of memory between multiple VMs and a bunch of other bugfixes, enchancements, etc."
Link to discussion on TheServerSide.com
C++ had this way before. Next...
Ruby.. next...
Perl...
No, and not always very useful. It's just neat.
In the VM or in the java support classes library, i.e. j2ee.jar
-
ping -f 255.255.255.255 # if only
C# did not "innovate" any of these. It might well have implemented them before Java, but most of them were available in various programming languages long before C# arrived on the scene.
Here's a very nice PDF giving actual code examples of the new language features:
- Ti ger.pdf
http://www.javasig.com/Archive/lectures/JavaSIG
generics support
C# innovated this, and already has this in the spec
-- You got to be kidding me, try AdA 25 years ago, much less C++ if you want to talk about an OO language that had it first.
syntactic sugar for loops
"foreach": C# innovated and already has this, implemented years ago
-- Innovated? had been in scripting languages for umm, well since scripting languages existed.
enumerated types
Java didn't have this before? LOL
-- Heh yeah it's not really a horribly useful programming construct. In truth, I've seen way too many bad programmers abuse enumerated types to make thier code hard to maintain and difficult to modify. So woopde do dah.
C# is/was just a glorified MS copy of Java to begin with. I'd hope they would have added something on to an idea they ripped off that someone else already figured out the difficult solutions for.
The Java language, VM, libraries and protocols (RMI, J2EE) are all fully spec'd out. There are *no* proprietary pieces the implementation of which is forbidden by Sun. 3rd parties can implement to their heart's content.
.NET libs are off-limits, are they not?
On the other hand, MS always, always, always seems to take care to leave some proprietary poison pill in their work, so you can implement 99% of their offering, but w/out the last 1%, your offering is worth substantially less (if anything at all).
MS-Kerberos is my favorite example: all these bytes are yours, except these two over here. Touch them not.
I think Mono is another case in point: it's an implementation of C# and the VM (yes?) but the
(Consider me trolled. Oh well, it's been a while since I've bitten any hooks.)
John.
Are we talking about the same thing ? What's safer ? A Java collection that takes *any* object without type-checking, or one that's restricted to a particular type/subtype ? I know which one I'd take.
The compiler performs at 30% of it's former speed ? Not with the 1.5 beta release. Or the pre-release available last month. Or the generics add-in from last year. Have you tried these ?
Finally I've worked in the finance sector for the last 10 years. Nowhere are templates forbidden as suggested above. I'm desperate for these to be widely used to give the run-time object-typing security that Java has lacked in its collections. This is a huge gain in my book.
J2SE(TM) 1.5.0 New Features
J2SE 1.5 In A Nutshell>
Also here are some snapshots of the new and improved Metal Look&Feel and of the GTK+ Look&Feel. You can also see how much antialiasing of bright text on dark backgrounds has improved from (unreadable) 1.4 to (rather decent) 1.5.
Also, Swing seems to be much more responsive! It is therefore my humble opinion that this release is going rock Java.
Here is a more detailed look at what 1.5 has to offer.
Some of my favorites:
- Autoboxing and Auto-unboxing of Primitive Types
- Enhanced for loop
- Enumerated types
- Formatted Output
- Concurrency Utilities
- Improved Diagnostic Ability
- Desktop Client
[alk]
Generic is good, if you're smart enough to use them correctly. Let's take the List example.
The type checking is much weaker thus introducing new potential holes for error to slip through.
Plain wrong. With the current list, if you've got a list of Foobar, then each time you want to extract a Foobar from the list, you have to fool the type system with a (Foobar) cast. If what you extracted was not a Foobar, then you get a runtime error (which is exactly what a type system's supposed to avoid). Symmetrically, if you try to put an integer in a list of widgets, the compiler won't notice. These issues are adressed by polymorphic type systems.
You must make some assumptions about the used classes however verifying the correctness of these assumptions in nearly impossible.
Wrong again: basically, a type is the statically verifyable part of the assumptions you make about a value. Maybe you're confused with dependant type systems, that allow to parameterize a type by a value (e.g. an array by its size), and is indeed often undecidable.
The reusabilty "argument" is rubbish
It wasn't for OO, and it is even more false about generics. Obviously quick and dirty code written by coder with low to average skills is not reusable, because writing reusable code asks a lot of smartness, and smartness can not be provided by a compiler. OTOH, STL in C++ are highly reusable, but very few coders are able to produce a code of such a quality, and noboby knows a way to fix that human issue. Reusability is about few code, written by few wizards, and used by many average coders.
The above mentioned problems create new security holes.
I'd be glad to see any concrete example backing this assertion. Actually, the evilest type system feature is the cast, and genericity is the way to get rid of most of them.
Due to turing completeness of most template/generics systems the compiler is slowed down to 30 percent performance. More evil is that templates push the grammars into the Chomsky-0 type making secure (=100%) correctness checking impossible.
Is this a random association of "sounds-good" term you've seen in a theoretical paper, or some very old and approximative quotes from a lecture during which you played Tetris on your phone?
Turing completeness doesn't lead to "slow downs", it immediately causes complete undecidability. The whole point of a type system IS to be decidable, hence not Turing complete, as opposed to the values. Moreover, templates keep the language in the "context free grammar" category. Last but not least, correctness checking is not related to grammars: grammar is just about parsing.
In old languages like Lisps the use of generics is usually strongly discouraged [...]
You know why it's discouraged? because it doesn't exist! List is dynamically typed, so templates don't make much sens. I guess you're confusing with macros, that are, indeed, Turing complete and can arbitrarily mess up the grammer in unskilled hand.
I've really seldom seen such an accumulation of BS in a single post.
Um. That link shows Java as having 11132 projects - the highest number except for C++ (12686) and C (12706). Given Java's big uptake in commercial development and the fact that it hasn't been around and mature for as long as C/C++ (how far back do Sourceforge projects go) I'd say you've not really done much to disprove his claim. Java is certainly one of the most popular languages out there today, and might even be at the top of the heap.
Of course, I understand that Britney Spears is rather popular too...
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
I'm guessing that you dropped some text between angle brackets, and what you meant to say was something along the lines of:
It is indeed true that, though s contains only Integers, which are all indeed Numbers as well, you cannot make this assignment. The reason is that, though Integer extends Number, the new types you've created (ArrayList<Integer> and ArrayList<Number>) using the genericized code have no such inheritance relationship with each other that would allow such an assignment.In generics, when you instantiate a genericized class and specify a type parameter, you're effectively creating a new type. In the example of the ArrayList, an ArrayList<Integer> extends whatever object that ArrayList does, and implements all of its interfaces, but it does not extend ArrayList itself or any type-parameterized variant of ArrayList.
sev
but have you considered the following argument: shut up.
This is one of the most misunderstood aspects of the C# vs Java debate.
If you write code in Java, you can run the same compiled class files on any platform. In C#, any code you write MUST run on a Windows-supported platform under Windows, but because every .NET language compiles to the CLA (Common Language Architecture), they are all translated into a single, compatible language before going to bytecode. Meaning, you can interoperate between any .NET language, have C# functions call a C++ function (assuming C++ is a .NET supported language now or someday) and just have it work...no CORBA, no distributed programming, etc. Furthermore, the CLA common language provides stuff like garbage collection so you can neglect free() and delete() in C++ and not worry about memory leaks (just don't compile that code with a non-.NET C++ compiler). The grand vision here is that everyone using .NET is locked into the .NET framework running on a Windows platform. There's nothing open about that.
sev
but have you considered the following argument: shut up.
Why finally? For Java to support IPv6 on Windows, MSFT had to support it first and that didn't happen until Windows XP SP1. .Net developer and want to support IPv6, you're in trouble as you have to rewrite your application to handle both kind of sockets, not too hard for client side, much more of a pain on the server side.
Now that being said, the really cool part about Java supporting IPv6 on windows is that it actually makes it much, much easier for developers to add support for IPv6 on Windows. You see, Microsoft didn't provide a dual stack implementation which means an IPv6 socket can not talk to an IPv4 host. It's stupid and contrary to what the RFCs strongly recommend. So if you're a
Now, with Java, none of that, a Socket is a Socket and that's it. To make it better, chances are your Java application doesn't need to be modified, or even recompiled! Imagine that: your application was already IPv6 enabled and you didn't know it.
the JDK 1.5 compiler is 100% compatible with JDK 1.4
Unfortunately, you're wrong.
To use the new language features, you have to use the "-source 1.5" switch with javac from 1.5.0. That makes javac create bytecode that can only be used with JDK1.5 (see the javac docs).
BTW, check out this link for benchmark results. The only place the latest Java (1.4.2) did significantly worse than GCC, and skewed the results were in the trig functions. In fact, in the int math test Java beat GCC. Slow? I don't think so.
- If one can only read values of type C with A methods, then the relation is covariant, i.e. to get A<As> <: B<Bs> we need As <: Bs.
- If one can only WRITE values of type C with A methods (e.g. pass them as function parameters), then the relation is contravariant, i.e. to get A<As> <: B<Bs> we need Bs <: As. Counter-example:
- If parameters of such types can be both read and written, then you need both As <: Bs and Bs <: As, i.e. As == Bs. That's what happens with java. If you want your structures to be covariant, you have to forbid their modification (here, forbid to change the cells' contents).
If in some exceptionnal cases you want to enforce subtyping, it's up to you to use casts. But you cannot assume a bogus subtyping relationship without noticing it, therefore the type system did its job.Why are you stuck on that?
I'm running 1.4.2_03 update 3 on Debian Sid.
Download the Linux.bin self-extracting file. and install as root where you want it to be installed.
First do a chmod 777 on the .bin file as noted by Sun. It will extract a structure as 1.4.2_03/ I don't like that so I just moved it to 1.4.2/
$mv j2sdk1.4.2_03/ j2sdk1.4.2/
Set the pathways for your .profile. and root's as well, and every user who needs access to the tools.
Here are my settings:
#Java SDK 1.4.2 SDK Path Settings JAVA_HOME=/usr/local/SunJava/j2sdk1.4.2/
add JAVA_HOME to your export PATH list.
Your choice of where you want your install directory is your choice. I made everything from Sun under SunJava.
Now as root run update-alternatives. (Man page for more info about the following).
$update-alternatives --install /usr/local/bin/java java /pathToYourJ2SDK/bin/java 100
Repeat for javah, javac, jdb, javap, jarsigner, java-rmi-cgi keytool, etc underneath the Sun /bin directory.
Then run update-alternatives --all to make sure it has Sun's sdk 1.4.2 set.
Run update-alternatives --config java
$update-alternatives --config java
Make sure its set.
Check out this paper for information about this other kinds of variance available in Tiger.
I've seen some really complex explinations in this thread. It's really not that complicated. If an argument is of a certain type, the supplied value must be of that type. End of story.
So, let's think about inheritance. All ArrayList objects are List objects. However, not all List objects are also ArrayList objects. If you declare a variable as List, all anyone knows is that it is simply a List object, even if its initialized as ArrayList. You can, however, test for the type of the value ( getClass().getName() , instanceof , etc.) and then cast appropriately. So, if you are certain that your List variable contains a value of type ArrayList, you can down-cast it to ArrayList and pass it in.
By the way, at the risk of being too specific, here's a pointer when you're using the Java Collections Framework. Usually, you want to use the interface classes for your arguments and return values. Use List, Set, etc. for arguments and returns, not their implementations. The whole point of an interface is you don't care how it's implementing, you just care about what is implemented. In certain cases, you do care about the implementation. For example, TreeMap sorts the entries by key, where as LinkedHashMap guarantees the results will be kept in the same order as they were added. These properties are useful in some cases, but in general, use the base class whenever possible.
So, in summary remember or learn inheritence rules and the distinction between the type of a variable and the type of a variable's value.
Join Tor today!
The Java 1.2 JVM has incompatibilites with earlier versions. That is to say, bytecode compiled with a 1.2 javac wouldn't necessarily run on a 1.1 jvm. So think of it as Java Platform 2.
Java 1.5 bytecode is fully backwards compatible with 1.4 JVMs and 1.4 bytecode was backward with 1.3 JVMs (asserts would only cause library issues). I'd expect Java 3 to appear only if the JVM bytecode spec changes.