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
Yeah - but lets face it, C# really sucks, and the only reason it's around in the first place is becasue Java existed. I use C# on a daily basis and HATE it. C# is just MS's bad hack of Java.
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
Whoops! Those angle brackets look like HTML to slashdot. Second try:
This works:
ArrayList<Integer> nums = new ArrayList<Integer>();
ArrayList l = nums;
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>
Generics weren't innovated in C#. The syntax is semi-borrowed from C++, while the constraining capability was borrowed from Eiffel. Both languages had this capability before C#, while Eiffel had it before C++.
Steve
remember Sammy Jankis
You're talking about C++. Generics in Java 1.5 is very different. Basically, Java generics is a way to avoid a lot of ugly casts when using collections like ArrayList and HashMap. That makes code more readable, and will catch more type mismatch errors at compile time. Nothing more, nothing less. That's a far cry from a "turing complete template/generics system".
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.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
You can package the SUN JDKs yourself very easily with j2se-package. Works very well for me. It has not been updated yet for 1.5, however.
The .NET libs are not off limit. The System.Windows.Forms namespace is proprietary (understandably so, it's Windows-specific). Aside from that, I believe all the .NET framework class library is available.
Generics are like the static (compile time only) parts of C++ templates. There's no equivalent of C++'s code replication.
I think this is a good thing: it's like Java only allowing multiple interitance of interfaces. Take the great bits of C++ and leave out the mad bad and dangerous to know (IMO).
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).
Hotspot checks your array indices, and if it figures that no bounds are broken, the checks are disabled. So if you loop over an array a couple of times, C and Java perform almost identically. You can easily check this by benchmarking.
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.
You actually said my best argument - lets say MS stopped distributing all .NET tomorrow and that Sun did the same.
.NET is a better platform - but because Mono looks better than any opensource java implementation.
BOTH groups would be basicly fucked - there is no REAL port of any of them - and from my point of view, Mono actually looks quite a bit more promising than Kaffe does.
If you asked me 1/2 year ago, I would definately put my money on java(and I do all my private coding in java - and has done it for the last 6-7 years or so), but now i start to be unsure - not because
Check out this paper for information about this other kinds of variance available in Tiger.
You can write a cast operator to get around this problem in C++. For example, here's a cast operator inside a smart pointer class:
This cast operator will only work with fairly intelligent C++ compilers, though. GCC and VC7.1 support it, but VC6 did not.
It seems to me that as time goes on, the JVM specification adds functionality that can possibly exclude it from being ported to other platforms. With this new release, the whole "Shared memory between JVMs".. I am pretty sure there are some not-so-advanced or alternate-goal OS's that doesn't support these kind of things.
Sure, maybe the blame can be put on the author of the OS, but I know that the "write once, run anywhere" vision is starting to slip.
Please go read the spec before jumping to conclusions. "Shared memory between JVMs" is an implementation change, not a specification change. It is not required, and indeed from a running Java program you can't even tell that it is happening. All that changes is that your memory usage is lower and your startup time is faster.
ZFS: because love is never having to say fsck
Look for mpkg-j2sdk (http://www.stud.uni-karlsruhe.de/~ude2/debian/) - it takes the .bin from sun and packages it up into a deb. Much easier...
Thus you have a lot more choice. You could be using Java on Mac OS X, Tomcat and PostgreSQL to power your website, or you could be using IBM mainframes with WebLogic and an Oracle backend.
This is my whole job. We run different product lines built of Java applications on everything from x86 Linux to PSeries AIX to zOS OPED Mainframes -- supporting tens of thousands of users. We developed one application and reused it in three environments, no recompile necessary.
Just out of pure interest, what do you use for your "low-volume" stuff?
My team uses JDK 1.4 with Tomcat and Apache running on Linux. I admit that we can't handle nearly the load that My Yahoo can, but low-volume for us still translates into ten million hits a day per server.
The high-volume properties like My Yahoo run a custom version of Apache on a custom version of BSD with a custom non-relational database backend. There is no off-the-shelf software that can even come close to handling Yahoo's traffic volume, unfortunately.
ZFS: because love is never having to say fsck
Although there seem to be specifications upon implementations upon specifications for eternity (pick something: j2ee, ejb, servlet, etc.), one of the great things is that _most_ of the time, you only need to dig as deep as you want. I've done Java development for over four years now, and only last month did I need to start digging into the EJB and J2EE specs for the first time.
.NET, you don't have that option. It's either M$, or M$.
.NET development, but if it is anything like the documentation for Visual Basic (Lord save us all), then as far as I'm concerned, it isn't even worth my time. Documentation for java (javadoc) is amazing, not to mention the 5 bazillion open source APIs that you can find to help you with your project, hudreds of which have fantastic documentation.
:)
The other great thing is that if you don't like one implementation, pick a different one! With
I also don't know what the documentation is like for
At least for the development that I've wanted to do, I haven't found anything that I couldn't do in Java that would need me to switch to another lanaguage for something. Java, for me anyways, is the ultimate development platform.
I also think the wallchart thing is a cool idea
java guy, tech blog...
It's nice to see that a Java site such as theserverside.com [theserverside.com]completely ignores Mozilla. Check it out for yourself...
What are you implying? The site comes up fine in mozilla based browsers.
Oh boy, that sure was insightful; thank you very little moderators.
Now, are you sure you don't miss things like:
Now, I'm not claiming Python is bad, or wouldn't have its part of programming world (although Ruby could replace it if necessary). But your zealous (and envious?) comment just outlines your ignorance. Right tool for the job, as usual.
Actually, C#, C++, and Java's OO systems are not conceptually similar to Smalltalk.
If you want languages that implement an OO system with semantics similar to that of Smalltalk, try Ruby or Objective-C.
All the systems do have inheritance, encapsulation, and polymorphism, yes, but beyond that they differ.
The former systems have very rigid 'static' type systems -- types are determined at compile time, and are verified by the compiler.
Smalltalk-like type systems are much more dynamic. Types, as such, aren't seen as being as important as the kinds of messages an object can receive. These systems have the disadvantage of requiring a small runtime to keep track of what object can receive what messages, but they allow marvelous flexibility, and lend themselves to quite a different style of programming.
It's interesting to note that the generics support that's been added to Java 1.5 is completely unnecessary in a dynamic language like Smalltalk, and, in effect, is an attempt to wallpaper over some of the unnecessary coding that a static type system require.
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!
Kind of funny, considering that Solaris is a derivative of BSD.
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.
They plan to implement all the .net libs, but admit that they may have to compromise on this if there are patents involved.
Free Java games for your phone: Tontie, Sokoban
AFAIK, There is no way to create an ArrayList backed by an int[], so you have to create an alternative class or use int[] directly, but naive programmers are surely going to believe that an ArrayList will be as efficient as an int[] when it will clearly not be.
So use Jakarta Commons Primitives instead.
A programmer is a machine for converting coffee into code.
I agree it's a PITA, but you can just copy the link URL and use wget -c [download URL]
That's what I do...
I work for a very profitable meta search engine that processes up to 800 requests per second these days--- we just hit 50M searches per day on Monday. I use Sun1.4.2 across three dual xeons running Linux2.4.20smp, and have seen a single machine handle 330 requests per second, with over 1000 active threads all competing for synchro locks, and using most of a 1.5GB heap. 20ms response time, vmstat reporting 50% idle.
And in the near future, I can expect even better things without touching a line of code (upgrade to 2.4.21-hugemem kernel, 2.6.2 kernel, 1.5.0 JVM). So it's not too slow for me. It *was* a lot slower when I launched initially, but as traffic grew, I just kept profiling it to find the next bottleneck, and optimized accordingly.
It is. Maybe you learned to make do without one but it is a pain in the ass. Don't even try convince me otherwise.
try remoting with IIS to achieve scalability and distributed performance.
Homogenous clustering is not always the answer. Heterogenous clusters utilise resources more effectively and some things simply cannot be built without them.
See, here's the crux of the problem with Microsofties. They want you to convert to everything Microsoft so that their new pet project will interoperate with their MS stuff. Yeah, most companies are going to ditch all their existing enterprise solutions just so that they can bring
Finally .net lacks real credibility in the enterprise
Throwing up a webpage with a shopping cart is not building an enterprise solution.
means that there arent enough good .Net coders in your company.
.Net is not ready for the enterprise I take their word for it.
We have many folks here who have 10 years experience coding on Windows and if they say that
Your pizza just the way you ought to have it.