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."

Comments

For more information check out theserverside.com

[alenm]

Link to discussion on TheServerSide.com

Re:Why?

[jimbolaya]

Java is probably the most popular language today; undoubtedly within the top 5. And the Java-is-slow-C-is-fast myth is just that...a myth. Dynamic recompilation (HotSpot) in modern Java Virtual Machines can actually make Java as fast or faster than C. And forget not that you can write a slow program in any language, C included.

What Java is is a memory hog. "Hello World" can easily consume a megabyte of RAM. The shared memory will help this situation. (Incidentally, the shared memory idea was originally developer by Apple for Mac OS X. Apple worked with Sun, and donated code, to make it universal).

an annoying quirk

[Dogun]

A friend of mine is bitching about this: if you type a list, say ArrayList, you can't use that as an argument for a function that takes a ArrayList. He's tried casting it, it just doesn't like it. Anyone else seen something like this?

Re:an annoying quirk

[severoon]

I'm guessing that you dropped some text between angle brackets, and what you meant to say was something along the lines of:

ArrayList<Integer> s = new ArrayList<Integer>();
ArrayList<Number> t = s; // does not compile

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

Re:an annoying quirk

[Prior Restraint]

Like everyone else on Slashdot, TheSunborn didn't preview before posting, and lost a bunch of angle brackets that might have caused the post to make some kind of sense.

Or, maybe s/he's crazy.

Re:an annoying quirk

[derkaas]

You can, however, make use of wildcards to define a covariant inhertiance relationship between ArrayList<Number> and ArrayList<Integer>. We can reconstruct your example to create this relationship:

ArrayList<Integer> s = new ArrayList<Integer>();
ArrayList<? extends Number> t = s; //compiles

Check out this paper for information about this other kinds of variance available in Tiger.

Re:an annoying quirk

[Montreal]

And the answer is to do it like this:

ArrayList<Integer> s = new ArrayList<Integer>();
ArrayList<? extends Number> t = s; // compiles

However, now you can't put anything into the collection t (since the actual type might be, for example, an ArrayList of Float objects or an ArrayList of Integers) but it is guaranteed that anything you get out of it will be a Number.

Re:an annoying quirk

[rreyelts]

While that is true, Java 1.5 has a solution for this called variance - based on very recent programming language research:

ArrayList<Integer> s = new ArrayList<Integer>();
ArrayList<? extends Number> t = s; // This does compile

This capability is something you won't find in any other mainstream language, yet. C++ may never get this kind of capability.

Re:an annoying quirk

[Lao-Tzu]

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 template member function allows you to implicitly cast this pointer
// to a CRefPtr<someBaseClass>.
template <class newType> operator CRefPtr<newType>() { return CRefPtr<newType>(m_pPtr); };

This cast operator will only work with fairly intelligent C++ compilers, though. GCC and VC7.1 support it, but VC6 did not.

IPv6 for windows finally

[goodbye_kitty]

Yay, finally some proper java support for IPv6 in windows. Im not an IPv6 zeaolot or anything but its great to be able to write (careful) java.net code using generic InetAddresses and be pretty sure that it will work regardless of which version of IP your network is using.

Re:IPv6 for windows finally

[The Clockwork Troll]

You must mean JDK1.5 supports a 128-bit BigFuckingInteger type? Cool! I would officially like to indicate that "-1" in such a field means "INVALID HOST -- CONSULT VERISIGN SITEFINDER". Are you writing this down people?

Re:IPv6 for windows finally

[Anonymous Coward]

Why finally? For Java to support IPv6 on Windows, MSFT had to support it first and that didn't happen until Windows XP SP1.
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 .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, 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.

Re:Why?

[Jim_Hawkins]

It bothers me when I read statements like this. Maybe Java is slower than C -- it really depends on what you are doing with each language. For example, heavy duty graphics are not going to fly in Java. However, the portability that a language like Java has, the ease that it can be implemented and the support that it is gaining/has gained in the corporate world makes it a solid competitor.

Every language out there has its own advantages and weakensses. C is fast. It is powerful. The gaming industry will probably always continue to use it unless something exceedingly better comes along.

Java is stable. It is secure. It is very easy to code. Web developers and businesses looking to get multiple systems working together quickly and efficiently will continue to use that.

I don't pretend to be an expert, but from what I've seen, Java is definitely a good thing to have around.

Re:Too little, too late

[sporty]

generics support

C# innovated this, and already has this in the spec

C++ had this way before. Next...

autoboxing of primitives

C# innovated this, already implemented years ago

Ruby.. next...

syntactic sugar for loops

"foreach": C# innovated and already has this, implemented years ago

Perl...

enumerated types

Java didn't have this before? LOL

No, and not always very useful. It's just neat.

and a bunch of other bugfixes, enchancements

Bugfixes in a language? WTF?

In the VM or in the java support classes library, i.e. j2ee.jar

Re:Too little, too late

[kinga]

Grennis: C# innovated!
Inigo Montoya: You keep using that word. I do not think it means what you think it means.

Re:Too little, too late

[jimbolaya]

C# was clearly inspired by Java, so if Java takes back a few ideas from C#, I say its fantastic. And recall that they each are based, in syntax, on C, and in concept, on Smalltalk. Language designers learn and borrow from each other. All is good in the world.

That said, you do give C# much too much credit for "innovation." Microsoft may have a monopoly on a lot of things, but innovation ain't one of them.

Re:Too little, too late

[LordK2002]

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.

About time too

[DrXym]

This finally puts Java the language onto the same level as c#. While most of the syntax changes amount to sugar (the compiled code being the same), it is still welcom to see a proper enum at last. And things like generics should make it considerably less tedious to walk through collections (a bane of Java development).

Another change that caught my eye was a skinnable theme for JFC called Synth. I wonder if this will help Java capture some of the kewl market for media players etc.

I also see the beta is being made available for 64-bit Linux.

As a platform, Java is still miles ahead of c#. But I sometimes wonder if the message is lost amongst all the specifications and implementations of specifications. The .NET strategy has gotten some ill-deserved 'buzz' from managers who've heard the spiel without quite understanding the implications if they go that route (i.e. lock-in). Someone in Suns marketing department should produce a massive wallchart detailing everything Java can do, every major solution for it and arrows showing how they all join together and then mail it out to every CEO / CTO in the country.

Re:About time too

[Seahawk]

The .NET strategy has gotten some ill-deserved 'buzz' from managers who've heard the spiel without quite understanding the implications if they go that route (i.e. lock-in).

How is java less lock-in than ,NET? Both are closed products with free alternatives. Java has Kaffe, lots of small jvm's and classpath - .NET has Mono.

In my eyes you are about equally locked in - but people tend to hate .NET just because its MS.

My view is that c# is a bit more "clean" as a language, but the classlibrary is much more immature than the java classlibrary.

Re:About time too

[jlusk4]

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.

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 .NET libs are off-limits, are they not?

(Consider me trolled. Oh well, it's been a while since I've bitten any hooks.)

John.

Re:About time too

[Spoing]

1. How is java less lock-in than ,NET? Both are closed products with free alternatives. Java has Kaffe, lots of small jvm's and classpath - .NET has Mono.

While in general I agree -- the core implementations of both are closed source -- the two are entirely different when motivations come around.

Sun: Motivated to create a Java developer base and sell related goods on various platforms.

Microsoft: Motivated to create a C# developer base and sell related goods on Microsoft platforms (Windows NT and Windows CE lines).

While I don't entirely trust Sun, they have a much better history when it comes to trustworthyness.

All that said, the .Gnu and Mono projects are damn important. They are also doing a difficult task on an unreliable (and fluid) 'standard'^.

1. (^ - Standard sadly means "What's popular" to most people...they are wrong, though that's how they think of it. Ex: Windows and Word are 'standards'. )

Re:About time too

[DrXym]

You're not locked in because there are multiple JVMs and multiple implentations spanning multiple architectures and devices from multiple vendors. You are not compelled to use Sun hardware, nor Sun software if you want to use something else. Many of the core technologies are open specifications with open source implementations.

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.

With .NET your choices are made for you - Microsoft. Microsoft software on Microsoft operating systems on Microsoft supported platforms. Mono might be suitable for toy apps (not that Kaffe is much better) but it is never going to implement all of the proprietary things that .NET is comprised of.

Re:About time too

[Glock27]

How is java less lock-in than ,NET?

Because Java has freely available, industrial strength implementations on dozens of platforms. If you use it, you aren't locked in to deploying on any particular OS or hardware. (BTW, don't forget gcj in your list of "free" alternatives.)

.Nyet, on the other hand, leaves you with only Windows as a deployment option - it's not at all clear that Mono will be allowed to finish/distribute a complete cross-platform .Net implementation. Many important libraries aren't in the ECMA standards, such as Winforms.

I hope that helped clear things up...

Re:About time too

[Haeleth]

it's not at all clear that Mono will be allowed to finish/distribute a complete cross-platform .Net implementation

While the immaturity of Mono is the reason I'm looking into Java rather more seriously than .Net at the moment, I would like to point out that it's also not at all clear that there's anything Microsoft can do to stop Mono.

Remember that the only potential legal threat to Mono is Microsoft's patent portfolio. But even if Mono is infringing on something - and I haven't seen any evidence that it is - Microsoft do not have an extensive record of using patents aggressively. Their basic tactic has always been "embrace, extend, extinguish" - not "steal, sue, squash".

So the main threat to Mono is that the target will keep moving, not that Microsoft will try to crush them. But Microsoft will not be able to break .Net in too many incompatible ways without alienating their customers. And unlike SCO, Microsoft's business model relies on keeping their customers happy.

Re:About time too

[severoon]

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

Re:About time too

[Seahawk]

You actually said my best argument - lets say MS stopped distributing all .NET tomorrow and that Sun did the same.

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 .NET is a better platform - but because Mono looks better than any opensource java implementation.

Re:About time too

[Seahawk]

I have been a C# developer for a year and a half - and damn its frustrating to reverse engineer MS libs, because the damn thing is poorly documented.

But look at one of my other answers :)

And personally I love java - and has for about 6 or 7 years...

Re:About time too

[Tal Cohen]

Not true: If Sun drops dead, Java will live on with interested parties such as IBM and Oracle. Their agreements with Sun are such that Sun cannot simply pull off the product and prevent further development.

Re:About time too

[Morologous]

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.

Re:About time too

[Anonymous Coward]

I get the point how .NET developers would be screwed, but if Sun stopped distributing Java I could continue to use IBM's very high quality JVM, or BEA's JRockit, or Apple's OSX. No doubt one of the many others would quickly step up to fill the void. None of these can disappear at the hands of Sun. If .NET went away at the hands of Microsoft, it would likely disappear entirely because of its immaturity. Java, on the other hand, has reached the point where it could live on independently if necessary. If Sun or Microsoft stopped shipping a C++ compiler, the language would live on. Java has reached that point too.

Re:About time too

[humandoing]

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.

The other great thing is that if you don't like one implementation, pick a different one! With .NET, you don't have that option. It's either M$, or M$.

I also don't know what the documentation is like for .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.

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 :)

Re:About time too

[DrXym]

But what is .NET? Show me where .NET (in the CLR / C# sense) finishes and SQL Server .NET begins. Is it in ADO.NET or what? If you don't know, what chance does some clueless manager?

All they hear at the seminar is that ".NET has a portable runtime just like Java and offers an end to end solution". And then the brain disengages without detecting the ambiguity. How many ask for clarification - the runtime might be portable but has it been ported and what about the rest, is that portable and ported too? Of course any company switching over might learn their mistake when it is far too late to correct. This premise also presumes Java needs replacing when it rarely does for any reason, especially not to another runtime language.

Even the client side stuff in .NET like the Forms demonstrates there is no portability there. Look at the hoops that the Mono folks have to do to support it - linking to Wine no less. In other words, to implement Forms (and PInvoke) you have to emulate an entire Win32 API!

And there is the constant threat of harrassment hanging over the project if ever it gets too good for Microsoft's liking.

This is why I think mono is wasting its time really pursuing .NET libs. Support for semi-core libs such as Forms might be okay but draw a line in the sand. Offer a viable alternative in GTK# and other open technologies which give people no reason to use windows.forms. Better yet, implement plugins for Eclipse which make it easy to visually design and build apps for GTK# that run on any platform.

After all, DevStudio used to be a premier development platform but these days it is looking distinctly ropey especially for the fortune it costs. With a bit of coaxing Eclipse could do everything DevStudio offers but with the added benefit that the code it produces truly runs anywhere

Re:About time too

[tunah]

They plan to implement all the .net libs, but admit that they may have to compromise on this if there are patents involved.

Re:About time too

[Uksi]

In C#, any code you write MUST run on a Windows-supported platform under Windows

That's not correct. Next time, please say "according to blah, ...". For example:

According to the Mono faq:

Question 58: Can I develop my applications on Windows, and deploy on a supported Mono platform (like Linux)?

Yes, you can.

As of today, Mono is not 100% finished, so it is sometimes useful to compile the code with Mono, to find out if your application depends on unimplemented functionality.

So in short, yes, you can compile C# and C++ to bytecode under Windows and run it under Linux.

Although what you said about CLA (being able to call other languages' functions) is correct.

Re:Too little, too late

[LarsWestergren]

So, finally Java is finally catching up to C#.

Eh, considering C# is pretty much a clone of Java, I wouldn't crow to loudly about being first.

As for your specific points here, I think they illustrate that it is good that Java and C# are competing, both are striving to better themselves.

As for the trollish tone of your post, why take this so seriously? You are not your programming language.

Re:Too little, too late

[MSBob]

C# innovated this, and already has this in the spec

Bollocks to that. C# copied generics from C++ (which likely copied it from somewhere else) and so did Java. And they both (C# and Java) got it wrong and missed the point.

Java didn't have this before? LOL

Lack of enumerated types in Java has been a real pain in the ass as was lack of typedef.

Memory sharing between VMs is not so easy to do when you have umpteen platforms to support. Much easier when you have one like in .net.

What .net lacks however is more substantial. There is no API in .net for doing O/R mapping such as JDO or CMP (belch). There is no API for distributed clustered components like EJB session beans. MSMQ is only usable in the Microsoft world. JMS queues can generally be used to integrate with legacy systems. Java has a bunch of great open source tools for it like Eclipse and all its plugins not to mention the Jakarta project. .net has bugger all for a developers' community, unless you consider Microsoft's astroturfing a vibrant community.

Finally .net lacks real credibility in the enterprise. The company that I work for (biggest consulting shop in North America) has a strategy of using .net for quick several week hack jobs but the real projects are always done with J2EE.

Code Examples

[Dreamland]

Here's a very nice PDF giving actual code examples of the new language features:


http://www.javasig.com/Archive/lectures/JavaSIG- Ti ger.pdf

Saves loads of code

[cerberusss]

What is great about this, is that this saves loads of code. Lots of explicit typecasts can be left out now, there is a very short-handed for-loop, you can import constants, etc. etc.

I played with the alpha and gave a presentatation about it at my employer. Lots of people were enthousiastic.

Plug: java-1.5_new_features_en_v2.ppt

Re:Too little, too late

[jerkos]

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.

Exactly

[FatSean]

Linux, AIX, Windows. We can develop our J2EE apps on any of these platforms and they 'just work' on the other 2 with no extra work. It's glorious. Ever try to cross-compile a non-trivial C/C++ program. Yuck.

steps toward Python

[axxackall]

generics support, autoboxing of primitives, syntactic sugar for loops, enumerated types, variable arguments

Looks more and more like Python. All I need now to move from Python to Java is just same small size of memory footprint and ability to interprete the source code. No need to mention FP-things like list comprehensions. Until then - keep your coffe for your blind-dumb managers. I use a real language.

Re:steps toward Python

[----]

Have you tried jython?

"Jython is an implementation of the high-level, dynamic, object-oriented language Python written in 100% Pure Java, and seamlessly integrated with the Java platform. It thus allows you to run Python on any Java platform."

This means you can even run python on a palm pilot or a cell phone.

jython code can even be compiled into java bytecode (*.class files)

/* ---- */

Re:steps toward Python

[The12thRonin]

Python is not weakly typed. It is dynamically typed. But you knew this, and just made an honest mistake because you do real work. ;)

By your logic then, VBScript is ok since it does dynamic typing as well.

int foo = 5; char* bar = "duh"; foo = foo + bar; /* perfectly valid */

Yes, because char* points back to the ascii value for the character and not the string itself.

The best compromise is to allow both typing schemes - dynamic, unless specifically statically typed. That way, if I determine a bottleneck is due to dynamic typing, I can use static typing. Now that is something I would like to see in Java.

Wrong. People are lazy. Give them the easy way out and they will take it. Same debate we're having about .NET and Java now. .NET lets you get away with things that will blow up on you.

Re:steps toward Python

[hobuddy]

Dynamic typing being a Good Thing depends on the context. Dynamic typing tends to move more bugs which could easily be caught at compile time to runtime. This means more testing needs to be done which actually drives up development costs and thus negates any benefit gained from "rapid development".

Indeed, I find that writing test suites saps much of the development speed advantage I gain from using a dynamically typed language.

However, using a soundly designed dynamic language, I can write dynamic-implementation+test-suite in about the same time I could write only static-implementation in, say, Java. But since I have an extensive test suite, I end up with much more reliable code.

Re:steps toward Python

[NumbThumb]

The point is that the typechecking in Python is done at runtime (obviously). Having to *declare* the types of all variables/members/parameters allows to check for correct types without having to write test-cases that cover *every* possible path of execution (which, in general, is impossible anyway, especially if lambda-statements are involved).

Forcing programs to be type-save weeds out a lot of potential bugs beforehand. And it makes reading the code a lot easier.

Benchmarks

[SashaM]

Actually, 1.5 beta has been available for a few months now, but the link wasn't on the main java.sun.com page.

Here are some highly unscientific benchmarks of startup time I just ran on my Athlon XP 2000+ under Mandrake 9.2:

[sasha@jupiter tmp]$ time -p /usr/java/1.4/bin/java HelloWorld
Hello World!
real 0.30
user 0.22
sys 0.03

[sasha@jupiter tmp]$ time -p /usr/java/1.5/bin/java HelloWorld
Hello World!
real 0.17
user 0.16
sys 0.02

These are relatively consistent over multiple runs.

Re:Benchmarks

[SashaM]

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.

Re:"generics"

[PhrostyMcByte]

The type checking is much weaker thus introducing new potential holes for error to slip through.

In collections, generics make type checking much stronger. They allow you to find casting problems at compile time instead of run time by not boxing things to Object and back. This also gives a huge speed increase (about 300% in my tests).

In Response to C#?

[osewa77]

When I first learnt Java, I was so excited about the write once read anywhere functionality but many language features (or the lack thereof?) simply bugged me. Then I discovered C# and was happy to have found a usable Java - until I saw the probs Mono is facing porting .NET, particularly System.Windows.Forms, to Unix ... and the fact that they would always have toplay catch up, with no big company to support them (IBM, Sun and other Linux/Open source backers already have a huge stake in Java)

When I read about the proposed features for Java 1.5, I knew i could stick with Java for the long term. Good news!

Re:In Response to C#?

[alext]

even if .NET compatibility was completely dropped tomorrow, Mono woulc continue to be a great platform

Make your mind up. Either Mono "is an open source implementation of the .NET Development Framework" (www.go-mono.org) or it's a different platform.

You can't expect people to invest in something on the grounds that it's Dotnet compatible and then not care if it suddenly isn't.

Looks more like a naive yearning than a strategy.

Re:Too little, too late

[Anonymous Coward]

C# invented them? Are you sure?

> > generics support
> C# innovated this, and already has this in the spec

C++ and Eiffel innovated this. Generics have been available for Java for *years* in this implementation ( http://www.cis.unisa.edu.au/~pizza/gj/ ). It just don't get accepted into Java right away. (BTW, Generics aren't currently part of C#, are they?)

> > autoboxing of primitives
> C# innovated this, already implemented years ago

LISP, C, heck even PL/I implemented this years ago.

> > syntactic sugar for loops
> "foreach": C# innovated and already has this, implemented years ago

Python, Basic, Smalltalk, and Perl did this years ago.

> > enumerated types
> Java didn't have this before? LOL

The new enumerated types aren't simple integers, they're more like Ada enumerated types. They're objects that can be used in switch statements. variable arguments. BTW, enums aren't really needed for most programming as long as you have constants. Many high level languages (e.g. PHP, Python?) don't have enums and there's no strong demand for them.

> > variable arguments
> C# innovated and already has this ("params array" arguments)

FORTH, LISP, and C had this for ages.

> > sharing of memory between multiple VMs
> C# already has this
Actually, this is more to do with multiple implementation sharing loaded classes. Currently Java startup times are slow because classes aren't preloaded or shared as they are on the Microsoft J# and MacOSX Java platforms.

> > and a bunch of other bugfixes, enchancements
> Bugfixes in a language? WTF?

Yes, bugfixes do happen. Oh, I forgot you live in the Microsoft world.....

Seriously, why is it when when C# cherry-picks good features from Java, it's called innovation but when Java learns from other languages it's called playing catchup?

Java has gone very far without these features and it still doesn't need them. They're fluff. The only feature that really needed to be added is the shared memory VMs since it'll solve the perception that Java is slow once and for all. The metadata feature is also nice, but it isn't really necessary. XDoclet had C#-like metadata for years (I believe before C# did). It just hasn't been recognized and officially integrated with the EJB spec.

The good and the ugly

[brett_sinclair]

I really like the new language features (and will use them in about 5 years when our server is upgraded :-().

But Swing is even uglier than before. Metal still looks very old, but now it looks like someone very old with obscene amounts of make-up on.

The GTK+ look is even worse. It doesn't look like GTK+ at all (I'm not even sure whether it's supposed to be GTK1 or GTK2).

Worse: font rendering is abysmal. Buttons and menus are barely readable using the GTK+ emulation L&F. The Java VM still doesn't use Xft/Freetype, which pretty much makes the attempt at GTK+ emulation useless.

Re:"generics"

[oops]

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.

Quick Links

[osewa77]

J2SE(TM) 1.5.0 New Features
J2SE 1.5 In A Nutshell>

Re:Too little, too late

[LeonardShelby]

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

Re:"generics"

[brett_sinclair]

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".

Re:Too little, too late

[AbbyNormal]

As much as anyone loves a good berating of a pro-Micrsoft poster, I think both posters missed some relative points.

While the parent mod, loved to cite counter example of technologies utilized previous to C#, I think he missed a good point. C# was the first to pull ALL of these things together under one hood and they did so a few years ago. Don't get me wrong, I'm a java (mainly) and .NET developer, but I choose the right software for the right job . I'm glad to see Java stepping it up a notch, I just hope that it is not too late.

Rubbish.

[warrax_666]

The type checking is much weaker thus introducing new potential holes for error to slip through.

No. Type checking is stronger because you can avoid type casts. (Note, I'm talking about generics in general, not the Java implementation which is slightly broken because of VM compatibility problems).

You must make some assumptions about the used classes however verifying the correctness of these assumptions in nearly impossible.

What the hell are you talking about? Be more specific.

The reusabilty "argument" is rubbish: that's what we have already OOP for. And when you now claim performance problems due to heavy stack/virtual methods use: that's an issue of the processor design not of the programming language. When you think that running serious software on system compatible to 30 year old rubbish is cool, then you must accept the performance of 30 year old waste in the same turn.

The lack of speed of virtual methods has NOTHING to do with processor technology. It is there because you MUST do a lookup at runtime (which there is absolutely no way to avoid). This will ALWAYS add overhead, regardless of processor technology. The only way to avoid this overhead while still having "reusability" is to have "compile-time virtual methods" (i.e. templates).

The above mentioned problems create new security holes. That's why the use of generics/templates in strictly forbidden in e.g. the banking sector.

Now you're talking pure nonsense. What security holes? Generics AVOID security holes because they avoid typecasts (invalid typecasts are one typical reason for security holes).

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.

Nonsense. Compilers are not slowed noticably down by generics in general. All functional programming languages support "generics" (type-variables is a more correct term), but the compiler for e.g. O'Caml is still as fast (or faster) than gcc is for C code. Compilers for C++ may be slower because of templates, but that's because the C++ templates are nothing more than macros with a little added type-checking (so the compilers usually have to compile lots and lots of extra code).

In old languages like Lisps the use of generics is usually strongly discouraged to users unless they are ultra-gurus due to the bad experiences. It's not clear why this should be different for Java or C++.

There is no such concept as "generics" in LISP -- since everything is dynamically typed generics are the default. If you're talking about macros, then some people may discourage them, but those people are idiots. Macros are the precise reason that the LISPs are so powerful.

J2SE 1.5 in a Nutshell

[loconet]

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

Re:"generics"

[fab13n]

Is it a troll?

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.

Just a Question for everybody:

[nberardi]

I don't want to start a flame war, but do you think that the pressure of .Net pushed some of these features through that Sun seemed to be holding off on for the longest time.

Such as enums, generics, boxing, foreach loop, etc.

Just a question that I have had, because I never heard anything about these features comming into Java until after .Net made it's comming out in 2002.

Re:Just a Question for everybody:

[jilles]

Absolutely, competition is good. On the other hand I think Java itself was a good motivation for developing .Net. I don't think MS would have been as eager to put development and research resources into it otherwise.

This is what competition is about. MS already has C# 2.0 designed (which sports many of the features introduced/present in jdk1.5) and no doubt they'll start marketing that in a couple of months. It's a technological arms race. Of course the big question is which of the two will make the first move to support the other. My guess is that they will let IBM do the hard work. Already there is some .Net support in eclipse.

Re:Why?

[iapetus]

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...

Excuse me but:

[gargleblast]

1. The type checking is much weaker than what? It is perfectly strong at runtime.
2. Verifying the correctness of any program in any Turing-complete language is in general impossible
3. The reusability "argument" of OOP is rubbish too.
4. The abovementioned problems are nonsense and as such create nothing. In addition, the banking sector is not universally regarded as sensible.
5. You must be thinking of C++ templates which are (1) Turing complete and (2, coincidentally) are a significant burden to the compiler and linker. Java's generics are neither. They are a simple syntactic sugar for type casting. C++ with templates is still LALR(1)/Context-free/Chomsky type 2. Chomsky hierarchy has nothing whatsoever to do with secure correctness checking. If a language is Turing complete, there is in general nothing you can prove about it's programs.
6. In my limited experience with Lisp's authorities, they encourage much and discourage little. Provide a citation please.

What about HttpSession objects?

[UCRowerG]

I know the compile-time checking for things like ArrayList is a good thing, but is there any note on how this may impact things like HttpSession or HttpServletRequest attributes, where different data types are essential?

Code is for reading as well as writing

[gidds]

While all of these features make code easier to write, I'm not sure they all make it easier to read.

I believe that overall, much more time is spent maintaining code than in writing it, and yet languages seem designed mainly for the latter. (Perl particularly!) Some of the changes -- new for() loops, generics -- will improve readability and maintainability too, but I worry that the new imports, and maybe enums, won't. At present, it's fairly easy to look at a small section of Java code and know exactly what it's doing. With no preprocessor, and nice easy scope rules, you can easily tell what names and objects are being used -- that's one of the things I really like about the language. Additional imports, not just of class names but of other identifiers, risks muddying this. Has anyone done much actual work in 1.5 and can speak from experience?

Someone please make a debian package!

[Doug Neal]

I'm still stuck on 1.3 due to the Blackdown JVM's Debian package not being updated for 1.4. I could do it non packaged-managed, but I'd really rather not...

Re:Someone please make a debian package!

[MForster]

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.

Re:Someone please make a debian package!

[tyrione]

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.

Re:Someone please make a debian package!

[desdemona]

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...

C is portable too

[sreitshamer]

It bothers me when Java's portability is extolled. C is portable too, to more platforms than Java is. And the system call libraries on most platforms have C interfaces, not Java. The only interactions with the host OS that Java supports natively are through the weak File and System objects, through which I can only get the most generic information. For everything else I have to use JNI and, you guessed it, C.

Java's only better if you don't know what you're doing (you can't have pointer bugs, for instance). C and C++ are better when you want to build your language constructs from the bottom up at the same time that you write your program from the top down.

Re:C is portable too

[archeopterix]

It bothers me when Java's portability is extolled. C is portable too, to more platforms than Java is.

C is portable only to some extent. Granted, it compiles everywhere, but it doesn't make your program run everywhere, because, unlike in Java there is no standard way of doing things like GUI, DB access, printing and such in C, so your Foo OS C program probably uses libraries that don't exist on the Bar OS.

Re:C is portable too

[Dan-DAFC]

Java has binary portability (i.e. compile on Wintel and run that binary unchanged on Solaris), C's portability is at the source level (develop on Wintel recompile on Solaris). And even then it takes more discipline (not that programming discipline is a bad thing) to write portable C code than to write portable Java because of the abstractions you mention. If you want to write a program that interacts with the system at a low level then Java is the wrong tool for the job. JNI is awful. It gives you the disadvantages of Java combined with the disadvantages of C/C++. If you find yourself needing to use it you should reconsider your choice of development platform.

Re:C is portable too

[teromajusa]

"That's only true for trivial applications."

Thats an exageration. My company sells several non-trivial Java apps which are binary portable. While we've encountered some platform inconsistancies, particularly in networking, its been fairly trivial to find ways to make things work portably.

Re:C is portable too

[Dan-DAFC]

Are you sure those different packages weren't just for ease of deployment (an .exe installer for Windows, RPM for Linux etc.)?

I have never known an issue in a (100% pure) Java program that relates to what platform it was compiled on. What platform it executes on, certainly, but not on what platform the build was done on. The compiler either produces valid byte code or it doesn't. There's no issue such as byte code being valid on Windows but not on Solaris.

If I compile with a 1.4 compiler on Windows it will run on a 1.4 VM on Windows, Solaris and Linux without recompilation. I may occasionally find that my threading or I/O behaves slightly differently because I haven't accounted for subtle differences inherent in the underlying OS (not as big an issue as when coding in a natively compiled language), but that's not because the byte code is not compatible across different platforms.

Re:C is portable too

[abigor]

C is portable all right - assuming you love the preprocessor.

#ifdef SPARC ...
#endif

#ifdef X86 ...
#endif ...and so on. Yuck.

Re:Too little, too late

[lobsterGun]

There can be bugs in a language too.

Try this in Visual C++

void foo()
{
for (int i = 0; i < 10; i++){}
for (int i = 0; i < 10; i++){}
}

you'll get a compiler error stating that i has been declared twice. For some reason, Visual C++ puts the 'int i' in the function scope rather than in the loop's scope.

Class Data Sharing comes from Apple

[Arkham]

One of the new features, Class Data Sharing, comes as a contribution from Apple. On the Apple Java Page, Apple describes this feature as:

On other platforms, each Java application consumes some system memory, so you might end up using more memory than you need to when running multiple Java applications. Other languages, such as C or C++, solve this problem using what's called shared libraries. Apple developed an innovative new technology that allows Java code to be shared across multiple applications. This reduces the amount of memory that Java applications normally use. And it fits right into Sun's Hot Spot VM, allowing Mac OS X to remain compatible with standard Java. In addition, Apple has given this implementation to Sun so the company can deploy it on other platforms. It's just one example of how Apple supports standards and shares ideas to benefit all.

Pretty cool stuff, and it shows that Sun does accept changes to Java from the outside that are of clear benefit.

Good News for SwingSet

[Yoda2]

This means that the Java RowSet for JDBC is now a semi-standard part (still a sun.* package) of the JDK and no longer requires a Early Access Developer download.

Our open source SwingSet toolkit for making the Swing components database-enabled/aware will now be much easier to install/distribute. Hooray!

Can we thank .NET for giving Sun a push?

[alien_blueprint]

Sun have been promising generics for Java since 1997, and I have been patiently waiting for it all this time.

I haven't had the chance to look at C# in detail yet, but it's certainly no co-incidence that these features finally saw renewed activity after C# appeared. So, thanks, MS, for applying a little competitive pressure onto Sun for us :)

I'm also a little disappointed to see just how similar Java generics are to C++'s templates. I was hoping that we were waiting for a *reason*, and that reason might be because it was a new and interesting approach. But, at least superficially, this looks almost exactly like C++ templates, with all the positives and negatives that go along with that.

Re:Can we thank .NET for giving Sun a push?

[jcupitt65]

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).

Where the value is

[lonb]

While I see people here immediately start debating who gets credit for various aspects of the language and when things came out first -- in hopes of finding which originator is the more powerful geek (MS or SUN), I think the critical point is being missed.

Microsoft has it REALLY easy, and is cut way too much slack, when it comes to development environments and languages. They control the operating system and the hardware specifications and compliance. And, they have done so for well over a decade.

Java is truly platform independent, which is a huge challenge. That challenge was met with a well designed language that operated slowly. However, between 1.4 and 1.5 there are substantially speed increases in the VM which bring it up to par with the fastest languages available.

When you think about developing applications you need to consider many things other than pure technology:
- Who will be around in 5-10 years (both MS tech and Java tech will)
- Access to developers (while MS is the clear winner in the US, this is not so in other countries, where even gov'ts are against MS)
- Vendor independence and support (this is clearly in favor of Java)
..the list goes on.

So, competition is good, huh?

[ceeam]

I mean apparently some level of pressure from dotnet does show up... And that's good I think. Not that I like either of Java or C#... Both look too restrictive (without real benefits) and kinda old to me. I'm leaning more and more to move all the stuff I do to Python (i.e. where I may decide what to do it in, sigh). Slick, reliable, and just very nice to work with.

Screen Shot

[Yoda2]

Here's a screenshot of my EBLA project using the new default look & feel and the new SwingSet navigation bar.

Are you talking about THAT Microsoft?!?

[A nonymous Coward]

Their basic tactic has always been "embrace, extend, extinguish" - not "steal, sue, squash".

You might want to talk to the many companies Microsoft has stolen from, notably Stac (I think was their name). Sue? Squash? Yep, sounds like Microsoft. You must be living in some weird dream world.

Re:Why?

[Surt]

Java is slow today in 2 main places:

[] because array references are bounds checked, and if you do anything more than minimal array work your bounds wont get hoisted so you're screwed for performance. Maybe the 1.5 compiler will hoist more references, the 1.4 misses a lot of obvious opportunities. Also, there are some optimizations that can be done on 64-bit architectures, so hopefully this will at least get somewhat better in a couple of years. It would be nice if they added an unchecked keyword or something to let the programmer decide when they want bounds checking.

Swing is pretty slow, and I don't see sun promoting any of the alternatives yet.

Re:Simple input

[iapetus]

Depends what sort of input you want, but for simple line-at-a-time stuff, System.in can be wrappered to provide easy access:

import java.io.*;

public class InputDemo {
public static void main(String[] args) {
try {
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
while (true) {
String input = br.readLine();
System.out.println(input.toUpperCase());
}
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
}

Re:Too little, too late

[teromajusa]

"I think he missed a good point. C# was the first to pull ALL of these things together under one hood and they did so a few years ago."

I think you in turn missed his point. The post he was replying to claimed that C# had innovated these features. He was demonstrating that those features had in fact existed in other languages previously.

Re:Same old same old

[JohnnyCannuk]

Don't whine at Sun my friend...go the the HP site and get the JDK from them...they may have even released a 1.4 version by now...

Oh BTW, since Sun itself only directly supports Linux Solaris and Windows with all of it's other software, you should not be surprised when they don't release a BETA on another platform. *BSD may be good, but Sun are not experts in *BSD. When The 1.5 SDK is final, I'm sure you will see a quick release to *BSD, jsut as there is a 1.4x fro *BSD now (actually maybe only NetBSD but there is one....).

You see, unlike some other software giants, Sun will let other companies and organizations port Java to their platform at their own speed since they are the experts not them...

Re:No need to wait... Bytecode is backward compati

[brett_sinclair]

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).

"enchancements"

[tehcyder]

Is it just me who loves that typo?

Re:MOD PARENT UP

[deanj]

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.

About polymorphidm snd subtyping

[fab13n]

Let's state that A <: B means "A is a subtype of B". Now the question is "What do I need as conditions on As and Bs to get A<As> <: B<Bs>". The answer is:

• 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:

  Int &lt;: Float
  
  Array&lt;Float&gt; a0= new Array&lt;Float&gt;();
  a0.[0] = 3.14159;
  Array&lt;Int&gt; a1 = a0; // would be legal if the type was covariant
  Int x = a1[0]; // Oops, I've put a float in an int.
  // I shouldn't be allowed to do that without an explicit cast.

• 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.

I like most of it...

[mark-t]

But the autoboxing thing I just can't abide by.

It's a convenience, to be sure, but it seems to me that autoboxing is a setup for programmers to make mistakes, as certain classes can get automatically and invisibly created, where before there would have been an error message issued by the compiler. Hopefully there's a command line switch to disable it so that the compiler can still catch those errors.

Everything else in 1.5 I absolutely love.

Re:SWT

[harmonica]

I find it hard to imagine that anyone is still using Swing these days unless they are locked in to it,

SWT doesn't come with a MVC approach as Swing does. Besides, you'll have to deallocate your GUI resources with SWT yourself.

SWT is the future of Java GUIs

That's a very bold prediction. SWT is a valid alternative in some cases. Before picking a GUI one should think a bit about which toolkit is best-suited for the job. But in no way is SWT always the right choice.

not enough

[ajagci]

These are language fixes that should have happened years ago. The real question is: why did it take Sun so long? Why is the process by which the Java language evolves so severely broken?

And many serious problems remain with the Java language:

• Java genericity has no special support in the runtime, which limits the type safety it can provide.
  
• Generics over primitive types are boxed, meaning they are inefficient.
  
• Java's native code interface is still inefficient and complex.
  
• Java still lacks value classes and operator overloading, making it a poor choice for applications involving numerics or graphics.
  

The most serious problem with the Java platform is and remains, however, that it is basically proprietary: all Java 2 platform implementations depend crucially on code licensed from Sun (e.g., there is no independent Swing implementation). Furthermore, there doesn't exist a Java standard that people can implement without having legal constraints imposed on them by Sun.

Re:not enough

[jjohnson]

Sun wasn't working on the language because they were busy building up the libraries--arguably a better choice. Instead of generics and autoboxing, we have J2EE, which (in the right parts) is probably a larger productivity gain. One place Java still has a huge advantage over ASP.NET is the size of the standard libraries/APIs.

Re:not enough

[Featureless]

I can understand and respect a firm position on open standards and non-proprietary technologies, and that's fine for some folks. On the other hand, I have no problem with Java's licensing or ownership encumberances, and I know I am not alone. The source is open enough that crucial problems, even in the VM, can be fixed by me (rather than begging and whining and being ignored for years, or writing ugly workarounds). In practice I have no issues at all. Certainly, Java compares favorably to things like .Net on this score.

Some thoughts:

Java genericity has no special support in the runtime, which limits the type safety it can provide.

True.

Generics over primitive types are boxed, meaning they are inefficient.

Collections were already boxing primitives. How often do you think this will come up for you in the real world? Can you come up with a convincing example?

Java's native code interface is still inefficient and complex.

Funny, I've used it for a few different things (in 1.4) and never found it to be either. But perhaps if you made a more specific complaint...

Java still lacks value classes and operator overloading, making it a poor choice for applications involving numerics or graphics.

Pardon my ignorance about value classes; I'm wondering if you can be more specific about when they're really useful and what benefits they have for numerics or graphics?

And finally, when you say operator overloading, you lose me. My opinion of operator overloading is that it is absolutely bad. Let me be clear. It is always bad, under any circumstances, when used for any reason. It has exactly zero functional value, and, as opposed to other kinds of "syntactic sugar" it has a tendency to make code where it is used with any frequency into a confusing, unmaintainable minefield. When advocating for operator overloading you are basically advocating a programming style with 1 letter method names, only it's worse, because you're limited to a few "commonly used" letters.

Re:Some Insite please

[egomaniac]

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.

Nice First Step, But....

[occamboy]

We recently switched from Java Servlet development to ASP.NET, and ASP.NET is MUCH faster to develop in. Yes, I know that we're locked in to MS OS and server, but given the incredible productivity increase, this is a small price to pay.

All things being equal, I'd much prefer to stay away from MS. But ASP.NET is far too superior a way to go.

It looks like the new Java release finally makes it roughly as good as C# (or Delphi, after which C# is modeled), but more is needed to for the Java world to be as efficient as the ASP.NET world:

1. A good IDE. In ASP.NET, I can drop components on an HTML form, which bypasses a lot of HTML grief. The entire paradigm is easy-to-use and integrated. In Java, I need to use the comparatively awkward Eclipse or Forte IDEs, muck with Dreamweaver and whatnot - it's a productivity-destroyer.

2. Servers that are not obtuse. I can get IIS to do anything in about 5 minutes. It takes hours or days to do anything in Tomcat or Resin and Apache. My time is precious.

Re:Nice First Step, But....

[truthsearch]

Yes, I know that we're locked in to MS OS and server, but given the incredible productivity increase, this is a small price to pay.

Vendor lock-in is never a small price to pay. From now on your project will be dependant on one and only one vendor, unless you're willing to completely re-write it from scratch one day. As IDEs evolve much quicker from every vendor except Microsoft, you'll be disappointed when you can't use the future version of Eclipse or JBuilder or whatever when it far surpasses Visual Studio. When a new useful free library pops up for Java, which happens all the time, you can't use it. You're stuck on a new platform with less features, less free tools, and less support for the foreseable future.

Re:Nice First Step, But....

[netnichols]

All the java products you mention are free. How much does VS.NET and IIS cost?? I do agree that for 'visual stuff' (ie. guis) ms development tools are still ahead.. but with the rate of innovation in the java world.. they won't be for long.

Re:Nice First Step, But....

[thetoastman]

Yes, I know that we're locked in to MS OS and server, but given the incredible productivity increase, this is a small price to pay.

As another person has already pointed out, this is never a small price to pay.

From a technical point, you've tied your entire IS structure to one company. Your innovations, flexibility, and ability to create services for your environment will be dictated by a single company.

From a business point of view, implementing business critical functions based on a single proprietary environment is always dangerous. In effect, you are entrusting a critical business function to an entity outside your zone of authority.

If Microsoft decides to stop supporting .NET (or any particular technology), your IS infrastructure will have to be completely rewritten. In mainframe days, we called this the forklift upgrade approach. You drive in a forklift, hoist out the old mainframe, and replace it with a new mainframe.

This is exactly the type of capital costs that distributed computing was designed to eliminate. By creating a proprietary single-vendor structure, you've recreated the inherent business and technical risks of single source mainframe computing.

As far as soft dollar (productivity) costs, you've also placed yourself at significant risk. When (not if) the change comes, all of your IS department will have to be retrained. In addition, all of your user base will have to be retrained. This is a serious cost.

The soft dollar cost risk does not end there. Since your field of expertise is narrower (restricted to one vendor's offerings), finding qualified people for senior positions becomes more difficult. This will inflate salary costs at the high end, increasing overall cost of ownership.

To combat this potential salary issue, your company may resort to outside consultants, again placing critical business functionality outside your zone of authority. Your company many also decide that mid-level expertise is adequate, which means that you will not get the benefits of moving to a proprietary, single-source technology.

Having programmed on MVS, UNIX (of all flavors), Windows, and the Macintosh, I realize that some of the IDE offerings for microcomputer platforms are pretty amazing. However, using an IDE is no excuse for not knowing the technology you are using.

In short, if you understand the technology, then learning a tool is just that - learning another tool. I have my preferences in editors, IDEs, and tools (not trolling for an editor religious flamefest!!). However by understanding the technology behind the tools, my choice of tools is based on ergonomics and speed rather than all the technology assist that I potentially get.

When another platform comes along, as I'm sure it will, I will be able to jump right in. By understanding the technology I can be a more flexible geek (gumby-geek?) and provide a better service. If I rely on a single-source proprietary environment, I will go the way a lot of PL/1 programmers went when the next wave of technology arrives.

Re:Reality check

[egomaniac]

Are you serious??
You should try to do some netowrk programming, say for example real time analysis of netowrk packets, see if java can handle a gigabit network...I didnt think so.

I work for Yahoo. Many of our web servers are powered by Java, and they're fast enough for us. Are you suggesting that your network performance needs are higher that frickin' Yahoo's?!?

I do freely admit that we don't use Java for the super-high-volume stuff like My Yahoo and Mail. But we're Yahoo. Even our low-volume properties are high volume. Java is fast enough to serve a lot of purposes around here.

Re:New features - Half way there

[(void*)cheerio]

I'm crossing my fingers...And I must say, I'm quite excited about future possibilities...

Just think:

Java 1.6 : Overloadable operators
Java 1.7 : Pointers
Java 1.7.1 : Void Pointers

The prospect of the combination of overloadable operators and pointers? Oh baby baby baby!

Re:Reality check

[egomaniac]

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.

Re:Too little, too late

[AbbyNormal]

No...Please re-read my post. I never claimed C# innovated anything...I said they were the first to put them all under one roof.

Java 3?

[Schnapple]

Question about the Java naming conventions.

It was my understanding that the first versions of Java were called simply "Java". Then at some version (1.2?) they started calling them "Java 2", despite not being 2.0. So, is this 1.5 version still "Java 2" or have we moved on to "Java 3"? (which, as I understood it, was the title likely associated with 1.5)

Re:Java 3?

[AT]

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.

"Java 2" product name

[Eric Smith]

So why isn't this "Java 3"? There are more significant enhancements between Java 2 1.4.0 and this new 1.5.0 than there were between Java and Java 2 (1.1.8 and 1.2, if memory serves).

Of course, IMNSHO the whole "Java 2" name was just marketing run amuck. I don't see how it's done anything but cause confusion. If marketing absolutely insisted on having a "Java 2", engineering should have bumped the version number to 2.0.

I'm not a fan of marketing determining version or release numbers, nor version number inflation, but changing a marketing product name to include something that looks like a version number without having it match the actual engineering version number is obviously bad.

Re:For more information check out theserverside.co

[Suppafly]

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.

The biggest problem with compatibility...

[s88]

will be code like this:

Enumeration enum = collection.elements();
while(enum.hasMoreElements ()) { ...
}

Guess what... that is a compile error now. "enum" is a new keyword, and is no longer valid as a variable name.

Scott

Re:Too little, too late

[destinationmoon]

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.

operator overloading

[NoOneInParticular]

The grandparent was talking about numeric and operator overloading. It is completely beyond me that a modern language like java does not have one of (a) native numeric libraries or (b) operator overloading to create your own. Have you any idea what an unmaintable mess it makes to be forced to use a lisp style syntax instead of math, or even more errorprone and a hassle, write all the loops by hand?

In many languages nowadays, be it fortran, c++, perl, python, etc. etc. etc. it is possible to use straight math operators on arrays or matrices, which has a clear and concise syntax that everybody that learned math understands. This cuts down on the code to write, the formula is clear and can actually be looked up in the original paper if you care, and, the libraries are usually pretty well optimized. Compare this with java, where, if you use a matrix library, you get some cooked up API that doesn't resemble the way you think about arrays of numbers at all.

Okay, as you seem to claim that operator overloading is absolutely bad always, please explain why:

matrix c = a + b - c;

is bad, and

String c = a + b;

is considered acceptable? Hell, the addition operator on strings isn't even associative.

Re:SWT

[harmonica]

I did, and there are other add-ons too (I remember some Sourceforge project). But I don't like that it isn't part of the core SWT library. Why didn't they support MVC from the beginning? I guess SWT is supposed to be relatively low-level. But that's not what everybody should use, in my opinion, to get back to the original argument.

Re:Java 3.0

[egomaniac]

Just skip this and program in much better JVM based languages than Java:

Admittedly, I didn't even bother to look at either of the languages you point to, but it's irrelevant. Here in the real world, popularity matters. You could be using the best damned programming language in the entire world, and if you're the only one using it, good luck finding a job.

I'm not saying that we should hold back progress. If these languages are really better than Java, then by all means support them and encourage people to adopt them. That's not where you're wrong. Where you're wrong is saying that people should "skip" Java for these languages. That is, quite simply, insane, at least if you're trying to program for a living.

Pain in the ass to download

[Peter Cooper]

My beef with Java is that the Sun SDKs are such a pain in the ass to download from a command prompt.

They use some extremely arcane methods to make sure you have to agree to their licence (which is fair enough) but then once you've started downloading, you can't pause and resume! I even tried their stupid download manager, and it couldn't deal with it.

For those of us on modems (and have ISPs who boot us off every 2 hours to avoid hogging), this is really annoying. I had to get a friend with broadband to download it, then upload it to my FTP server.. so I can stand a chance of downloading it properly!

Not a quirk, it's called inheritence.

[Jerk City Troll]

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.

They might be doing more harm than good

[vegetasaiyajin]

I like most of the features, except the "enhanced" for loop and the autoboxing.

The "enhanced" loop removes readability from the language, but just that.

Autoboxing is more problematic. For example, if you declare

ArrayList<int> intList;

you might be thinking the intList is backed by an array of ints (int[]), but they are not. They are backed by an Object[] and every element is an Integer.
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.

Re:They might be doing more harm than good

[inertia187]

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.

Re:Same old same old

[Jerk City Troll]

Sun are not experts in *BSD.

Kind of funny, considering that Solaris is a derivative of BSD.

Catching up to Common Lisp?

[jwr]

That's funny -- it seems that in another 4-6 years the language features of Java will approach those of Common Lisp.

The main difference being that CL is standardised and thus isn't a moving target -- you don't have to worry about the language changing from under you every once in a while. You can concentrate on your libraries and applications.

Re:Reality check

[alphafoo]

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.

Re:Too little, too late

[MSBob]

This is not really as important as you claim it is.
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.

.Net for the moment is supposed to be used on MS Windows
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 .Net in house. Yeah.

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.
We have many folks here who have 10 years experience coding on Windows and if they say that .Net is not ready for the enterprise I take their word for it.