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

Standardize JAVA!

[Anonymous Coward]

We need an ISO standard.

For more information check out theserverside.com

[alenm]

Link to discussion on TheServerSide.com

Why?

[Anonymous Coward]

Why use Java in place of better known and popular languages? There's certainly no efficiency motivation; anybody who has ever programmed in a real world environment knows that Java is slow and C is fast.

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

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:Why?

[Anonymous Coward]

Java is probably the most popular language today;

No it isn't, and it never will be.
Check sourceforge.

You probably just imagine this that because you probably program in Java sometimes and read the glossy Java developer mags. Silently you're afraid you are missing out on all those other wonderful languages that you don't really understand. I call that wishful thinking out of fear.

regards,

Walden.

Re:Why?

[Anonymous Coward]

..and of course that dynamic re-compilation takes no time at all ... duh.

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

Re:Why?

[Anonymous Coward]

Java as a memory hog?
Yes, and without a lot of careful work this affects performance in real world medium and large size applicatins more than code execution speed.

Shared memory helps?
*Only if you run multiple programs simultaneously*
What is really needed for single program performance is object structure changes so that commonly used things (GUI elements, datastructures, threads...) within a single program share and save memory or are allocated and reallocated from pools automatically. Generally, this is more imporatant on the client-side but each situation is different.

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:Why?

[Anonymous Coward]

But, but, java was the language designed for idiots - what's this? You're saying you have to be careful? That's not the spirit in which java was created.

The vision behind java is you can hire a bunch of idiots, throw them at some problem, and maybe the code looks terrible, but it'll run, and you can pay them less.

Re:Why?

[Bert690]

Since you can't do low level memory optimizations (e.g. to maximize cache utilization), Java will never approach well optimized C/C++ implementations, at least for memory intensive apps. (And let's not even bring up that bloated mess known as Swing...)

For example, here is a recent paper that includes a comparison of Java and C/C++ for XML processing tasks. The conclusion is that Java based implementations are not yet competitive with the C/C++ implementations.

Don't get me wrong, I *love* Java, but when I do highly performance critical stuff, it's just not the right tool for the job.

Re:Why?

[Anonymous Coward]

Britney Spears is rather popular too...

Yeah, and if you peek under the JVM's covers, you'll find it has nice legs and titties, too. This explains why most Java programmers are men and lesbians.

Re:Why?

[addaon]

This explains why most Java programmers are men and lesbians.

Don't you think that can be explained by the fact that most people are men or lesbians?

Too little, too late

[grennis]

So, finally Java is finally catching up to C#. Too bad Whidbey is looming ;)

Not to mention, C# is ECMA standard (ECMA-334 2nd Edition 2002), whereas Sun still keeps a tight grip on their precious IP. Anyway...

generics support

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

autoboxing of primitives

C# innovated this, already implemented years ago

syntactic sugar for loops

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

enumerated types

Java didn't have this before? LOL

variable arguments

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

sharing of memory between multiple VMs

C# already has this

and a bunch of other bugfixes, enchancements

Bugfixes in a language? WTF?

Re:Too little, too late

[Anonymous Coward]

C# innovated 'foreach'?

WTF crackpipe are you sucking on?

Re:Too little, too late

[Anonymous Coward]

C# innovated 'foreach'?

Yeah, everyone knows it was Visual Basic.

Re:Too little, too late

[Anonymous Coward]

C# innovated 'variable arguments'?

WTF crackpipe are you sucking on?

Re:Too little, too late

[Anonymous Coward]

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.

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

[Anonymous Coward]

C# innovated 'generics'?

WTF crackpipe are you sucking on?

Re:Too little, too late

[Anonymous Coward]

dear troll,

We all know C# is microsofts answer to a 7 year old language, speak about being late. Talk to me when you have all the supportive api's we have. And don't forget, C# can copy from java so why shouldn't java copy from C#.

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.

Re:Too little, too late

[Anonymous Coward]

Everything you mentioned was done in languages (C, C++, Python) years before C# was even existed.

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.

Re:Too little, too late

[Anonymous Coward]

You're a troll who doesn't know what "innovate" means.

Re:Too little, too late

[miguel]

Well, it might be in the spec, but it is not in a released product, just like the SDK 1.5 is not in a released product.

They are both in the works.

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.

Re:Too little, too late

[Anonymous Coward]

C# innovated generics...

*cries with laughter*

Re:Too little, too late

[Anonymous Coward]

>>>generics support
>>C# innovated this, and already has this in the spec
> C++ had this way before. Next...

C++ does not have generics, it has templates, which are quite different. Templates cannot be verified when they are compiled, only when they are instantiated. Generics can be verified when they are compiled, so when they do compile you are guaranteed that they will work for any instantiation. Also, generics (in the MS implementation, at least) do not duplicate code as much as templates: methods that can use the same instructions because the instructions do not depend on the actual type share the same code.

>>>enumerated types
>>Java didn't have this before? LOL
>No, and not always very useful. It's just neat.

I do not think there are may people that share that view; I certainly don't. Defined constant integers take more typing to enter, they cannot be reflected over as a unity (as they aren't), and they are not type safe.

I do agree with you that most items in the grandparent post are no innovations, but they sure are nice to have.

Re:Too little, too late

[Anonymous Coward]

Why is this marked as 'Troll'? Everything that was pointed out (bleh foreach) is true. Talking about C# is on topic when discussing the JDK 1.5 IMO. As pointed out, most of the improvements in 1.5 are ripped from C#.

--
c# AND java fan

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.

Re:Too little, too late

[Anonymous Coward]

I noticed you didnt say anything about my open ECMA standard comment.

It is sad that I have to post this as an A/C since I am voicing an unpopular opinion here on slashdot. Pathetic groupthink sheep.

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

Re:Too little, too late

[Anonymous Coward]

That C# implemented them is true. That Java is implementing them as a catch-up to C# is likely also true. That C# innovated any of these features is laughably incorrect.

Re:Too little, too late

[Anonymous Coward]

Java has gone very far without these features and it still doesn't need them.

I think that's amazing. I do a lot of development with Java, but it's not by choice... Java is an increadibly clunky language. It is IMHO impossible to do anything elegant at all.

But Java has a huge amount of industry support, which I think is amazing.

Re:Too little, too late

[Anonymous Coward]

It is sad that I have to post this as an A/C since I am trolling my little socks off here on slashdot.

I fixed your typo.

Re:Too little, too late

[Anonymous Coward]

If we can have millisecond JVM startups, then can we finally write our CGI in java ?

Re:Too little, too late

[alien_blueprint]

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

Innovated?! How long have Perl and Python had this feature?

That's a bizarre definition of "innovate" you've got there ...

Re:Too little, too late

[Asmodeus]

"There is no API in .net for doing O/R mapping such as JDO or CMP (belch). "

There is in the next version - almost identical to JDO (Except that M$ have decided to re-invent OQL at the same time). In the meantime, search for 'bytecode' on the gotdotnet site and find my semi-transparent object persistence code, or look at freshmeat and search for Gentle.NET which is another O-R mapping tool.

Asmo

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.

Re:Too little, too late

[fab13n]

- generics support
- C# innovated this, and already has this in the spec
- C++ had this way before.

Actually, first implementations of generics come from the functionnal progrmming community, esp. Philip Wadler et al. So, the java genericity's genealogy would rather lead to Hindley/Milner type sytems, through Haskell

Re:Too little, too late

[Anonymous Coward]

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.

Yes, enums are generally of little use - but that's because all an enum is is a watered down variant type.

Real variant types, combined with ML-style pattern matching, are incredibly useful. For example, you can define a fully generic binary tree in one line of Caml -

type 'a tree = Leaf of 'a | Branch of 'a tree * 'a tree

Call me again when Java has that level of sophistication and I may be interested.

Re:Too little, too late

[Anonymous Coward]

Sure, there can be bugs in languages too, but your example is clearly a bug in Visual C++'s compiler, not the language itself...

Re:Too little, too late

[Ryan Hemage]

This has been fixed in VS .Net, (if you compile with /Ze) though, Microsoft being Microsoft, this scoping issue is not a bug but a Microsoft language extension (a.k.a. "feature").

Re:Too little, too late

[SteveX]

The .NET generics implementation is a little different than the Java and C++ versions, in that only one copy of the template code is generated - if you have a List template, and you have lists of 10 different types of objects, you have 10 copies of the list code. With .NET you have one.

- Steve

Re:Too little, too late

[teromajusa]

Actually, the scoping of the loop var was changed in the standard a few years ago. Formerly it was function scope, now its scoped to the loop. Your version of the vc++ must be old. If you try that code in vc7, it will compile just fine. Even if you were correct about that being a bug though, it would not be a bug in the language but in the compiler implementation.

Re:Too little, too late

[Anonymous Coward]

C# copied generics from C++ (which likely copied it from somewhere else)

From Ada-83

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:Too little, too late

[Anonymous Coward]

Typical for M$ - innovation means copying from somewhere else...

Re:Too little, too late

[deanj]

Heh....good points, and "foreach" is even older than that.... Wasn't it in csh?

Re:Too little, too late

[Deef]

The Java version works this way too. Only one copy of the template code is generated. Even C++ is allowed to work this way, by the specification. It's just that virtually no C++ compilers actually do it that way.

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.

Re:Too little, too late

[Anonymous Coward]

He (teromajusa) wasn't claiming that you (AbbyNormal) claimed that. He was claiming that sporty (in the great-great-grandparent post, or thereabouts) was bashing the original poster for claiming that C# innovated these features.

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.

Re:Too little, too late

[Anonymous Coward]

Actually, it's like this:
C++: generates 10 copies during compile

dotNET: generates 10 copies during runtime

Java: generates 1 copy (generics is only at the syntax and code verification level)

http://www.artima.com/intv/generics.html

Re:Too little, too late

[NoOneInParticular]

this is not a bug in the language, it's a bug in the compiler. Given that this is MSVC such bugs are not at all surprising.

Re:Too little, too late

[NoOneInParticular]

Just replying to one in a whole series. Guys, don't you realize that the word 'innovate' when used in the context of MS means 'appropriated'? Give the grandparent a break, it's a good troll.

Re:Too little, too late

[NoOneInParticular]

Come on, cut the guy some slack. He's obviously using the term the microsoft way, which means 'appropriated'. Innovation is not a verb, that alone should have given you some clue.

Re:Too little, too late

[cyberjessy]

C# copied generics from C++
Wrong. Generics(templates) in c++ is more like macros. (You can read up on what i mean)

O/R bridge(JDO-CMP)
This is not really as important as you claim it is. In any case, you will get equivalent functionality if you derive your data-related classes from a dataset.

There is no API for distributed clustered components like EJB session beans
ahhh .... try remoting with IIS to achieve scalability and distributed performance.

MSMQ is only usable in the Microsoft world
But .Net for the moment is supposed to be used on MS Windows

Java has a bunch of great open source tools for it like Eclipse and all its plugins not to mention the Jakarta project
Considering Java had a headstart, and the equation between them right now, you see that .Net is catching fast. OpenSource tools for .NET. Consider SharpDevelop. Not enterprise quality. But usable. Enterprises and professionals can always afford Visual Studio.Net

Finally .net lacks real credibility in the enterprise
You will be surprised at how many sites are turning to ASP.Net. I just met someone who told me that Infosys(large indian company employing 20000 people) ported their Core banking solution(Finacle) to C# using JLCA. Numerous otehr examples ... just check google.

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.
Simply means that there arent enough good .Net coders in your company.

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.

Re:Too little, too late

[Anonymous Coward]

Innovated?! How long have Perl and Python had this feature?

Ten years, twenty, who knows. But you don't except 11 year old pre-teen like grandparent to know that.

Looks cool and I like the like for old releases

[thbigr]

Nice to have a link on the top page for old releases. To many times I have gone to the java.sun looking for some odd 1.1.4 or what ever to try and replicate some bug the user is having.

it does work if you do this...

[Anonymous Coward]

javac -source 1.5 filename

Re:it does work if you do this...

[inertia187]

javac -source 1.5 filename

That's exactly what I was wondering. I was getting. Example:

C:\Documents and Settings\Anthony\Desktop\tiger>javac TestTiger.java
TestTiger.java:8: not a statement
List<String> stringList ;
^
1 error

C:\Documents and Settings\Anthony\Desktop\tiger>javac -source 1.5 TestTiger.java

C:\Documents and Settings\Anthony\Desktop\tiger>

Now it works. Thanks!

mod parent down

[Anonymous Coward]

warning, goatse link in parent post

Re:mod parent down

[Anonymous Coward]

no such luck, unless it's from the fortchoming Nintendo game "Goatse: a Link to the Past"

I MISS JON KATZ!!!

[Anonymous Coward]

C'mon fellow slashdotters,

dont you miss the lovely prose of that great man who had his finger on the pulse of the geek nation>

I think we should all subscribe, so that Taco can hire him back and buy him a BMW

Thank you - that is all

Re:I MISS JON KATZ!!!

[Anonymous Coward]

how is this offtopic?

the poster has a good point - Jon Katz added a bit of class to this shabby website

Re:I MISS JON KATZ!!!

[Anonymous Coward]

FUCK YOU and FUCK JON KATZ..

anyway.. he's still here. They just call him Honestpuck instead.

FUCK YOU!

FUCK YOU!!

fuck OFF and DIE you mmotherfucking fuck fuck fuck.

Mac

[Anonymous Coward]

Darn it, the Mac just got JDK version 1.4.2...

http://www.apple.com/macosx/features/java/

Re:Mac

[jimbolaya]

Hey, but we had shared memory between VMs since Mac OS X 10.0! That's gotta count for something.

Remember, though, that this is a beta release of 1.5. Unfortunately, Mac does lag in JDK releases, but not nearly as much as we did in the "Classic" days. If history is a guide, Apple will release "developer previews" of 1.5 before it reaches GM for Windows et al.

Re:Mac

[goljerp]

I knew that 1.5 beta was coming out soon, because Apple just released Java 1.4.2.

Re:Mac

[Anonymous Coward]

Hey, have you seen that film, the one with the white kid who near the end "you're sayin' the same shit he said".

If not, you should see it.

Re:Mac

[goljerp]

Whoops! Sorry, blame it on the (unfair) moderation - I normally don't view posts which are at -1!

I guess great minds just think alike, eh?

Re:Mac

[pldms]

:-)

You can try out most of the new features (since they are largely compiler changes) using this preview compiler. It requires a minor amount of fiddling with the scripts, and the new coolness is your reward.

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

[noselasd]

Please explain further. I've done this many times.

Re:an annoying quirk

[Anonymous Coward]

This works:

ArrayList nums = new ArrayList();
ArrayList l = nums;

Re:an annoying quirk

[Anonymous Coward]

Whoops! Those angle brackets look like HTML to slashdot. Second try:

This works:

ArrayList<Integer> nums = new ArrayList<Integer>();
ArrayList l = nums;

Re:an annoying quirk

[tbfmicke]

This sounds like a reasonable behaviour, if you have typed a list to only have Strings (say) it makes sense that you cannot send it to a function that don't know about that typing.

The function could add a Date or anything to the list without knowing its mistake and suddenly you have a list whose type lies for you :-)

Re:an annoying quirk

[Anonymous Coward]

That compiles?!? It shouldn't! What happens if I now do:

l.add("Whoops!");

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

[Anonymous Coward]

Is that really what the syntax looks like?

Hell, it is C++.

Re:an annoying quirk

[TomH]

If what you say is that you cannot pass e.g. a type ArrayList to a function that takes Arraylist, then that is completely reasonable since ArrayList can contain any type of elements and is therefore different to ArrayList.
Inside the function you could compromise static type checking (which is essentially what the Java generics is all about) by e.g. putting Strings in the ArrayList, which would result in run-time exceptions. The generics have been introduced so that you can avoid all the annoying casting from Object to whatever type, and instead you will get compiler warnings if you access an object incorrectly. Allowing what you suggest would prevent that type of static checking from taking place, thus destroying the purpose of generics in the first place.

Re:an annoying quirk

[andrewscraig]

You get a warning :

test.java:8: warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.ArrayList
l.add("Whoops");
^
1 warning

Re:an annoying quirk

[hey!]

It is certainly not reasonable behavior, as by any stretch of the imagination list of strings is a subclass of list. Suppose I have a func that reverses lists; it should work on any list. I should be able to use the same method to transpose matrices of ints or floats.

Upcasting actual parameters is key to effective use of polymorphism. If your method assumes string or date members then you should type the formal params accordingly, which is the whole point of template types.

This has to be a bug if it is true.

Re:an annoying quirk

[TheSunborn]

The reasen this can't be allowed is very simply: Look at this:

ArrayList s = new ArrayList();
ArrayList t = s; // Does not compile, but asume that it would.

t.addElement(new Float(10.5)); // Now we have added a float to a list which can ONLY contain integers. Not good.

Integer i= s.elementAt(0); // Class cast exception.

Allowing t=s would ruin the entire "You are sure your collection only can contain what it say it contains, and we check that at compile time"

Re:an annoying quirk

[dnoyeb]

What do you mean it does not compile??? Of course it compiles. What are you talking about? Did you mis-type?

Since when did you DEFINE that the arrayList could only contain integers??? I see no such constraint.

Re:an annoying quirk

[Anonymous Coward]

Marvelous. I see Java has done its best to emulate the usefulness of C++ template compiler errors as well.

Re:an annoying quirk

[The Clockwork Troll]

Do any facilities exist in JDK1.5 which will facilitate automatic type conversion between "cousin" generic types such as the two ArrayList types you mentioned?

Re:an annoying quirk

[Anonymous Coward]

Yes, there is. It is called casting. Read a book before you ask such questions.

Re:an annoying quirk

[Sircus]

I've not tried the 1.5 Beta yet, but it could be it'd be happier if the function prototype took an ArrayList

Re:an annoying quirk

[Anonymous Coward]

// For that I think you'll need:

ArrayList l = new ArrayList();
l.add("Whoops"); // But I think what the orig. poster was saying // something like the following doesn't work:

ArrayList a = new ArrayList();
ArrayList b = new ArrayList();
a.compareTo(b);

Re:an annoying quirk

[scrytch]

Good explanation of inheritance behavior severoon. It bears noting that C++ behaves this way as well. I'm not certain whether C++ allows you to define a cast operator to get around this (I think those are only for primitives), though you can certainly define a constructor. In Java, you'll need to write your own conversions. Usually this is a good thing, and if you really need common behavior, you should still be able to use an interface -- that's what it's there for.

Re:an annoying quirk

[Anonymous Coward]

//OOPS.
// For that I think you'll need:

ArrayList l = new ArrayList<String>();
l.add("Whoops");

// But I think what the orig. poster was saying
// something like the following doesn't work:

ArrayList a = new ArrayList<String>();
ArrayList b = new ArrayList<String>();
a.compareTo(b);

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

[CynicTheHedgehog]

ArrayList Z = new ArrayList( );
ArrayList N = new ArrayList( );
N.AddAll( Z );

You couldn't cast between them per se, but this would be much safer anyway. Look at it another way:

Integer z = new Integer( 1 );
Number n = z;
n.Parse( 5.2 );

If the object referenced by n were actually of type Number, then the above should work. However, the object is of type Integer, so the parse should fail (although I must confess that I don't know what the actual outcome would be...I haven't used Java in over a year). It's really the same situation. Intuitively you would think it would work, but you can see from the example how unsafe it would be. The following *would* work in any case:

Integer z = new Integer( 1 );
Number n = new Number( z.intValue( ) );
n.Parse( 5.2 );

or:

Integer z = new Integer( 1 );
Number n = z;
n = new Float( 5.2 );

Re:an annoying quirk

[tbspit]

I think parent was intended to read as follows:

The reasen this can't be allowed is very simply: Look at this:

ArrayList<Integer> s = new ArrayList<Integer>();
ArrayList<Number> t = s; // Does not compile, but asume that it would.

t.addElement(new Float(10.5)); // Now we have added a float to a list which can ONLY contain integers. Not good.

Integer i= s.elementAt(0); // Class cast exception.

Allowing t=s would ruin the entire "You are sure your collection only can contain what it say it contains, and we check that at compile time"

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.

Re:an annoying quirk

[lokedhs]

This is correct. The generics are not plymorphic (which is correct). You need to explicitly state that you want a reference to a "List of Integer or any of it's subclasses". The syntax looks like this:

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

Re:an annoying quirk

[lokedhs]

I believe you still can put a null into it.

A null is special in that can be casted to anything.

Re:an annoying quirk

[uid8472]

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.

Of course not; if you could (for example) cast an ArrayList to an ArrayList, then someone could use the latter type to insert an element of class Donkey, and someone using the former type and expecting to extract an Elephant would get an unpleasant surprise. In other words, it would violate the type system. In yet other words, because ArrayList's type parameter is used in both covariant position (return value, for extraction) and contravariant position (argument, for insertion), it must therefore be invariant.

If it were an immutable container, covariance would make sense (and likewise for contravariance and a write-only container like a typed communication channel), but I don't know if the Java 1.5 people have allowed for it.

Re:an annoying quirk

[SkywalkerOS8]

I just tested this by trying to pass a List to a method that accepts an untyped List and it worked just fine. Do you have a code example of what your friend was trying to do?

Re:an annoying quirk

[pjt33]

I presume the method was typed something like
process(ArrayList list)
If you have another method
process(Object obj)
then a plain ArrayList will be bound to the second. This is a slight nuisance for writing code which requires casts, but otherwise shouldn't be an issue.

Re:an annoying quirk

[oldwarrior]

generics it seems to me have little to do with subclassing but everything to do with macro preprocessing. You have to step outside of the "object-oriented" mindset to use them. But they can make some operations safer and (in C++) faster.

Re:an annoying quirk

[jeremyp]

"list of strings is a subclass of list"

Actually, it isn't. The list of strings can't have a method "add (Object o)" for instance.

Re:an annoying quirk

[redKrane]

Functions don't exist in Java, and there is no way in hell you "just can't" pass an object as a method argument. Hello...

Re:an annoying quirk

[tdelaney]

i = [1, 2, 3] # array of integer
n = i # array of number

Seems like other languages support it ...

Re:an annoying quirk

[Anonymous Coward]

Obviously no-one reads before replying -- or would you like to know some more about variance?

Re:an annoying quirk

[anarxia]

You can do it with the reflection API but it is not exactly clean code and you lose compile time checking. Most of the times if you need a function pointer you should be using factories instead.

Re:an annoying quirk

[rreyelts]

I don't understand your point. You are writing statically unsafe code. You could do the same thing in Java years ago:

String[] strs = new Object[] { 1, 2, 3 };

but that doesn't mean you'd want to. Variance gives you static type guarantees about parametrically polymorphic objects.

Re:an annoying quirk

[Anonymous Coward]

Since when was casting "automatic"?

Re:an annoying quirk

[Anonymous Coward]

This example does not work. The covariance stuff was experimental and was not included in the final 1.5 release

Re:an annoying quirk

[tunah]

Hmm, I'd been following the generics forum, but this hadn't occurred to me. Do you know why a distinction is made between ArrayList and ArrayList ? (in terms of design, not implementation)

Re:an annoying quirk

[Anonymous Coward]

Hmm, I'd been following the generics forum, but this hadn't occurred to me. Do you know why a distinction is made between ArrayList<T> and ArrayList<? extends T> ? (in terms of design, not implementation)

Sure. In the former, list.insert(new T()); is a valid operation. In the latter, it is if and only if the ? is T itself.

Re:an annoying quirk

[Dogun]

Just a quick addendum (though somebody figured out what I meant anyhow) I was complaining about an

ArrayList greater than sign Integer less than sign

and an

ArrayList greather than sign Number less than sign

Evidently, it is true that an ArrayList(integer) is not a sublcass of ArrayList(number) and there is no good way to solve this problem for mutable objects; otherwise a function that takes a list of numbers could insert say a float into a list of integers. Just one of those things, I guess.

Re:an annoying quirk

[TheSunborn]

Both :}

Re:an annoying quirk

[lokedhs]

What are you talking about? It's all in there in the latest beta, as it was in the alpha. It was not to my knowledge in the demonstration release before that though.

Re:an annoying quirk

[tunah]

Right, posting before coffee again. For some reason I was thinking that you could have an actual ArrayList, rather than it being a restriction on the kind of ArrayList it actually is (or isn't, thanks erasure!).

Re:an annoying quirk

[jovlinger]

So what happens when I do

t.add(5.1)

This should attempt to store a float into an Integer array, no?

One true language

[Anonymous Coward]

I'll save you the trouble and point out that lisp had all those features years ago.
Did I read the documents? Of course not, but this is /.

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:IPv6 for windows finally

[steve_l]

And a ping! They gave us ping!

New features

[Cthefuture]

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

So essentially it's become C++... ... decades late. :)

Re:New features

[PhrostyMcByte]

I'd say more like C#.

Re:New features

[Anonymous Coward]

Wow, you Java people sure don't like C++.

Jealous much?

Re:New features

[Anonymous Coward]

sad but true. java blows

"generics"

[Samuel Duncan]

While some people always propagate the use of generics/templates, I'm strictly set up against it.
While you get at first sight nice stuff like reusability etc. there are several reasons for avioding generics like an STD:

• The type checking is much weaker thus introducing new potential holes for error to slip through.
• You must make some assumptions about the used classes however verifying the correctness of these assumptions in nearly impossible.
• 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 above mentioned problems create new security holes. That's why the use of generics/templates in strictly forbidden in e.g. the banking sector.
• 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.
• 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++.

Re:"generics"

[Anonymous Coward]

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

utter rubbish. the opposite is true.

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

nonsense. THE point of generics is that the work for all types

The reusabilty "argument" is rubbish: that's what we have already OOP for.

nope. subtyping/classing does NOT give you the reusability of generics and vice versa. they are orthogonal problems.

The above mentioned problems create new security holes.

since the above arguments are rubbish, this one is too

That's why the use of generics/templates in strictly forbidden in e.g. the banking sector.


rubbish


Due to turing completeness of most template/generics systems the compiler is slowed down to 30 percent performance.


this is a problem with the C++ typing system. other approaches to generics do not have turing complete typing systems in this sense.

in any case, what's a problem with a 30% slowdown, when you get all the great benefits of increased safety that genericity affords.


More evil is that templates push the grammars into the Chomsky-0 type making secure (=100%) correctness checking impossible.


rubbish.

Summary you have no idea what you are talking about. please read a good book about
typing systems like Benjamin Pierce's

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

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.

Re:"generics"

[lfourrier]

do you know java ?
do you understand what are generics in the context of 1.5 ?

I don't understand how you were moderated interseting.

Here, we don't speak about generic generics ;). we speak about generics as implemented in jdk 1.5

And from my experience, the banking sector avoids STL because they came years after C++, (which itself took years to be standardized)

Re:"generics"

[LeonardShelby]

So you like writing container classes for every possible type that could go into one? Yeah, that's the way to do it. None of this saving time and getting reusability in the horizontal (with inheritance being in the vertical). Why would someone do that?

And there are techniques to get better performance with generics, it's just that the C++ compiler camp hasn't found them yet.

And isn't Lisp effectively a typeless language, or at least dynamically typed? Generics are actually there by default then.

Steve

Re:"generics"

[nuffle]

that's what we have already OOP for

However, Java's OOP is a little limited in one aspect: it doesn't allow multiple inheritance. Although you can use interfaces to accomplish most of what you'd want to do, it is a bit clumsier (i.e. you must provide implementation in all the classes implementing an interface). I imagine generics/templates are Java's solution to allow code to be written once and reused elsewhere, when you don't want to sacrifice your one and only possible parent class.

Like you, though, I think it's a bad idea. I'd rather they had multiple inheritance.

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:"generics"

[James Youngman]

While some people always propagate the use of generics/templates, I'm strictly set up against it. ...

• The type checking is much weaker thus introducing new potential holes for error to slip through.
• You must make some assumptions about the used classes however verifying the correctness of these assumptions in nearly impossible.

With templates - and I assume generics, though I have not yet tried the 1.5.0 SDK - the type checking is stronger, not weaker. For example if you have a HashMap<InetAddress,HostIcon> then you can only retrieve items from it by specifying an InetAddress as a key, and it will only ever return instances of HostIcon. More importantly, this is checked at the time that your code is compiled.

If you need to make an assumption about the classes on which you operate, you can either just perform the operation you need (static compile-time checking will usually cause a compile-time error when the class on which you are operating does not give the requisite guarantee, for example, offer the method you need) or, failing that, you can use the Java language feature which was designed to comminicate interface contracts between classes and their users - that is, use an Interface.

Re:"generics"

[MetaMarty]

More evil is that templates push the grammars into the Chomsky-0 type making secure (=100%) correctness checking impossible.

Chomsky-0 and 1 grammers cannot be parsed by the common LALR parsers, like the once generated by YACC. If your statement were true, there would be an enormous effort needed to adjust the java compilers to accomodate the new grammer.

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.

Re:"generics"

[warrax_666]

Note that templates != generics. Templates are more powerful than the generics in java. In fact C++ templates are Turing complete; I seem to remember someone even implementing the Towers of Hanoi in C++ templates (it would generate print statements which would print the correct sequence of moves. Truly evil stuff!).

Correctness checking the code generated by templates is impossble, but that's just because (in general) correctness checking programs in any Turing Complete language is. So correctness checking an arbitrary C program is also impossible. However, note that type checking C++ templates is very possible; my compiler does it all the time.

Re:"generics"

[mitch0]

1.) Type checking is much weaker? How could

int i = container.get(0);

be weaker (where container is a template instanciated for int specifically, so you get compile time error) than

Integer i = (Integer)container.get(0)

where you'll get a runtime cast exception if you happen to be unlucky?

2.) Compile time checking of capabilities can be done with templates. Check out for example the Concept Check library of boost.

3.) reusability rubbish? not if you want a type safe, efficient container library for example (no, the current java library is not type safe. See point 1. And it's not efficient either (try storing ints in a HashMap for example)

4.) I've never heard about any such constraints for banking software, but you might be right on this one. I'd be surprised though, since I'm pretty sure some banking software is written in c++, and the standard library is using templates heavily) Templates creating security holes are beyond me, though...

5.) Compilers getting slower doesn't really matter. Correctness proof is not possible in general (at least, not feasible for real world applications). Templates make this maybe twice as hard. So?

oh well, at least your post was not "informative", but "interesting"...

cheers,
mitch

Re:"generics"

[alien_blueprint]

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

No, the compile time type checking is stronger. Since, for example, you can declare the exact type that a collection may contain, there's no need for unsafe casting at run-time. This is *much* safer, as a whole class of run-time errors has been eliminated.

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.

I don't see what this has to do with generics. But I agree in so far as "virtual" methods should be the default as they are in Java. And they still are. Adding generics to Java hasn't changed that one bit.

The above mentioned problems create new security holes

Such as? I've never heard of such a thing.

That's why the use of generics/templates in strictly forbidden in e.g. the banking sector

Aside from the fact that your argument about "security holes" is untrue on the face of it, this is just incorrect. Evidence? I know people using C++ at various banks, and they've never mentioned any such thing.

Due to turing completeness of most template/generics systems the compiler is slowed down to 30 percent performance

This is true - and actually it's much worse than that. But honestly, is that an issue today?

More evil is that templates push the grammars into the Chomsky-0 type making secure (=100%) correctness checking impossible

Firstly, this kind of thing will only effect a tiny subset of Java programmers. Secondly, correctness checking *is* impossible to get 100% right. Turing showed that, after all ...

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

I don't think I'd be going out on a limb to say that you don't really know what generics are as they apply to C++ and Java.

Given that Lisp is a dynamically typed language in the first place, I'd imagine that "generics" are a very different feature entirely in that language. So what are generics in Lisp, exactly?

Re:"generics"

[salimma]

Due to turing completeness of most template/generics systems the compiler is slowed down to 30 percent performance

This is true - and actually it's much worse than that. But honestly, is that an issue today?

[humor]Why, yes, he's obviously using Gentoo![/humor]

Re:"generics"

[Anonymous Coward]

there are a _huge_ number of problems with multiple inheritance.

for example, if classes A and B are inherited from C and D is inherited from both A and B...

1. do we have one or two parent C objects??
2. which one gets intialized first?
3. when in D, we call a virtual function in of C, is it the A or B overloaded version that is called?
4. and many many more...

Re:"generics"

[Anonymous Coward]

"However, Java's OOP is a little limited in one aspect: it doesn't allow multiple inheritance."

Actually, multiple inheritance _isn't_ "real" OOP from an OOP theoretic viewpoint, it is simply a C++ specific OOP implementation.

Multiple inheritance is also riddled with problems, which is why Java omitted it on purpose. The problems are everything from "simple stuff" like what happens if a class inherits from two classes that both have the foo() method in them, and the inheriting class doesnt override it? You are most likely bound for trouble using multiple inheritance, its more of a headache than useful.

Re:"generics"

[severoon]

I never created container classes for every type-specific container I wanted. If I wanted typing in the elements of an ArrayList, for example, I wouldn't create a FloatArrayList and an IntegerArrayList. That'd be a waste of time. Instead, I'd create a TypedArrayList that extends ArrayList and takes a Class in the constructor. Then, whenever you store anything in that collection, it checks the class of the object you're trying to store against the class specified at instantiation time.

It's not as clean as generics (I'm glad they're here), but did anyone seriously write fifty different ArrayLists, one for each type they needed to store in there? That's not using your head...

sev

Re:"generics"

[Jonboy X]

Umm, yeah, I call shenanigans.

Collections still contain only Objects, which must generally be downcast to be useful. Generics just automate this downcasting. If anything, generics result in *less* efficient code, as sometimes you don't need to downcast all the way to Integer when you just need a method from Number.

Okay, so maybe you're just misinterpreting the results, not lying. That's the thing about ad-hoc benchmarks: you never know quite what you're testing.

Re:"generics"

[maraist]

Generics just automate this downcasting.

My understanding of generics is that the type-cast is completely omitted.. If the compiler can PROVE that what is going in to the collection is a Foo class, then when you pull the material back out, no type-cast is needed. Thus it is in the retrieval of generalized objects that performance is saved.

So again, to my understanding there is NO downcasting.

Re:"generics"

[Jonboy X]

[T]he type-cast is completely omitted.

Wrong!

Well, I'm pretty sure you're wrong. Take a look at http://www.artima.com/intv/generics2.html , specifically the section titled "Comparing C# and Java Generics". All that's happening is that the compiler is inserting those downcasts for you. Well, it's also verifying that whatever you put into the Collection is the right type, but that's at compile time, not runtime.

It'd be neat if you were right, though. Point me to your source on the no-casting solution, and it'll make my day.

Re:"generics"

[William Tanksley]

Your post was almost entirely correct, and was very powerful in rebutting the nonsense you were responding to.

In old languages like Lisps the use of generics is usually strongly discouraged [...]

You know why it's discouraged? because it doesn't exist!

Not true -- Common Lisp has generics.

Lisp is dynamically typed, so templates don't make much sens.

Lisp includes facilities for specifying static types, so its templates. However, generics are useful for more than just static typing; they provide polymorphism that inheritance alone can't provide.

I guess you're confusing with macros, that are, indeed, Turing complete and can arbitrarily mess up the grammer in unskilled hand.

He probably is confusing SOMETHING, but macros aren't discouraged in the Lisp community :-). They're considered to be one of the great strengths of Lisp. Some people even mistakenly believe that they're unique to Lisp's s-expressions (incorrect because Forth's "concatenative" syntax is even more applicable to automatic code generation).

I've really seldom seen such an accumulation of BS in a single post.

I agree with this sentiment, although I've seen worse :-).

-Billy

Re:"generics"

[fab13n]

I guess you're confusing with macros, that are, indeed, Turing complete and can arbitrarily mess up the grammar in unskilled hand.

macros aren't discouraged in the Lisp community :-)

Indeed. That's "unskilled hands" that are decouraged :)

Re:"generics"

[Anonymous Coward]

The downcasts must still be in the bytecode -- think about the JVM security model, and the bytecode verifier.

Re:"generics"

[vague]

I'll just clarify a fact that has been missed or somewhat obfuscated by other replies. You're completly confused as to relationship between macros/templates as found in C++/LISP and how they are used for achieving genericity in C++ on one hand and true generics as found in Ada, ML, C#, or Java 1.5. With the latter kind the generic functions/types can be statically type checked in isolation, long before it is instantiated as must be done for C++. When they type check they are type safe and end up providing much greater type safety than Java 1.4's idiom did, by providing type constraint on type parameters and type guarantees on collection content.

Generics are not templates, but genericity can be achieved using templates. However, since generics aren't as powerful as templates they are also very easy to make perfectly type safe. You have some (fun) learning to do!

Re:"generics"

[Anonymous Coward]

I understand that multiple inheritance can be complicated in some situations, but it can be useful when used carefully. Why can't the compiler just force you to be explicit in the case of a conflict?

Re:"generics"

[Kupek]

Um, STL.

Re:"generics"

[toriver]

However, Java's OOP is a little limited in one aspect: it doesn't allow multiple inheritance. ... otherwise known as schizophrenia. MI isn't central to OO, both Smalltalk and C# do without it too. So perhaps it's MI that's the bad idea?

Using nested classes as delegates you can accomplish nearly anything you would want to use MI for anyway.

Re:"generics"

[voodoo1man]

I don't think I'd be going out on a limb to say that you don't really know what generics are as they apply to C++ and Java.

I think I will have to agree with you here.

Given that Lisp is a dynamically typed language in the first place, I'd imagine that "generics" are a very different feature entirely in that language. So what are generics in Lisp, exactly?

What the parent is probably referring to when he talks about Lisp "generics" is macros, which are a totally unrelated concept.* Like you said, Lisp is dynamically typed, and the closest parallel to C++ generics is multimethods.

* - A Lisp macro is a function that manipulates it's arguments before they are evaluated, with the result spliced back in the place of the macro call (this is pretty much the same thing as parse-tree manipulation in languages without explicit program representation). Peter Seibel's upcoming book explains them very well.

PS - Note that when I say Lisp here, I'm referring to Common Lisp. Scheme macros ("syntax-case") are a bit different, and Scheme doesn't come with multimethods or other goodies.

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

[cerberusss]

Do you have experience with C#? I'm just curious, care to let us know?

We're doing consultancy work mainly in Java (and PL/SQL, Oracle proprietary), but we expect customers to ask about C# in the near future.

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

[Anonymous Coward]

It's purely amazing how a slashdot reader can be so ignorant on such a pervasive topic in our industry.

Re:About time too

[Anonymous Coward]

Yah?
Is that with or without a flip of the wrist?

homer

Re:About time too

[anti-trojan]

"Cerberus" is the Latin spelling of the Greek "Kerberos".

And your nickname is Gollum's way of saying it?

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

[Nurgled]

Some parts of the class library are off-limits, but the important core stuff seems to be okay. A developer could, say, implement the guts of an app using the portable runtime libraries and then implement two or more sets of UI classes using different class libraries, which is probably a sensible approach to ensure the app fits in to each environment correctly anyway.

Re:About time too

[cerberusss]

Cerberus was taken :D

Re:About time too

[Anonymous Coward]

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.

Re:About time too

[Seahawk]

Actually it was no troll at all - I just find it weird how "geeks" often defend java agains c# - I'd rather have a complete open source solution that fitted the same purpose - with no lockins at all.

And about the 2 bytes MS wont let you touch - try to enforce that in a danish court of law - I dare MS! :)

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

[Seahawk]

I explained my point poorly then(Thats the punishment for not having englisg as my native language :)):

The thing for me is that if Sun started "fucking" with java developers, I will be almost as bad off as if MS started changing specs to complicate making OSS .NET platforms.

And tbh - I trust Sun only a little more than MS.

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

[Anonymous Coward]

Exactly what .NET libraries are you referring to? Mono has implementations of all the major .NET namespaces, including Windows.Forms, which handles UI stuff. There are even implementations of some of the Microsoft namespaces, such as Microsoft.VisualBasic.

Re:About time too

[truthsearch]

But Microsoft will not be able to break .Net in too many incompatible ways without alienating their customers.

But they are and they have, with many customers just going along. The .Net 1.1 runtime is not backwards compatible (it won't properly run all .Net 1.0 apps), even though it was only a minor version increment. They also changed many interfaces, so you couldn't always recompile on 1.1 without code changes.

Plus WinForms is already being dropped in the near future. Anything you develop today with a GUI in .Net will be considered legacy very soon. All new development is supposed to switch to a whole new API (Avalon?). Java did something similar with AWT and Swing, but they still support both. Microsoft's marking the WinForms API deprecated within a couple of years (by the time Longhorn's released).

In my view, and shared by many others, they alienated their biggest development customer base (Visual Basic) by not making any more fixes or enhancements to that line of software. They also didn't provide a seamless migration path. That's one reason why less than half of VB developers are switching to .Net so far. They lost many VB developers to Java. They've alienated many customers before, and they'll keep doing it. It already appears to be hurting their market share, but not their bottom line.

Re:About time too

[Anonymous Coward]

Does it make sense to be at the mercy of a company that can wipe you out at any time, regardless of the fact that the company hasn't historically done so?

I think it's better to be clear and free.

Re:About time too

[Darren Winsper]

Seeing as I've taken code compiled with VS.Net and run it on Linux using Mono, I call bullshit on that statement.

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

[aastanna]

The .Net 1.1 runtime is not backwards compatible (it won't properly run all .Net 1.0 apps), even though it was only a minor version increment. They also changed many interfaces, so you couldn't always recompile on 1.1 without code changes.

That's the risk you take when you use anything with a version number 1.0. With the development cycle the way it is you're basically a beta tester. The only real exception to this is open source software, since it is generally released to the public as 0.1, and by 1.0 it's rock solid.

Re:About time too

[truthsearch]

I agree. That doesn't stop a lot of zealous managers and developers from jumping in. It's quite ironic that they won't use the initial release of Office or Windows until many patches are tested, but they put .Net 1.0 on production servers almost immediately with complete trust it's secure and stable. Then 1.1 is released with a few bug fixes, but still more open issues than closed, and they upgrade the servers right away. I see it and hear of it happening all the time.

Re:About time too

[Anonymous Coward]

".NET 1.0 apps won't run on 1.1"

Every 1.0 app I've compiled compiles and runs equally well without code changes in 1.1, as 1.1 was mostly a bug fix.

However, even if .NET version incompatabilites existed, we have side-by-side execution. One can install .NET 1.0 and 1.1 on the same system without any incompatabilities. If your app requires 1.0, then you distribute 1.0. Simple as that.

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

[sbrown123]

That's the risk you take when you use anything with a version number 1.0.


Thats sad. Java 1.0 code still runs with Java 1.5. You get alot of deprecation warnings but it still runs.

And you are not addressing that the next version of .NET will make 1.1 incompatible. They will also require you purchase a new copy of Visual Studio.

Java has kept backward compatibility and does not require the purchase of expensive tools for each version upgrade. Im currently using Eclipse IDE and it works great with the latest version.

Re:About time too

[Anonymous Coward]

Any library under System.* or its subsidiaries is standardized. Anything under Microsoft.* is proprietary.

That said, to date everything you need is in the System namespace - The Microsoft namespace only includes some best practices libraries that aren't widely used, and some Windows specific things like registry editors that would be useless if they were in the open domain anyway.

Re:About time too

[Seahawk]

Do you have a link confirming that?

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

[Everlasting God]

Bullshit. Obviously you've never tried to run AIX-compiled java bytecode on aony of the HPUX JREs.

Re:About time too

[mingot]

The .Net 1.1 runtime is not backwards compatible (it won't properly run all .Net 1.0 apps), even though it was only a minor version increment. They also changed many interfaces, so you couldn't always recompile on 1.1 without code changes.

They don't have to be backward compatible. Period. Side by side deployment of the 1.0, 1.1, and 1.2 framework just "works" and if a program it targetted at a specific version of the framework that's what it will use. If you can be bothered go do a little research on how "DLL Hell" was addressed with the .net framework.

In a nutshell the 1.1 framework should not even be running 1.0 apps. They should be running on 1.0, and there is no magic you have to do to have application A use one version of the framework and applications A, B, and C use another.

Plus WinForms is already being dropped in the near future. Anything you develop today with a GUI in .Net will be considered legacy very soon. All new development is supposed to switch to a whole new API (Avalon?). Java did something similar with AWT and Swing, but they still support both. Microsoft's marking the WinForms API deprecated within a couple of years (by the time Longhorn's released).

In another thread talking about the threat of longhorn I'm quite sure you'd be calling it vapor and mentioning how it wont see the light of day for at least another half decade. BUT REGARDLESS, the applications you develop today are still going to work right next to the XAML apps that will be created. It's simply not an issue as different versions of the framework will continue to work side by side.

Your post really borders on FUD making it sound like the code you write today simply wont execute tommorow, and really that's just not the case.

Re:About time too

[mingot]

And you are not addressing that the next version of .NET will make 1.1 incompatible. They will also require you purchase a new copy of Visual Studio.

Again, side by side execution will work *IF* the newer version breaks the old one. In addition, how is one forced to purchase the lastest visual studio when both the 1.0 and 1.1 (and 1.x) compilers are free (as in don't cost money)? Quite a few people are using an open source IDE with the free compiler. And it would not really surprise me if we were to see the open source compiler able to take advantage of the mono compiler at some point in time (if it does not already).

Re:About time too

[kahei]

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

It's just amazing that people can post statements like this as fact without, apparently, having read a single doc or asked someone who knows what they're doing.

Sigh.

Re:About time too

[sbrown123]

Again, side by side execution will work *IF* the newer version breaks the old one.


If you give someone a app written in 1.0 to someone with a 1.1 runtime you run into the issue of it not running due to changes from 1.0 to 1.1. Backwards compatibility means that you would still be able to run the 1.0 compiled app on a 1.1 runtime. .NET is not 100% backwards compatible. Java is.


Quite a few people are using an open source IDE with the free compiler.


The ide you are talking about, I am guessing, is SharpDevelop. It requires installing the .NET SDK from Microsoft to run. Microsoft could, and probably will, close off downloading the SDK with a future version of .NET. They have done this in the past with other products and its perfectly within thier domain to do so. You have to understand that Microsoft is a company that makes money selling products. Visual Studio is a product. If SharpDevelop cuts into their profits they WILL kill it with this approach. They did not get where they are today by always playing nice.

Re:About time too

[Slime-dogg]

Microsoft has patents on some of the methods used in their libraries, but this doesn't mean that the libraries can't be re-written with different methods. It is very much like GNU vs. Unix, where the proprietary stuff is just re-written in an open way.

The difference between Mono and the Microsoft libraries is completeness. System.Windows.Forms is nearly there. The amazing thing is that Mono has got a larger number of supported databases than the Microsoft implementation. How about that?

Re:About time too

[aled]

Do you have a link that says otherwise?
If don't is you against us and we are more... :-)
Seriously, I would not go us far as to say that Java is open source but give IBM and Oracle lawyers some credit.

Re:About time too

[mingot]

If you give someone a app written in 1.0 to someone with a 1.1 runtime you run into the issue of it not running due to changes from 1.0 to 1.1. Backwards compatibility means that you would still be able to run the 1.0 compiled app on a 1.1 runtime.

No shit. The point is that when you can run the app in any sandbox you want it doesn't make a whole lot of difference.

.NET is not 100% backwards compatible. Java is.

Hrm, I seem to remember having quite a few problems getting Tomcat and Forte both running with the same VM back when I had the misfortune of working with Java.

They have done this in the past with other products and its perfectly within thier domain to do so. You have to understand that Microsoft is a company that makes money selling products. Visual Studio is a product. If SharpDevelop cuts into their profits they WILL kill it with this approach. They did not get where they are today by always playing nice.

Ok, what SDK being used by 10's of thousands of people have MS stopped offering for download replaced with a product that leaves a developer no recourse other than to send them money?

And they DID get where they are by playing nice with developers.

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:About time too

[Perky_Goth]

why doesnt ibm back them up anyway? that'd give sun cold shivers...

Re:About time too

[Seahawk]

I would hate the business success being in the hands of another companys lawyers - especially(fear of trolling) if these lawyers are american :o(

(And you first argument: I have a feeling you know why thats a bad argument! ;D)

Re:About time too

[truthsearch]

So your 1.0 apps that run on a very buggy platform must continue to run on that platform until you're willing to re-write it in a newer version. That's not acceptable.

It is also not acceptible to have 5 apps on one computer, each written with a different version of .Net, to each have the runtime in memory concurrently if the apps are to be running at the same time. Why should I have to use an extra gig of ram to run a few programs because each runtime isn't backwards compatible?

It's true your code today will execute tomorrow. But it's like saying it's OK to write new 16-bit Windows apps today. Yeah, it'll run, but you won't get any support, platform bug fixes, security checks, or anything else. Robert Scoble will tell you to use XAML today (not when Longhorn's released) because WinForms are the old way. So keep using WinForms, but soon don't expect any support or bug fixes.

You're a fool for relying on a platform that's never fixed or backwards compatible. Fundamental things like closing an open file still don't work 100% after the platform was released 2 years ago. If there's a fix in 1.3 you're telling me it's correct that I should have to rewrite my apps to use it. In attempts to fix DLL Hell, which doesn't exist to the same extent on any other platform, they produce a whole new set of even more complicated problems.

Re:About time too

[Anonymous Coward]

Ok, what SDK being used by 10's of thousands of people have MS stopped offering for download replaced with a product that leaves a developer no recourse other than to send them money?

Visual J++

Re:About time too

[mingot]

Bzzzt. Still availible and programs written with it will still run. They discontinued development, that's all.

Re:About time too

[sbrown123]

No shit. The point is that when you can run the app in any sandbox you want it doesn't make a whole lot of difference.


Apparently you have no idea what backwards compatibility is. Okay, lets make a simpler example:

Playstation 1 came out. Lots of games were built for it. Playstation 2 came out. For games built for the Playstation 1 to work on the Playstation 2 the Playstation 2 would have to be backwards compatible.


Hrm, I seem to remember having quite a few problems getting Tomcat and Forte both running with the same VM back when I had the misfortune of working with Java.


You were probably running a virtual machine that was too old for one of the two apps. Java is 100% backwards compatible. Not so much so the other way.


Ok, what SDK being used by 10's of thousands of people have MS stopped offering for download replaced with a product that leaves a developer no recourse other than to send them money?


Question with a question: name a SDK that works without Visual Studio besides .NET that is both supported and available for free download?

Re:About time too

[mingot]

Apparently you have no idea what backwards compatibility is.

Apparently you have no reading comprehension. My point was that you don't need backwards compatibility if you still have a playstation 1 hooked up to the television. Make sense? If an application written with version 1.0 the framework does not work with version 1.1 you can run it against the 1.0 framework. It's not backward compatibility, it's side-by-side execution. With that said, I have never had a problem running a 1.0 application under the 1.1 framework, so not really sure if the original poster was talking out of his ass.

You were probably running a virtual machine that was too old for one of the two apps. Java is 100% backwards compatible. Not so much so the other way.

Dunno, seems like one of them would not run on a newer implementation of the runtime. Perhaps it was just a buggy implementation. name a SDK that works without Visual Studio besides .NET that is both supported and available for free download?

Um, the platform SDK, which pretty much has everything?

Re:About time too

[sbrown123]

If an application written with version 1.0 the framework does not work with version 1.1 you can run it against the 1.0 framework.


Stop! Your killing me with laughter here. So you agree that .NET is not backwards compatible. Just say it to yourself a few times and let it sink in. Then, while you try to argue that you can do side by side execution of .NET apps of different versions read this notice on .NET frameworks on Microsoft's website:


Important: You cannot install two different language versions of the .NET Framework on the same machine. Attempting to install a second language version of the .NET Framework will cause the following error to appear: "Setup cannot install Microsoft .NET Framework because another version of the product is already installed."


For someone who is trying so hard to defend .NET you should atleast learn something about it beforehand.


Um, the platform SDK, which pretty much has everything?


Platform SDK? Are you confused into the belief that Windows is built around .NET? The humor continues! .NET is the only Microsoft SDK? You got me rolling now!!

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

Re:Code Examples

[dnoyeb]

That is a rather pathetic document. It reads like a sales pitch.

This code BAD. this code GOOD, see!! You want this code for sure!

Come on. If its valuable just show the merits. Instead it looks like one of those make over commercials where the "before" photo has the person without their hair combed, no makeup, and their face all sad...

Re:Code Examples

[bobbotron]

Thanks, that was a really helpful set of slides! :)

Is it okay to redistribute it to peers? I have some collegues who would be interested in seeing this.

Re:Code Examples

[Drakonian]

Thanks for the link. Here is a really nice demonstration of Enums + Generics + Enhanced for taken from that document:

enum Suit {clubs, diamonds, hearts, spades}
enum Rank {deuce, three, four, five, six, seven,
eight, nine, ten, jack, queen, king, ace}

List<Card> deck = new ArrayList<Card>();
for (Suit suit : Suit.VALUES)
for (Rank rank : Rank.VALUES)
deck.add(new Card(suit, rank));

Collections.shuffle(deck);

(Sorry, I can't indent that properly). As they said, this would require pages of code today.

Re:Code Examples

[Perky_Goth]

seems dead, here's the cache
clicky

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:Saves loads of code

[dnoyeb]

Yes but I have been concerned about the implications of this. Compile time checking is fine, but its one time. What if the class file is swapped?

Will all accessing classes just assume the type is correct because they believe if its compiled, it must by properly typed? Or are these types forbidden to be used on public interfaces?

In otherwords, I believe the calling method is passing type X. If its not a type X then the compiler will fail. But what of runtime now that the cast and subsequent type check is removed? What happens when I pass Y into it because I have a newer or older version of the class?

Re:Saves loads of code

[cerberusss]

It's a pure compiler construct. So yes, if you have an older version, it will result in a runtime ClassCaseException. But at least, the older version will run; which wouldn't have to be the case if the binary class format would have changed...

Re:Saves loads of code

[Anonymous Coward]

They'll be less enthusiastic about the 'net bill.

Re:Saves loads of code

[jpmrst]

Lots of explicit typecasts can be left out now

It's a great start, but it would be nice if the generics were worked into more libraries - for example, in the Swing model classes, it would be nice to be able avoid casts by taking Integers out of a DefaultComboBoxModel<Integer> .

But hopefully it's just a matter of time (or of Beta 2).

Re:Saves loads of code

[Trinition]

What is great about this, is that this saves loads of code. Lots of explicit typecasts can be left out now...

What is also great about that particular piece is that it has the potential to be faster. Casting in Java requires runtime checking of the Object check -- that's measurable overhead. By eliminating the need to cast (say because your List of Users is guaranteed to only have instances of User or a subclass in it), you are actually eliminating runtime overhead.

Re:Saves loads of code

[cerberusss]

Casting in Java requires runtime checking... you are actually eliminating runtime overhead.

That's a pretty interesting question, actually. Which brings a slew of other questions: Will the virtual machine skip those checks when it sees that it's a 1.5-compiled class? Can it actually see how a class was compiled?

Nice!

[Stupid Dog]

Also included are executables for Windows & Linux AMD64 versions!

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.

Re:Exactly

[NoOneInParticular]

Ever try to cross-comple a non-trivial C/C++ program? I do that all the time. Just use gcc and it will compile for practically any platform without a glitch.

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

[Anonymous Coward]

http://www.beanshell.org/

Script language with Java syntax; with the latest release
can also create classes with it at runtime;

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

[Sanity]

I use a real language.

Sorry, but weakly typed languages might be all well and good for toy projects, but for doing real work give me a strongly typed language like Java any day.

Re:steps toward Python

[Tyler Eaves]

Python is QUITE strongly typed, just IMPLICITLY typed, not EXPLICITLY typed.

Re:steps toward Python

[3h]

Interpreter for Java.

Re:steps toward Python

[Anonymous Coward]

Yeah, that's what makes it a toy language.

Re:steps toward Python

[Anonymous Coward]

Jython ahoy!

Re:steps toward Python

[Anonymous Coward]

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

If python was 'weakly typed', you could do this -

foo = 5
bar = "duh"
foo = foo + bar
... but you can't, because it raises a (gasp) type error! Just as a comparison, consider C -

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

(before I get flamed, yes, I _know_ this is nonsense, so was the python example - the point is python complains, C doesnt. Btw, the C example is not valid C++ code (C++ has stronger typing semantics))

I personally find static typing to be relatively useless. It basically is only useful for optimization purposes. By knowing the type at compile-time, certain optimizations can be made. But, we all know that "premature optimization is the root of all evil" ;)

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.

Re:steps toward Python

[Anonymous Coward]

This is what make you to make a toy comment.

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

[Anonymous Coward]

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

Where did I mention a language being "ok" because of it's typing semantics? Hm? Well? Gee. Nowhere.

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

Irrelevant. I could have assigned a pointer to a struct (which is an ADT for I dunno, a parse tree.) to a char* - which is just stupid. The whole damn point was C's lack of type checking. Duh?

"Wrong. People are lazy. Give them the easy way out and they will take it."

Dynamic typing is a Good Thing. It allows for rapid development. So yes, people are lazy and they will take the easy way out. That's a Good Thing, in this case.

Now, back under the bridge, Troll.

Re:steps toward Python

[WWE-TicK]

> Dynamic typing is a Good Thing. It allows for
> rapid development

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

Re:steps toward Python

[haystor]

Lax constraints let us more freely express our thoughts in code.

This may be a problem for you but it is not a problem for all of us.

Re:steps toward Python

[Anonymous Coward]

What lame idiot moderated this as "insightful" instead of "troll"?

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.

Re:steps toward Python

[Anonymous Coward]

Never saw OCAML's type inference engine, have we?

Re:steps toward Python

[The12thRonin]

Lax constraints let us more freely express our thoughts in code.

That's what comments are for. Lax constraints allow design flaws to slip through the cracks, not to mention code bloat.

Re:steps toward Python

[NumbThumb]

one can infer some type-info from the use of vars/params/etc. But Python does not really allow for that: if i write a function like this:

def foo(item):
frob(item.bar)

how is the inference-engine to know what type of object is expected for param 'item'? If the engin knows *all* class-declarations, and restrict the use of the function foo to objects that are instances of classes declaring 'bar', this would be much to strict: someone using your function could dynamically create the bar-field in some random object and use it with the foo function. How are you going to assert that this is allways/never the case?!

Re:steps toward Python

[Anonymous Coward]

>What lame idiot moderated this as "insightful" instead of "troll"?
Probably the same that smoked your entry with a -1.

Re:steps toward Python

[Anonymous Coward]

Until then - keep your coffe for your blind-dumb managers. I use a real language.

Oh boy, that sure was insightful; thank you very little moderators.

Now, are you sure you don't miss things like:

• Performance. Java code on 1.4/1.5 Sun/IBM JVM runs circles around Python code
• JavaDoc that allows some level of literate-ish programming
• Actual fully functioning high-performance generational garbage collector, with goodies like soft and weak references for caching

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.

Re:steps toward Python

[GOD_ALMIGHTY]

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

Can't help too much with the memory footprint unless you want to look at J2ME, but you can configure a J2SE vm to run with a smaller footprint than the default settings.

Interpreting source I can help you with: http://www.beanshell.org/

So we're down to one reason you need to switch and that needs a clearer definition.

Have fun!

Re:steps toward Python

[Anonymous Coward]

Java is designed for large teams, where you certainly don't want any "free thinkers". Your argument is basically that Python is only good for student and personal projects.

The other issue with dynamic typing is that it can easily lead to security holes, especially if you are doing database or filesystem work.

Re:steps toward Python

[axxackall]

J2ME and even J2SE is not a solution for me. I need a functionality of J2EE (specifically EJB, JAX, JMX, JMS). With the same version of Python interpreter (not like some pitty micro-edition) I can get that functionality with a compbination of libraries (like Twisted or Zope) still sitting within the footprint that is 10-100 times less than I've got from any EJB provider.

By the way, the footprint size per se is not the only negative factor that drives me away from Java: with a big footprint size the startup time from noJVM in memory to the running application is getting unacceptable long. And if the logic of the application is to load it up by demand - Java is out of consideration.

Re:steps toward Python

[Anonymous Coward]

Looks more and more like Python.

You mis-spelled Lisp.

Re:steps toward Python

[cakoose]

How are you going to assert that this is allways/never the case?!

By solving the halting problem. Duh!

Re:steps toward Python

[aled]

"I need a functionality of J2EE (specifically EJB, JAX, JMX, JMS)."
"With the same version of Python interpreter (not like some pitty micro-edition) I can get that functionality with a compbination of libraries"

I doubt you really need the full functionality of those Java packages if you can replace them with a few libraries. Perhaps you should use tomcat/jsp/struts and a smaller xml parser or a standalone app.
Do you need to startup many times? A J2EE server should be always up. BTW the beta says it has shorter startup times and shared classes between sessions.

Re:steps toward Python

[aled]

I disagree with a few thing. You may not like Java, ok. Java may use more memory/cpu than python for your project, ok. Java may not have features that Python has, ok. But that doesn't mean Java is as good as anybody language or less capable. May be you have not noted it but there are a lot of things that Java does that Python doesn't do.

BTW less is more... is false. Reading too much Orwell?

Re:steps toward Python

[owlstead]

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.

Interesting, but why would you be so much faster? It isn't that you don't have to know what's in your variables all the time. If you worry about refactoring, or remembering the types, use a good IDE.

As a sidenote, I currently use Eclipse for this. Fortunately, Eclipse will support 1.5 pretty quick if I've read the USENET discussions correctly. My development time was about halved, though I started off with plain text...

Re:steps toward Python

[Anonymous Coward]

You call Python a real language? Python is for script monkeys. Real languages are C, C++, Assembly, etc, not for the weak of heart like the script monkeys.

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

[bwy]

This is the first true Beta release. The release that showed up at the end of December/beginning of January was marked as an alpha release.

Prior to that some pieces of the JVM were available via the early access program but it was nowhere close to a complete J2SDK distribution.

Re:Benchmarks

[SashaM]

Hmm, I guess I'll need to check that, but with what I installed a month ago I have:

[sasha@jupiter tmp]$ java -version
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b31)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b31, mixed mode)

So at least the VM seems to think it's a beta ;-)

Re:Benchmarks

[bwy]

True, I noticed as well that the code thought it was a beta. However the text on the web site had warning that it was in fact an alpha release. I think there was some real haste to get 'something' out since Tiger was already late.

The version I grabbed today reports itself as b32c. Anyway, it is good to see it is out there now in plain view. I was really hoping they'd move to support anti-aliasing in native Swing components.. for such a major release I really see no value added to Swing at all. Heck, at least we got mouse wheel support when going to 1.4 from 1.3.1!

Re:Benchmarks

[grungeman]

And as I can see from the frames on you screenshots you ave licensed the Alloy Look&Feel. How much was it?

Re:Benchmarks

[zephc]

Would that new theme for Swing be called NuMetal? :P

Re:Benchmarks

[SashaM]

What you see on the screenshots is the KDE Alloy Theme, not the Java Alloy Look&Feel.

Re:Benchmarks

[Anonymous Coward]

I bought it, and it's just great. I really love it. If I remember correctly, it was on the order of $200

Re:Benchmarks

[grungeman]

Cool, thanks for the pointer

Re:Benchmarks

[Anonymous Coward]

That is really amazing. Too bad other languages can't keep up. Let's try Ocaml for example:


Hello World!
real 0.00
user 0.00
sys 0.00


Hm. No progress at all from the previous version.

Re:Benchmarks

[owlstead]

Dunno, I could not get any of the new language features to work on my system with that version. It was more an Apha renamed as Beta version to me. Oh well, let's try this one.

It must be busy there though, I couldn't fill my 4 mbit/sec pipe, which Sun normally fills up pretty well.

Re:Benchmarks

[tunah]

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

There was a very outdated (last changed July) early access version and some alphas you could obtain, including one that was semi-public, but they were buggier and had no docs.

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#?

[PhrostyMcByte]

with no big company to support them (IBM, Sun and other Linux/Open source backers already have a huge stake in Java) *cough* Novell is supporting Mono.

Re:In Response to C#?

[salimma]

that they would always have toplay catch up, with no big company to support them

Novell, Intel and HP. In fact, Mono's libraries (as opposed to the compiler, interpreter and JIT) were relicensed from LGPL to MIT X11 to accomodate corporate backers.

Re:In Response to C#?

[ajagci]

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

Who cares? Open source programming in Mono uses toolkits like Gtk#, which are more efficient and more familiar to OSS programmers anyway. .NET compatibility in Mono may be a migration path for Windows programmers and it may appeal people with some special needs, but even if .NET compatibility was completely dropped tomorrow, Mono woulc continue to be a great platform.

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)

Gosh, yeah, just like IBM and Sun also had a huge stake in their own UNIX systems. (Well, Sun is still trying to kill Linux, but IBM at least has pretty much given up AIX for Linux.)

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

If you look more closely, you'll see that they really have failed to address the hard stuff: generics over unboxed types, value classes, efficient native code interfaces, etc. So, no, serious limitations remain in Java and the 1.5 changes are no reason for much increased confidence. I would actually ask: "what took you so long?"--these changes could have been implemented years ago with no problems.

Besides, Java still is not an open platform and there are no open source implementations of the entire platform, so when you compare it to Mono, you are comparing apples and oranges.

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:In Response to C#?

[fforw]

Besides, Java still is not an open platform and there are no open source implementations of the entire platform, so when you compare it to Mono, you are comparing apples and oranges.

GCJ!

The situation is very similar:

• both are free
• both offer a running implementation of their platform
• both are missing important parts of the API (GCJ has no swing, Mono has no System.Windows.Forms and maybe won't be able to implement it because of software patents).

Re:In Response to C#?

[zjbs14]

http://www.go-mono.com/winforms.html

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:The good and the ugly

[fruity_pebbles]

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.

Sun's Windows JVM (at least 1.4.x) doesn't use the native font engine either, so if you have Windows' ClearType enabled Java apps look stupidly ugly next to other apps on your desktop. If you enable the JVM's font anti-aliasing things are better for the most part, but some characters aren't rendered very well so the overall result is still ugly.

Re:The good and the ugly

[The boojum]

Indeed, yes. That's the single biggest issue I have with Swing. As a graphics programmer, I can't abide by aliasing in any form, and it seems like the default fonts for the Swing L&F are handpicked to alias as much as possible. (Look at any letter "y" in a Swing app to see what I mean.) It's almost painful for me to look at a Swing app. I'd be fine with using the Swing L&F if only they'd make it so I could antialias the text. I'm even okay with the Java antialiaser; anything's better than no antialiasing!

<rant> I've looked into it in the past, and found that there is no way to globally turn it on. I'd hoped that since Swing is supposed to be light-weight, I could just turn on anti-aliasing for the heavy-weight frame and it would trickle down. Instead, the only way to get antialiasing in Swing is to subclass each widget, and override the paint method to enable antialiasing and then chain to the superclass's paint method. Worse, that only works for simple widgets. For compounds like drop-down boxes, you end up with the button being anti-aliased while the list is aliased because it uses the standard list widget. Alternatively, I know there are alternate L&F's that provide this, but then anyone using the program has to install it. And even then, I'm locked into a single L&F if I want antialiasing. I can't switch L&F's (to the Windows one, say) and preserve antialiasing. Grrr... </rant>

suck it baby

[Anonymous Coward]

suck my cock, suck it you shit fucking bitch, I'm gunna fucking wipe you bitch all over the fucking hill, you dumb slut, FUCK U

Quick Links

[osewa77]

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

come on down

[Anonymous Coward]

yeah this is it CLICK NOW!

Sun Marketing?

[Anonymous Coward]

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

Sun has a marketing department? Jeesh, its like saying Novell has a marketing department. This is one thing that companies need to really wake up and smell the coffee on. Although good products can sell themselves, they sell better with good marketing to entice the corporate types. Marketing is the reason why M$ is where it is today.

Re:Sun Marketing?

[ClosedSource]

You're not serious. Sun got the press to report that Java was a new computer language that allowed, for the first time, programs to run on ANY computer. That's the biggest marketing coup in the history of computers.

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.

Re:Rubbish.

[Moonbird]

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

Bull.

Re:Rubbish.

[egomaniac]

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

Oh. So basically, what you're trying to say is "I have no idea what I'm talking about!". I gotcha.

Absolutely no way to avoid? Hotspot keeps track of whether or not a particular method actually has multiple implementations (and thus really needs to be virtual) or not. If not, it can treat the method as if it were not virtual and, for instance, inline it.

The complication in doing so is that Java supports dynamic class loading -- you can load a class from anywhere at any time. Such a class might contain a new definition for a method, which suddenly makes a virtual-but-not-really method truly virtual, with multiple implementations. Hotspot is smart enough to realize this, find every method in which it has made an assumption that a method only had a single implementation, "deoptimize" them (throw away the compiled native code and go back to running Java bytecodes), and potentially reoptimize them.

And the really cool part is that it can do that even while the method is executing.

Now, why is it that people on /. insist on screaming "That's impossible!", even when something was implemented years ago? Seriously, if you're going to claim that something can't be done, please at least pick something that hasn't been done yet. That way there's actually the possibility of being correct.

Re:Rubbish.

[NoOneInParticular]

Wow, so what you are saying is that unless there is no need for a virtual function to be virtual, the overhead is there. In what way does this invalidate the grandparent who was assuming that virtual function existed for a reason?

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:J2SE 1.5 in a Nutshell

[d-rock]

The syntactic sugar is nice, but the changes to the Networking classes and additions like java.util.concurrency (http://java.sun.com/j2se/1.5.0/docs/api/java/util /concurrent/package-summary.html) are going to make it much easier to write robust, high-performance software.

Derek

Re:J2SE 1.5 in a Nutshell

[Trinition]

Autoboxing and Auto-unboxing of Primitive Types

This one worries me the most. I fear people will start lazily letting Autoboxing turning their primitives into Objects when it would be better to make a class that can use a primitive directly.

Consider a HashMap where your keys will always be an integer. You could:

1. Use autoboxing so every put/get that you use an 'int' is instead constructed as an Integer object, on which the hashCode() method is called to find the bucket, and then equals() is called repeatedly to find the matching key in that bucket, or...
2. Make a IntKeyHashMap that takes an int directly (no memory allocation / instantiation overhead), uses its literal value as the hashCode (no method call) and uses the primitive == operator instead of calling .equals() (again, no method call)

Granted, the hashCode() and equals() methods on Integer are very simple and fast methods, and memory al/deallocation has gotten a lot faster with thread-local heaps and generational garbage collection. Still, if this were in the inner loop of your program, which would you prefer to have?

Maybe I shoudl just shut up and let HotSpot take care of it for me.

Re:J2SE 1.5 in a Nutshell

[bill_mcgonigle]

- Desktop Client

Hey, that's a category, not an enhancement. You weren't just copy 'n pasting for karma, now were you?

Perl is Better

[Walrus99]

Java is way to difficult to learn and implement. Gimmie good ol' Perl any day. No variable declaration, no worry about classes and objects, just write it out, drop it in the cgi bin and you're ready to go. Perl is the gurilla attack of programming. Go in, get the job done, and get out. Maybe they should call it SEAL.

the new Tiger Beat is out?!?

[Anonymous Coward]

who's on the cover - sean cassidy or leif ericson?

C# the innovator???

[snatchitup]

I luv spin. But, if C# says it's an innovator, then it already admits that C# isn't an original language and a pure marketing ploy.

In reality, you may only use the term "Incorporated".

Replace the term "innovated" with "incorporated" in the previous post, and suddenly it's matter of fact, instead of a troll.

Re:C# the innovator???

[Anonymous Coward]

Disclaimer: I'm a C++/Java/Perl/C# (and a few more languages) developer and I'm not trolling.

I luv spin. But, if C# says it's an innovator, then it already admits that C# isn't an original language and a pure marketing ploy. In reality, you may only use the term "Incorporated". Replace the term "innovated" with "incorporated" ...

And replace "reference" with "pointer" in Java's literature and suddenly all the arguments of "C/C++ is dangerous because of pointer problems..." or "Java is safer/better/sexier because there aren't any memory issues to worry about..." become what they truely are: hype.

IMO, what it boils down to is that there hasn't been significant advancement in programming languages for about a decade or so (maybe more, depends on what you perceive as "significant"). Sure, tools have advanced, auto-generating code is slightly easier, libraries are more mature, standards are being adopted, I'll give you those.

But when was the last major concept introduced into a mainstream development environment? Templates/generics? Exceptions? User defined types? All of those have been around for 20+ years (in one shape or another).

But wait, some might say, there's the VM! That's a significant change from the bad old days of compiling to a specific platform right? Wrongo-bucko. That's been around for plenty longer than you'd think (Perl ring a bell anyone? What about ye ol' BASIC environments from years gone by?).

So what it comes down to is whose marketing machine/message is better. Right now there's plenty of anti-MS sentiment (most of which is well earned in my eyes), so Sun can use that to get momentum behind its proprietary offering. However, MS will push in its own behemoth fashion and will have its cult-like following too.

As for me, heck, I'll keep doing what I do now for a living. Implement systems in the environment that the customer is willing to pay for.

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:

[Anonymous Coward]

> I don't want to start a flame war, but do you think that the
>pressure of .Net pushed some of these features through th > at Sun seemed to be holding off on for the longest time.
> Such as enums, generics, boxing, foreach loop, etc.

The only feature that Sun held back was Generics;
the others (for loop, boxing, enums, varargs...) haven't been
discussed before; Some of them were probably influenced by C# (especially auto boxing);

>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.
.NET was first hyped (er, sorry: I meant. introduced)
in 2000

with C# and other languages for it.

murphee

Re:Just a Question for everybody:

[nberardi]

Well it is good to know Microsoft did something to help the Open Source community even if it was through proxy :)

Re:Just a Question for everybody:

[Anonymous Coward]

It's sort of funny you consider Java to be Open Source.

Re:Just a Question for everybody:

[nberardi]

No I don't consider Java to be open source, but there are tons of open source projects that will benifit from these "enhancements"

Re:Just a Question for everybody:

[Anonymous Coward]

Yep, C# has had enums, boxing, simple iterators like foreach, indexers, and other goodies Java is just now coming into. (now if only Java had a const keyword instead of that laborious "static final"!)

I think it's a healthy competition. C# 2.0 was alpha'd a few months ago, so now Sun is trying to rush a new Java out the door. Wait a few more months and MS will be rushing C# 2.0 and .NET 1.2 out the door. :-)

Competition is good... of course, competing with the evil empire often ends in a loss for the opposing team.

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:Just a Question for everybody:

[Anonymous Coward]

> others (for loop, boxing, enums, varargs...) haven't been discussed before;

People have been bitching about the lack of foreach, boxing, and enums since Java 1.0.

Maybe these weren't official submissions to the Java Standards Board, but if Sun was really paying attention to developer feedback (as Microsoft was), they would have been aware of these issues.

Re:Just a Question for everybody:

[blamanj]

No. If you look at the historical documents, Sun has been planning these features for some time. Experimental versions of generics predate even 1.2.

Now it is possible that the timing of the features changed, but many of these features have been "in plan" for quite some time.

Re:Just a Question for everybody:

[nberardi]

.Net in some cases already supports Java.
- Converter for Java to C#
- J#
- Displaying .NET Windows Forms from Java SWING

So I think the big question is when Sun is going to put something out that allows Java to support C# code. I agree only IBM can probably compete against Microsoft of this kind of work.

Re:Just a Question for everybody:

[nberardi]

Sorry links disapeared:
- C# using Swing
- Java to C#
- J#

Re:Just a Question for everybody:

[jilles]

J# is totally useless for anyone that downloaded a sun sdk after 1998 (the year they launched java 1.2 if I'm correct).

What I was thinking about is something like a more or less transparent bridging of the boundaries between both virtual machine architectures (e.g. java objects calling a .net object or vice versa, C# class extending JPanel, that sort of thing). That should require a fair amount of tinkering at the virtual machine level but it is not impossible IMHO.

Both MS and Sun are too entrenched to do this but IBM typically has to work with both of them (or at least their customers require them to).

Re:Just a Question for everybody:

[mauddib~]

Most, if not all, of these features existed long before .net came (at least enums, generics and foreach loops do for sure). The problem with these features is that they actually make a sort of syntactic sugar which will make the language harder to implement and test. Moreover, foreach loops do require a specific class library (just like exceptions do), therefor coupling the Java library to Java syntax and introducing alot of complexity and removing elegance.
Its just a matter of aesthetics. It's not hard to implement these features (actually, we've made a language called "taaltje" that could run on the JVM and had stuff like enums and a "sort of" boxing). It wouldn't be hard at all to implement a foreach statement (just typecheck the argument and place it in a boilerplate JVM intructionlist).

Re:Just a Question for everybody:

[nberardi]

Oh yeah I totally understand that all these features existed before. Enums and Genericts game from (C++) foreach loops (VB). I don't know about implimenting another class library for a foreach loop, but you will definitly need a common interface so it knows how to access to the loop. I don't really understand the elegance statement, because personally I will find it alot easier to write.

enum Numbers { One, Two, Three }

than to write

final class Numbers {
static final One = 1;
static final Two = 2;
static final Three = 3;
}

Personally I think the enumber implimentation is more elegant.

Generics serve one function.

[Anonymous Coward]

They save typing, and by typing I mean developing callusses on you fingertips.

Good to see generics support!

[chajath]

this feature is what c# needs! Too many times I come across all sorts of casting errors, and I can't be botherd typing up all the casting needed.

FOAD

[Anonymous Coward]

fuck off and die.. all of you

Slow Down CowboyNeil, you fucking fat fuck!!!

Slashdot requires you to wait 2 minutes between each successful posting of a comment to allow everyone a fair chance at posting a comment.

It's been -324231342 minutes since you last successfully posted a comment

Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form. Please try again. If the problem persists, and all other options have been tried, contact the site administrator.

Re:FOAD

[Anonymous Coward]

Slow Down CowboyNeil, you fucking fat fuck!!!

Aww... someone needs a hug and a warm cup of cocoa!

Re:FOAD

[Anonymous Coward]

Broken Bones fan, perchance?

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.

Re:Excuse me but:

[Anonymous Coward]

2. Verifying the correctness of any program in any Turing-complete language is in general impossible

Correction: verifying the correctness of every program in any Turing-complete language is in general impossible.

There are always programs that you can verify... just not all of them.

about time

[chrish]

Is this the patch that finally makes Java fun?

(Note: I work in a Java shop. Also, I personally think Java is a serious pain in the ass, mostly because of runtime issues, not language issues. But hey, I'm mostly a docs guy.)

Re:about time

[JavaLord]

But hey, I'm mostly a docs guy

that explains everything.

SWT

[Sanity]

I find it hard to imagine that anyone is still using Swing these days unless they are locked in to it, SWT is the future of Java GUIs.

Re:SWT

[brett_sinclair]

SWT is the future of Java GUIs. I agree. But, nevertheless, it's a pity that Sun is letting Swing bitrot. I'm still a big fan of Swing's API, flexibility and close-to-perfect crossplatformness.

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.

Re:SWT

[Anonymous Coward]

Some religious nuts still believe in Swing, and still have the ear of some PHBs.

Aside from the 2 second gc delays with Swing, it just doesn't look like part of the native OS. Users (especially desktop users) don't really care whether they're running java or C++ or C#. They do care how their app looks, and if 99 apps look one way, and the other one looks different, guess which app they're going to cast a distrustful eye on? Guess which app they're NOT going to spend money on to buy? You think I'm going to spend my precious time, writing shareware that's going to get ignored?

And don't tell me the windows L&F in swing is good enough. IT IS NOT. SWT isn't exactly great either - but it is good enough. Barely. But SWT is evil, because it's not Pure. Bah, you religious nuts - try living in the real world just for once, will you?

Re:SWT

[mrm677]

If SWT is the future, it would sure be nice for it to show its face. I'm not a dummy, but I can't find any SWT API documentation. I surfed eclipse.org silly without finding anything.

Re:SWT

[jonabbey]

My app gets downloaded every day to run on a wide variety of systems. I know that SWT is supposed to be compatible with Java Web Start, but I don't understand how you can make a JNLP launch package that includes the shared objects/dll's for all of the permutations of Windows, Linux, Macintosh, Solaris, OS/2...

I'd love to have a higher speed GUI, and I like the idea of a high quality native look and feel (so long as the native look and feel isn't Motif, ugh. Guess I need to make sure those Solaris systems have GTK, huh?), but the advantages of guaranteed ubiquity on the Java platform leave Swing my choice for the time being.

Re:SWT

[lokedhs]

Very far into the future then, since currently there exists only a single real application that uses SWT.

Re:SWT

[Anonymous Coward]

I don't understand how you can make a JNLP launch package that includes the shared objects/dll's for all of the permutations of Windows, Linux, Macintosh, Solaris, OS/2...

Implement your jnlp as a JSP, and define a servlet mapping with a jnlp extension which runs the jsp.
In it, check the user agent in the request header, and define your package according the OS. I put native binaries in a jar, (one jar for each platform)
and on download, unpack the jar into a temporary directory.

Hope that helped.

Re:SWT

[Sanity]

SWT doesn't come with a MVC approach as Swing does

You obviously haven't heard of JFace.

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

[jonabbey]

It did, thanks.

That's still kind of gross, though. Particularly when you may have a significant variety of OS, library, and distro revisions to worry over.

Has the SWT community provided a standard set of templates and resources to make it easy to do this? If I could download a tar file or GUI library shared objects for a wide variety of operating systems, along with the appropriate browser detection code to provide the shared libraries, that might make it seem a bit more tractable.

Of course, it would be even better if the JNLP protocol and launcher could do this.. I'd hate to pass somebody some useless DLLs just because their copy of Mozilla Firebird for Linux is set to emulate the IE/Windows user agent string.

Re:SWT

[curunir]

Try Google (the second link)

Also, there's quite a bit of documentation on the SWT project page (available from the homepage projects->The Eclipse Project->Platform->SWT)

I've yet to find online javadoc for the 3.0 version since they haven't had an official release yet and they only have it for official releases, not the milestones. If you want that, download SWT and run javadoc manually.

Re:SWT

[Sanity]

JFace is pretty central to SWT - but you aren't forced to use it. How does forcing the developer to use JFace help anyone?

Re:SWT

[harmonica]

In my experience forcing something on developers can also enforce better design. Not everybody checks out all the options, some people are just lazy and the result is less than par quality code.

As an example, the missing responsiveness of some Swing applications comes from the fact that there are no good and well-documented helper classes for running (more or less lengthy) tasks in different threads. You can find out how to do it right, but it's harder than necessary and many developers just don't care because it 'kinda works'.

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?

Re:What about HttpSession objects?

[brett_sinclair]

is there any note on how this may impact things like HttpSession or HttpServletRequest attributes, where different data types are essential?

No impact whatsoever; generics is supposed to be totally backwards compatible. So you can still store Objects in a HttpSession, use a plain HashMap (without pointy brackets), etc.

Re:What about HttpSession objects?

[NorthDude]

You are not forced to type your lists, you can still put Objects into them and cast them back if you need to...

Re:What about HttpSession objects?

[andrewscraig]

Actually, if you do HashMap without pointy brackets, you'll get a warning from the compiler about not using checks, so you'd have to use something like

Map<Object, Object> m = new HashMap<Object, Object>();

Re:What about HttpSession objects?

[Delirium Tremens]

You are confusting J2SE and J2EE.
HttpSession APIs are defined in J2EE, which typically tries to limit its dependencies on J2SE.
For example, J2EE 1.3 requires J2SE 1.3; and J2EE 1.4 requires J2SE 1.4 (that's kind of easy to remember, eventough it's actually coincidential since their release cycles are totally independent).
So since the latest J2EE specs -- J2EE 1.4 -- does not have any dependencies on J2SE 1.5, they can't really promote generics in there.

Now, technically, I think it might still be possible to provide a customized servlet.jar file with extra classes -- without touching the existing ones -- and get generics in there. But legally, I am not sure that is allowed.

Re:What about HttpSession objects?

[lokedhs]

No you don't. You only get the warnings if you try to do stuff like:

List<String> l = new ArrayList<String>();
List l2 = (List)l;

I haven't tried the beta, but in the alpha it was impossible to cast away that warning.

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?

Re:Code is for reading as well as writing

[goodviking]

While I agree that readability is important, I don't believe that this is so much a function of the language, as a function of coding standards and documentation for a particular project. Obfuscated java is no less readable than obfuscated Perl. On the other hand, a project that is well documented and coded to a style standard can be easily maintained in assembly.

Re:Code is for reading as well as writing

[Drakonian]

I'd disagree with you an enums - they make code much more readable. Better than having tons of public static final ints declared, with the additional benefit of being typesafe.

Re:Code is for reading as well as writing

[gidds]

Yes, coding standards are important, and personal responsibility is also important. It's possible to write a monstrosity in any language! But IME, with its nice clean syntax, simple scoping rules and namespaces, doc comments, and well-designed libraries, Java makes it easier to write clean, elegant code, and harder to write bad code, than most other languages. I'm just concerned that these changes don't spoil that.

Re: Code is for reading as well as writing

[gidds]

I don't really know -- I haven't used them yet! I'm just raising the possibility. Experience will tell.

Up to now, I've generally used the 'typesafe enum' pattern (a class with fixed, named static instances) instead of integer constants. So this won't be such a wrench. And it certainly has a lot of potential.

Re:Code is for reading as well as writing

[tunah]

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.

It's possible to write unreadable code in any language. With enums, replacing COIN_PENNY with Coin.PENNY seems to be an improvement, the only thing i'm not sure about is the fact that switches on enums are unqualified, such as: switch(myEnum) {
case PENNY: // not Coin.PENNY
...
}
so to check what "PENNY" means you have to look for the type of myEnum.

As far as static imports go, they can be used for good or evil :) IIRC, they were mainly a replacement for the use of interfaces to gain access to constants.

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!

[Doug Neal]

Gah, disregard that. Of course I meant, stuck on 1.4.0.99beta-1 (wanting 1.4.2) :)

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!

[Espectr0]

It's a shame you are using Debian. Really. But what stops you to get the .bin installer? And why are you waiting for blackdown?

There won't be a debian package for sun's java ever. I am not trolling here, it's just the facts

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

Re:Someone please make a debian package!

[ccoder]

<p>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/</p>

Excuse me, but since when is chmod 777 on ANYTHING a good idea?

Re:Someone please make a debian package!

[Gerald Turner]

Since 1.4.0 I've been contributing an alien patches that uses alternatives, installs mozilla plugin, etc.

Install alien.
Download the JSDK RPM.
Run 'alien j2sdk_1.4.2_03.rpm'
Install j2sdk1.4_1.4.2_03-1_i386.deb.

Re:For more information check out theserverside.co

[Anonymous Coward]

Thanks

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

[Progman3K]

>Java has binary portability

That's only true for trivial applications.

For example, Sun, who should know how to make 'standard' Java apps if anyone does, used to distribute DIFFERENT packages for their Forte Java development environment.

"Oh, but that's different!" I hear you saying.

Exactly; every situation is different.

Re:C is portable too

[deanj]

That's only true for trivial applications.

I've been involved with many large scale Java projects, and I can say your statement is pure FUD.

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:C is portable too

[Anonymous Coward]

As long as you stay away from the GUI stuff, and you aren't doing anything funky with the hardware, yeah, java is portable.

But, try doing something even remotely wierd, like writing to a serial port, and you'll find just how "portable" java is.

Java works very well, if all you need to do is move some buffers around and make some network connections.

It's the new COBOL, except you're not wearing ties anymore. Given the way the economy is going, that probably isn't too far away either.

Re:C is portable too

[smallpaul]

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.

What you mean to say is that the C language is not tightly bound to portable APIs for GUI, DB access, printing and so forth. Nevertheless, you can get portable APis for GUI and for DB access. Perhaps for printing also. The downside is that you have to assemble the portable library yourself. On the other hand, many Java programmers do so also by rejecting Swing in favour of SWT. But the more common thing is to reject Java the language because you do not like its GUI toolkit. That's too bad but is a natural outcome of the fact that Sun bundles everything (language, VM, GUI toolkit, server APIs and now Desktop operating system!) under the Java buzzword.

Re:C is portable too

[aled]

One may love the preprocessor but get married with ./configure. Oh wait...

C#

[Space_Soldier]

Still behind C# and the .NET Framework in general.

Re:C#

[steve_l]

C# language? Maybe. But .NET framework? I dont think so, though in places one is ahead of the other. And Java has some things (EJB) that it is not clear the other needs or wants.

The thing about .NET is that it adds many features by binding straight to the windows implementation. The file model? WinNT. The data access model? Sql Server. The UI model? Windows.

Where .NET gets interesting is in Longhorn, though it will be some time before that moves from being a VMWare image on my box, to being the base OS.

Same old same old

[Greg W.]

*Sigh*... you can get precompiled binaries for Windows x86, Linux x86, Solaris SPARC and Solaris x86. Whoopie. Gee, how exciting.

Oh, and the downloads page actually confused me for a second. They have a giant section labelled "32-bit/64-bit for Windows/Linux/Solaris SPARC
32-bit for Solaris x86". I kept thinking, "Why do they offer a Linux SPARC version but not a Linux x86 version??" Then I figured out how to parse it. When they write "Linux", they mean "Linux x86", because there aren't any other Linux architectures on the whole planet, right? Sheesh.

Excuse me while I continue not using Java(R)(TM) on my HP-UX workstation at work, or on my OpenBSD x86 box at home (but Kaffe sort of runs on the latter).

Why can't Sun just release a god-damned TARBALL OF THE SOURCE CODE and say, "Here you go. Here's Java 1.5.0 release candidate 1. We'd like to have some help porting it to FreeBSD, OpenBSD, NetBSD, BeOS, Mac OS X, AIX, HP-UX, Tru64, IRIX, and so on. Patches are welcome. In fact, we've released the entire thing under the new BSD license (without advertising clause), so you can integrate it with your applications, include it on official Debian CDs, etc."?

*Sigh*

Re:Same old same old

[dcocos]

Ummm, actually they do release the source, maybe not for beta code, but for the release versions. When my gentoo box upgraded to a new version of gcc, I had to recompile J2SE, took forever but when you ran java -version it would show my hostname. I actually just finished downloading and installing and they do include source (though i'm not sure that you could build with that alone)

Re:Same old same old

[Anonymous Coward]

Another thing regarding the packaging that pisses me off is that the RPM version for Linux they distribute behaves unlike any other package you can find on your system. Java is the primadonna that refuses to fit in, "Oh, you think just because you installed the RPM that you can actually run the program now? Hah!". Why distribute it as RPM if you're going to start creating top level directories in /usr, what makes Java so special it thinks it deserves this privilege? Maybe on Solaris you can get away with that sort of stuff, I dunno, but not on Linux in 2004.

THIS is how RPM packages work (Sun People take notes):
1. I install the package.
2. I type "java" or "javac" and the program better run!
3. There is no step 3. The browser plugin and other stuff if applicable was autodetected and installed in step 1.

Ok, I'm done ranting now.

Re:Same old same old

[ajiva]

You can't just "recompile" Java. There are lots of architecture specific code in there that requires ALOT of work to port. Go download the SCSL code from Sun, and then tell me how easy it was to port to HPUX.

Re:Same old same old

[cheekyboy]

You dont understand, just so the manager can keep his $250k job, he has to justify it by refusing developer requests, and say, "no to points 7 thru 12". Otherwise if he agreed to it all, whats his job purpose? Any good developer can self micro manage.

We know sun can't afford 15 machines and an auto compile script, even compilers with different system outputs.

Seriously, I think java has those other venders under partner relationships so they 'tweak' it for those systems if they feel like it, but still, they should get of their ass, we aren't asking for 12 dvds per platform sent out to 50000000 homes like AOL.

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:Same old same old

[Mr. Piddle]

Sun are not experts in *BSD.

Well, they used to be...back in 1982. Solaris and the *BSDs are cousins, so they best not be courtin' now!

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.

Re:Same old same old

[JohnnyCannuk]

True enough, but that hardly qualifies them as experts in OpenBSD, NetBSD, FreeBSD, ${any other BSD I don't know about}BSD.

And if that's the case, it shouldn't be too hard fro some smarty-pants *BSD guy to sign the SCSL, get he 1.5 beta source and make a *BSD port from that... or use the Solaris one.

What?

You mean *BSD and Solaris are not binary compatible? You mean they have drifted that far apart? You mean Sun may not actually be experts in any variation of *BSD except Solaris?

Who'd have though...

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!

Re:Good News for SwingSet

[GOD_ALMIGHTY]

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

My immediate reaction is... DO NOT DO THIS!!!!

I've worked on a number of distributed N-tier apps. One of the problems I've seen is having people caught up in an object oriented design that surrounds their application's business data structures. This usually comes about in the "thin" client-side GUI which has had every widget inherit it's network or database access from some other abstract class or interface.

The problem with this approach is that each widget starts doing it's own network communication and what not. While most client-server apps that hit a database will use a common connection pool for database connections, developers seem to forget to apply this inversion of control pattern to network using widgets.

So what's the problem with this? One project I worked on needed to add SSL to the network traffic for security requirements (HIPA). This was nearly impossible without massive rewriting because the expensive part of SSL is the session creation. With each widget trying to create it's own SSL session, the app's performance quickly became unusable, especially on slightly old hardware.

Another project was using SOAP and making a ton of unnecessary or redundent requests because the widgets were "smart". SOAP is freaking expensive in memory and CPU to serialize and deserialize. Not to mention the amount of traffic those verbose ass SOAP packets generated.

If you want to make your widgets aware of shared resources, apply an Inversion of Control pattern and build a framework that the components use to access these resources. Don't "inherit" these features into your widgets. It looks nice in an object design, but reality will kill you.

If I'm completely off base with my assumption of what you mean, sorry.... otherwise, take a look at how your widgets will be used and think about the hidden costs of what seem like elegant designs.

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

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

[Anonymous Coward]

WTF?

• C++ templates work at the source level, Java Generics don't (they add casts to increase type safety)
• Java Generics allow constraints on the types they
  are given, something C++ does not (at least not explicitely).

murphee

MOD PARENT UP

[Progman3K]

I hate it when someone makes a valid point and gets modded down because it's controversial.

Come to the realization friends; Java IS slow.

Personally, I LOVE Java as a pedagogical tool to aid in teaching computer science, and I had the same love for Logo, but obviously both of these languages have at least one thing in common; they are hampered by the fact that they are slow.

Re:MOD PARENT UP

[deanj]

Slow for what?

The applications I've written for real-time audio decoding work great; I've done some non-trivial 2D graphics work and that runs great too. I've done work on large scale Java projects, and speed has never been an issue.

Sure, you can come up with some BS "it can't do this fast", but in most cases, it does just fine.

Comparing Java to Logo...well, that's just braindead. I was going to say that you haven't been keeping up with Java, but it's giving too much credit... it doesn't sound like you're aware of what Java is doing at all.

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.

Re:MOD PARENT UP

[Progman3K]

I'm sure the key parts of your real-time algorithms are not coded in Java.

For instance, the codecs you're using.

Of course, it's much easier to call someone braindead than being right, thanks.

Re:MOD PARENT UP

[smallpaul]

Those benchmarks were debunked right here on Slashdot.

Re:MOD PARENT UP

[pHDNgell]

Come to the realization friends; Java IS slow.

Slow is a worthlessly objective word. If it's fast enough for what you do with it, it's not slow.

Personally, I LOVE Java as a pedagogical tool to aid in teaching computer science

This is a place I don't believe java fits. 1.5 is adding some nice stuff, but it's not something I would consider a well-designed language. It's good enough for corporate use, but there are a lot of things that are just stupid in java.

Scheme is good for teaching (and general use). Haskell is also excellent. OCaml teaches some pretty good stuff as well (not to mention being incredibly fast at execution time). Eiffel is an excellent teacher.

Java is sort of the English of programming languages. It's hard to learn, not very elegant, you see examples of it everywhere that sicken you with their brokenness, but everyone seems to want to use it for everything.

Structs

[Anonymous Coward]

All I want is structs. Passing by value. Right now I'm working on a funky text editor that needs a little extra info per character, and without structs I have to twiddle bits in a 64-bit integer. Don't really want each character to be a reference to an object, I don't think the performance would too great. Good thing I can cram everything in 64 bits, but I'd rather have a bit more space and reference fields by name.

Doesn't seem like so much to ask.

Re:Structs

[WWE-TicK]

Look up Flyweight design pattern.

Re:Structs

[Anonymous Coward]

IIRC, Flyweight works if you have a bunch of objects that share the same data, but that's not always the case. Besides, I don't want it dereferencing a pointer for every character.

Another example...for a while I was working on simulations of peer-to-peer protocols. I set up sims of a hundred thousand or so files, to see if some searching algorithms I came up with would work. So that's 100K items, each with its own id, location, etc. In this case I could just use a two-dimensional array I suppose, but it sure would be nice to have some freakin structs.

Reality check

[shlomo]

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.
Java has gotten a lot better, and the learning curve is shorter, I think generating machine code from byte code would make it as fast as c/cpp , something like what gcc/java is doing.

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:Reality check

[abigor]

Just out of pure interest, what do you use for your "low-volume" stuff?

Re:Reality check

[ShavenYak]

I bet Java could even handle My Yahoo and Yahoo Mail, if you guys would cut the number of advertisements down to just a couple dozen per page!

I used to love Yahoo's stuff, but the first time I went to check the weather and a Ford Explorer drove across my screen, it was over.

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:Reality check

[SharpD0g]

Did the Ford Explorer tip over. Supposedly 30 - 40 percent of them will. ;-)

Re:Reality check

[sdcharle]

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?!?

Sometimes people with 'high performance needs' turn out to be doing incredibly inefficient things in the code itself. It's like, yes, an Olympic sprinter could move a bag of M&M's upstairs faster than me if we took one M&M each time, but if I just take the whole bag, I'll probably win.

Re:Reality check

[Deadbolt]

Um, I work for Disney Internet Group. Perhaps you've heard of go.com and friends, including disney.com, abcnews.com, espn.com, movies.com, and ToonTown.

Everything -- *EVERYTHING* -- web-related runs on our custom servlet engine/web template languages. (They are open source; you can get them at teatrove.sf.net. All 100% Java and not substantially changed since 1999. Would you like to guess at the number of terabytes we serve daily, or the number of millions of unique page views?

Here in the real world, on the front lines, Java has been more than adequate for the needs of one of, if not *the*, biggest and most popular web rings in the world. I'm not saying it's the only solution or that it's perfect, but Java has proven itself more than capable of handling some seriously heavy-duty shit.

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:Reality check

[aled]

I guess they would have to close the doors by shortage of sponsors, but doubtless that would be very fast!

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.

Re:Where the value is

[Jack9]

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.

Your link does not demonstrate this speed increase, but is the previously /. linked (questionable) language runtime speed comparison. Where is the study showing it's faster?

Re:Where the value is

[lonb]

Except for trig functions it tied neck and neck with the winner, Vis C++. But the author admits that the benchmark may be errored there... Anyway here is an interesting excerpt:

It would be foolish to offer blanket recommendations about which languages to use in which situations, but it seems clear that performance is no longer a compelling reason to choose C over Java (or perhaps even over Visual J#, Visual C#, or Visual Basic)--especially given the extreme advantages in readability, maintainability, and speed of development that those languages have over C. Even if C did still enjoy its traditional performance advantage, there are very few cases (I'm hard pressed to come up with a single example from my work) where performance should be the sole criterion when picking a programming language.

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.

Re:So, competition is good, huh?

[Anonymous Coward]

Noticed that many improvements were to improve type-safety ?

Ever wondered why people seem to really want that and therefore dismiss python as a programming language -- but might like it as a scripting language ?

Some Insite please

[TheRealMindChild]

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.

Re:Some Insite please

[Anonymous Coward]

That's *insight* you pathetic bugger.

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.

Re:Some Insite please

[blamanj]

Shared memory doesn't affect write once run anywhere. If a platform doesn't implement it, then running multiple JVMs will simply require more memory. The behavior of the bytecodes is not changed in any way.

support for AMD64 Linux and Windows

[jarich]

Finally! I can use a 64 bit version of Java on the Opterons and see how the speed on the large (~6 to 8 gig datasets) improves/decreases

Re:support for AMD64 Linux and Windows

[Anonymous Coward]

Actually, I wasn't wondering about the data structure internals, but memory IO and disk IO...

the apps I am working with end up being memory bound or disk bound... I am curious to see whether or not the 64 bit versions of Java (Windows or Linux) takes better advantadge of the bandwidth the Opteron platform offers

Screen Shot

[Yoda2]

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

Re:Screen Shot

[earache]

Nice to see Swing still looks like shit.

Re:Screen Shot

[Anonymous Coward]

Nice to see Swing still looks like shit.

Ah, but it looks equally like shit everywhere. All thanks to Sun's decision to punt when it came to the problem of porting toolkits across platforms.

Simple input

[Lobo_Louie]

Curious if 1.5 has a simple method of keyboard entry. As a 1st year Java student, I find it odd that System output is done with a simple command, but System.in is a hoop jumping affair. Of course, I may not know what the hell I'm talking about...

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:Simple input

[cheekyboy]

Have they added printf yet?

or #define ? :)

Re:Simple input

[Tagren]

Yes :)
At this page search for 'printf'
http://java.sun.com/developer/technicalArticles/re leases/j2se15/
---

Re:Simple input

[jwriney]

And this is exactly why I am so opposed to using Java as a first programming language. There's too many things you have to tell a newcomer to ignore when they're first starting out. Whatever happened to INPUT A$ ?????

I adore Java and develop in it daily, but it's absolutely the wrong thing to start a first-year on.

--riney

Re:Simple input

[trout_fish]

One of the nice things about OO is that you can hide the complexity from new comers. e.g.:

SimpleInputClass i = new SimpleInputClass();<br>
String a = i.input();

This hides all the complexity in a simple class provided by the teacher. Once they undertand the more complex stuff you can open up SimpleInputClassand show how it works - or even get them to write their own.

Re:Simple input

[DrEasy]

JDK 1.4 introduced a one-liner for keyboard input, but I just can't remember what it was (kinda defeats the purpose I guess).

Also, why not use Dialog boxes instead? They're one-liners alright:

JOptionPane.showInputDialog(...)

Should be good enough for a 1st year Java class, and it looks more impressive than a basic prompt!

Re:Simple input

[Anonymous Coward]

I am waiting for scanf

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:Are you talking about THAT Microsoft?!?

[Anonymous Coward]

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.

It's been worse than that for many companies, including the guys who made Stacker. In their case, THEY sued MS and *won*, but still got squashed. (Remember the ineffective DOS 6.1 "recall"? That was because of the conversion from doublespace (stacker code) -> drivespace (code bought from their competitor with less features)... but it never actually helped Stacker any.)

Re:Are you talking about THAT Microsoft?!?

[smallpaul]

Name a company that Microsoft has sued for patent enfringement.

Re:Are you talking about THAT Microsoft?!?

[William Tanksley]

I worked for Stac back when that lawsuit started.

They did NOT sue/squash us. We sue/squashed them; and in return, they embrace/extend/extinguished us -- but what they didn't realise and we did was that the market for disk compression was OVER. They took it from us by buying and releasing one of our competitor's products which didn't infringe on our patents, but they got NOTHING in return, not even the satisfaction of causing our demise.

I left the company with the Hifn spinoff, so I missed all the fun as Stac stopped producing real product and went into an orgy of spending Microsoft's money on research products; having lost their original direction (compression) and all motivation (having to earn a living), their days were numbered (but that wasn't Microsoft's fault!).

-Billy

Re:Are you talking about THAT Microsoft?!?

[Malcontent]

I don't know about patents but Ms has sued lots of people. They have sued lindows and lots of other people for using names that might sound like windows if you were healf deaf. Hell they even sued a Mac columnist for printing an IE logo (http://www.macopinion.com/columns/tangible/02/04/ 01/).

Ms has also sued bandai for "using their intellectual property" (http://ifaq.wap.org/computers/mstomagotchi.html).

Ms has sued people for gathering up hotmail addresses.

Ms has sued tons of people. What makes you think they won't ever sue for patent infringement. If they feel no shame in suing a high school student then they'll sue for patent infringement.

Why the compiler options -d32 -d64

[expro]

Shouldn't 64-bit support come naturally by the VM extending the pointers? Does this mean class files compiled for 32 or 64 will be sub-optimal or incompatible with the other environment?

Re:Why the compiler options -d32 -d64

[Anonymous Coward]

It's a type, those options only apply to the runtime java command, allowing you to have >32bit heaps.

"syntactic sugar for loops"?

[Gudlyf]

Maybe it's just me, but a vision of Toucan Sam came to mind when I saw that phrase.

Great, now I'm hungry again....not.

Re:"syntactic sugar for loops"?

[Anonymous Coward]

Not to mention that syntactic sugar causes cancer of the semicolon.

AC

No need to wait... Bytecode is backward compatible

[Opiuman]

As long as you compile with JDK 1.5, the new language features are available to you now -- except the generics implementation of the collections classes and even that is solvable. This is because the bytecode generated by the JDK 1.5 compiler is 100% compatible with JDK 1.4.

Speed?

[beforewisdom]

I have seen IBM's jdk on linux open up less resources.

I have recently switched one of my company's JSP sites to jrocket from BEA because we noticed a visible speed improvement using it over SUN's jvm

I would like to use SUN's JVM.

Does anyone know for sure if 1.5 has any significant performance improvements?

Steve

MOD PARENT UP?

[wurp]

I've played realtime 3d games on java, and it doesn't look slow to me. Oh, wait, I _write_ realtime 3d games on java, and it doesn't look slow to me.

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?

Array access is fast

[Anonymous Coward]

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.

Re:Array access is fast

[Surt]

That's the trivial case of hoisting. Unfortunately, more complicated array access patterns break this, and you don't get the checks disabled. You can easily check this by benchmarking.

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.

Re:About polymorphidm snd subtyping

[hey!]

I think you're missing the point.

I absolutely agree the compiler should not automatically downcast a float to an int, and by extension it should not allow a Array<float> where an Array<int> is expected. This should be something the programmer explicitly request and takes responsibility for. However, it should upcast when an Array<float> is provided as an anctual parameter where a generic Array is specified in formal parameters.

In other words an Array<X> <: Array<*> (that is to say an array of X is an array of something). As your code snippet pretty much demonstrateds, if X <: Y, then it is not the cast that T<Y> <: T<X>. An interesting question is whether T<X> <: T<Y>. I don't feel as strongly about this though.

What I am saying is that the language should allow me to treat generics generically. Granted from a design standpoint, I should probably encapsulate generic operations within the template class, but that may not always be an option. This is the difference between language design in theory and language design in practice. Languages should enable and encourage good practice, but they should not enforce it (e.g. checked exceptions). Getting hung up on theoretical principles means that you encourage programmers to circumvent your protections in practice. You end up with language features that hobble programmers, like some of the extreme type checking of early Pascal implementations.

Re:About polymorphidm snd subtyping

[fab13n]

What you call Array<*> is actually \forall x. Array<x> (or A => Array A in Haskell, or <A> Array<A> in Java).

Example: a zip method, belonging to Array<T> and taking any other Array (of anything) as parameter and gives back a Array of pairs extracted from these tables:

class Pair<A,B> { public A car; public B cdr; }

class Array<T> {
public <U> Array<Pair<T,U>> zip(Array<U> that) {
// foreach i: result[i] = new Pair(this[i], that[i]);
}

Re:About polymorphidm snd subtyping

[tbfmicke]

The principle is the same as it has been for arrays since the beginning. The differnce is that the check for array handling is in runtime and not when compiling.

For example the code:

private static void func1(Object[] objs)
{
Object o1 = objs[0];
objs[1] = new Date();
}

private static void func2(String[] strings)
{
func1(strings);
}

will compile, but gives an exception when run.

I think I remember that the generics as it stands now (apart from array generics :-) is only done during compilation, so the compiler cannot depend on the runtime to do the same checkings as it does for arrays. So they are left with the choice to disallow the construct at compile time.

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:I like most of it...

[Greyfox]

I was under the impression it was only for primative types. It doesn't look like anything on the level of what C++ attempts to do. It should be pretty straightforward to create a special case for compiling that says when you see someone assigning an Integer to an int, autmatically call the Integer's .value() method. I expect it would break if you go much beyond that.

If your programmers are doing anything with introspection or serialized classes, autoboxing is going to be the least of your worries anyway...

That's because most java programmers are idiots

[Anonymous Coward]

If the only tool you have is a straightjacket, everyone else looks insane.

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

[danharan]

Scanning the docs, I don't see anywhere where it says that's a problem.

Wouldn't it be possible to java -source 1.5 -target 1.4?

Genericity is long time debate about Java !

[Anonymous Coward]

Java conceptors did not want a C++-ish feature, ie 'preprocessing inside', they want somethin that will not break the object point de vue of Java.

About the other functionalities,
enum was discussed long time ago, but they did not think it worth adding it. But according to experience, it appears that having some defacto feature is better that depending on people to understand an advanced pattern pro&con.

The foreach loop, was long time requirement, since the collection framework appeared, but unfortunatly they did not had time to build this in befire.

About the boxing and anotation, those are just MS ideas improved ! Who gonna blame Java for supporting interresting features ? No MS that just CC the Java spec after leaving the Java playgound in late 1998 ;-)

Anyway, the new functionalities and improvement are so dense that IMHO, this is the best release ever brought out of Java !

FYI, .net almost 4 years old now (if you include earlies and beta ey!).

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

[ajagci]

Sun wasn't working on the language because they were busy building up the libraries--arguably a better choice.

Oh, come on, that's pretty ridiculous. Sun is a 16B company with 36000 employees. If they can't simultaneously add a few minor backwards compatible extensions to the Java-to-byte-code-compiler and develop a library for enterprise applications, they really shouldn't be writing software at all.

Instead of generics and autoboxing, we have J2EE, which (in the right parts) is probably a larger productivity gain.

What you are basically saying is that Sun Java has become a specialty tool for people who write a certain class of enterprise applications. Nice. Fine. We can agree on that.

Now, if the implementation of features important for everybody is held up by Sun's involvement in J2EE, what does that say about Java for all the other applications? It says that Sun has no commitment to them and that Java will remain cumbersome and poorly supported for anybody who doesn't write enterprise applications. And we all should remember that next time Sun keeps trying to sell Java for desktop applications or education.

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:not enough

[jjohnson]

Okay, I didn't realize that you have such a hate-on for Java, so I'm not sure I should even engage you in this, but: where was the demand for autoboxing and generics before C# (quite publically) had it? I certainly don't recall hearing about them except on language lawyer mailing lists--meaning that the market wasn't howling for them. How would implementing those things create an industry that would keep Java momentum up? For all of the mixed blessing that J2EE is, you must admit that, it having been the focus of Java development for the last few years, has kept Java moving at the front of the market, which is what keeps it alive long enough to evolve as a language.

As for 16B/36K employees, there's prioritizing limited resources, and I think it's pretty obvious where those priorities went. Considering how successful Java's been so far, I don't think you can fault their market choices.

Re:not enough

[Anonymous Coward]

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.

cock*you[1] // fuck you in the ass

Re:not enough

[greg_barton]

My opinion of operator overloading is that it is absolutely bad.

"Then I guess you've never " +
"done this and found it " +
"rather convenient?"

Re:not enough

[Featureless]

This is a deceptive non-answer. A sugary Java shortcut is not operator overloading, and dare I say... "you" + "know" + "it."

Re:not enough

[bunratty]

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.

Operator overloading does have functional value. When combined with templates, it allows you to write code that can work on built-in types such as doubles and also user-defined types. I have used this technique to write Gaussian elimination code in C++ that solves matrices of doubles and also matrices of integers mod n. Without overator overloading, I'd have to write much more code, either developing a type hierarchy for the built-in types and my user-defined types, or repeating the code for built-in types and replacing + with add calls.

And which of these two lines of code would you rather maintain?
a = divide(add(b, sqrt(subtract(multiply(4, multiply(a, c)), b)), times(2, c))
a = (b + sqrt(4 * a * c - b)) / (2 * c)

I agree that operator overloading can cause an unmaintainable mess when abused but when properly used it can make code much more maintainable.

Re:not enough

[NoOneInParticular]

I for one was crying for generics in Java. I need to program quite a bit in java, and got blisters on my fingers by the amount of code you need to write for even the simplest of things. Currently I still prefer C++ over java (with 8+ years experience in C++, I finally managed to be productive in that language), but this might finally change now java finally delivers some of the productive features most languages had since the early nineties.

Re:not enough

[Kupek]

Either a troll or very ignorant. I hope it's a troll.

Re:not enough

[Featureless]

I don't think taking clever advantage of the order of operations is functional value. This is the closest you can get, but I would say it is still only saving typing.

You are arguing that because you are also reorganizing things on the line, your code is easier to understand.

But you would never write case 1:

a = divide(add(b, sqrt(subtract(multiply(4, multiply(a, c)), b)), times(2, c))

You would write case 2:

a = (b + sqrt(4 * a * c - b)) / (2 * c)

Unless you really wanted case 3:

a = mySpecialDivide(mySpecialAdd(b, mySpecialSqrt(mySpecialSubtract(mySpecialMultiply( 4, mySpecialMultiply(a, c)), b)), mySpecialTimes(2, c))

And yes, I would rather maintain case 3! You see, it is very difficult not to abuse operator overloading. The issue is how quickly and how well you will understand code by looking at it. And my experience has been unambiguously that, yes, it saves typing and is "easier" for the person that wrote it (in theory), and it is a raving nightmare for everyone else... even when it is used "properly."

The language should define the operators. You should define the methods. Saving keystrokes makes so much heartache... and whatever you think you gain by expressing things more closely to algebra you lose when something in one of those operators goes wrong, and it takes you (or more importantly, someone else) longer to figure out what.

Re:not enough

[Kupek]

Not only does operator overloading have functional value, it allows functional programming. [rimshot]

That is, in C++, overloading operator () allows you to define function objects. Function objects allow you to simulate functions as a first-class entity, allowing functional style programming in C++. Check out the Functional C++ Library, FC++, it's cool stuff.

Re:not enough

[greg_barton]

(you ^ must) % chill

Re:not enough

[ajagci]

where was the demand for autoboxing and generics before C# (quite publically) had it? I certainly don't recall hearing about them except on language lawyer mailing lists

I see. So, you think it just doesn't matter what the language experts say.

--meaning that the market wasn't howling for them.

And that surprises you? Do you think that the market is composed of language experts who know exactly what features they need and want? Well, gee, then VisualBasic must be a brilliant language design because the market kept buying it, too. Why, then, did we even need Java?

How would implementing those things create an industry that would keep Java momentum up?

I dunno. Why would I care? Microsoft Windows and VisualBasic had a lot of "momentum" and was enormously successful in the market. Why didn't you jump on that bandwagon yourself if you care so much about "momentum"?

"Momentum" is neutral. It can be used to move forward a technically good platform or a technically bad platform. When a language like Java loses its way, as I think it has, then "momentum" behind it amounts to "stagnation".

For all of the mixed blessing that J2EE is, you must admit that, it having been the focus of Java development for the last few years, has kept Java moving at the front of the market, which is what keeps it alive long enough to evolve as a language.

I disagree. I think J2EE has undermined what originally was at least a sensible goal. Java's distinguishing design goals are 100% binary cross-platform compatibility and the ability to sandbox untrusted code. But those goals simply are not key features for server-side applications: recompiling a server side application for a different platform is no big deal, and server side application frameworks generally do not run untrusted code.

J2EE may have been a smart business move for Sun, but Java is technically the wrong platform to support it. And the stuff Sun originally promised and that propelled Java to its initial success, web delivery of applications and thin clients, basically has withered on the vine, not because it wouldn't be tremendously useful, but because Sun couldn't figure out how to make money with it.

Okay, I didn't realize that you have such a hate-on for Java,

Typical: pretend that criticism is irrational hatred. Unfortunately, most of the response from Java advocates these days seems to reduce to such emotional button-pushing. Sad, but there is no technology or even strategy in the Java community anymore--just a "milk it for all its worth" and "anti-Microsoft is automatically good for everybody else" kind of attitude.

Re:not enough

[deblau]

Not all implementations depend on Sun. Check out Classpath. Granted, there's a lot of work to be done on it, and it's nowhere near production-ready, but my hat's off to them.

Re:not enough

[Anonymous Coward]

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

No, the compiler provides type-safety, not the runtime.

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

It had to be done before aswell (manually). I agree that now boxing happens behind the scenes, which may lead to unexpected slow-downs.

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

That's not a feature of the Java environment as such. Also, we used it a lot here, and didn't find it that slow.

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

Not sure what you mean with value classes. Do you mean type-variables (which is what you get in part from generics), or "virtual" parameter passing (methods that can be overloaded with different subtypes of the same supertype)?

Operator overloading is evil. Period.
For examples try to overload operator+ and operator* and then write something like:
A+B*C. What that really means is A+(B*C) because * takes precendence over + (which you cannot change). There are many more examples... It is evil and useless.

Re:not enough

[pfafrich]

Java still lacks value classes and operator overloading, making it a poor choice for applications involving numerics or graphics. I don't think this is a great loss, for serious numeric or graphic code speed is the ultimate goal. A bit of verbose language is a small price to pay. I haven't played too much with generics in C++, but it did seem to involve a lot of excess object creation which isn't too good for speed.

Re:not enough

[Anonymous Coward]

Not only were they working on J2EE, but personal Java and other such APIs for mobile device. I think the bulk of people developing java apps are working in either one or the other of these two areas

Re:not enough

[nvrrobx]

I agree with you on operator overloading 100%.

Since Java doesn't support it, I can expect to be able to do this:

if(foo.equals("blah")) {
}

to work, but in C++, for example:

if(foo == "blah") {
}

Riiiight, doesn't work. If someone overloads == properly, it might work.

Operator overloading is the equivalent of giving someone three feet of rope and waiting for them to hang themselves.

Re:not enough

[owlstead]

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.

And besides that, it would make parsing your code a lot slower. No more looking for '+' sign and knowing exactly that you want to add a number to another (or a String, the one Java (compile time) exception to the rule.

And that would definately screw up Eclipse, something that I do not want to happen. So this is a practical performance reason as well. From a theoretical stand I would be for operator overloading anytime. Problem is that in a practical world it is very much abused, making for unreadable code.

Re:not enough

[aled]

Don't wait for tomorrow what you can get done today with templates...

Re:not enough

[a1291762]

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.

My favorite peeve about Java was it's "special" treatment of java.lang.String. Argue all you want about overloaded operators being bad but + meaning "contatenate these two immutable objects into a new String object" is clearly an example of an overloaded operator.

Actually, without the special treatment of String, lots of code would break badly. String bar = "bar"; System.out.println("foo = " + bar); wouldn't work.

Link

Re:not enough

[jjohnson]

You know, I've been dealing with a lot of Lisp lately, which means wading through a lot of "Lisp is the perfect programming language" stuff, and I see their point--I still have the occasional moment of grokking something subtle and elegant that feels so damn good. From a certain perspective, Lisp really is the perfect programming language. Certainly, just about any language feature I've ever seen in C++, Java, C#, etc. already exists in Lisp in some form, and has for just about forever.

And yet Lisp is virtually nowhere, and the Lisp guys can't seem to figure it out. They've got the perfect programming language: Why isn't everyone using it all the time? The answer is that it's been an academic language and a moving target for so long that nobody's trusted it enough to settle on it for a long-lived platform. The compsci side of it prevailed too heavily over the marketing side, and so now, as an IT guy at a corporation with a homegrown ERP, I can't use Lisp. Even if I sell it on its technical merits, the business concerns sink us over time--the difficulty staffing, incompatibility with our parent company, greater difficulties interfacing with outside packages, etc., etc., etc.

So what I demand now in any technology into which I invest serious time is commercial viability, and while Visual Basic may be a horseshit language, you can have a satisfying career as a VB programmer. You can be fairly certain that time spent learning C# in detail won't hurt you in the long run by pigeonholing your skillset. You can become a Java guru and be as confident as anyone of gainful employment. And if getting that means writing (String) enum.nextElement();, then that's a reasonable sacrifice to make, and confusing a pragmatic attitude with a lack of strategic vision is simply insulting.

Re:not enough

[lsdino]

I haven't played too much with generics in C++, but it did seem to involve a lot of excess object creation which isn't too good for speed.

C++ does involve a lot of object creation. But good C++ doesn't involve a lot of object creation in the heap, it's on the stack. It's all about Resource Acquisition is Initialization. That's where you have a class, you declare it locally on the stack, and when you exit your method the class's destructor is ran. Of course, if your class is small enough all of this gets inlined. It's really a pretty elegant solution. A lot of people (probably converting C++ programmers) seem to be unhappy that you can't do the same thing in Java or .NET (the Java & .NET way to solve the problem is try/finally blocks all over the place).

Anything that you'd store in the heap would be long living objects but the major of your object creation will be on the stack. So it's really not as bad as it looks.

Re:not enough

[Anonymous Coward]

operator overloading is obviously useful in cases where there is a repetition involving the composition of many functions. Classic examples often cite linear algebra computations--which with operator overloading can become much closer to the notation understood and communicated in math for hundreds of years.

You might consider this an exceptional case, and not valuable in the typical one based on your experience--but to maintain that there simply is no value whatsoever, in no circumstances as you do now, is simply short-sighted.

Re:not enough

[Featureless]

I disagree. There is an easily understandable argument that our ability to write and maintain trouble-free code depends on our ability to easily understand our language. Every additional complexity, even if it results in a minor or moderate additional amount of thinking, is drawing on a "finite" reserve of "bandwidth" that the reader has when interpreting written work, and increasing the likelihood for error or misunderstanding.

The ability to represent more sophisticated mathematical calculations more tersely and ultimately in forms more familiar to mathematicians comes at a cost. Prolog, for instance, is highly expressive - but prolog code will quickly escape the author, and her successors', grasp. Your implicit argument for code which is more like conventional mathematical notation (used for "hundreds of years") sounds like a plea for "natural language programming." (English has also been used for X's of years.)

Yes, more complex operators _may be_ more familiar to (some!) humans. That does not make them part of a better programming practice.

I could see a case for a math-oriented language or toolset with more complex operators and datatypes. (To be clear, since people seem to be confused about this, "operator overloading" is not the same as a langauge with multi-functional operators.) But how appropriate is that for a general purpose language? Reasonable people can disagree. But open-ended operator overloading is bad in every case. If your goal is to reach correctness, and stay there, you want to minimize the complexity of your operators in any case. If you want your work to be safe and useful, people need to develop new operator behaviors as if they were creating a new langauge, and encounter them in the field as if in the context of learning a new language. With much less gravity than that, the pain starts.

I believe it is short-sighted to ignore the obvious human factors in the equation, so to speak. There is a trade-off in "walking farther towards the language" to express your mathematical functions, but in the real-world cases I have seen (where one has deep math in non-standard data types) the effort to express things with method calls was not nearly as onerous in fact as it was in principle, and you immediately gain maintainability and readability.

Compact, highly expressive languages with lots of complex operators may be useful for mathematical experimentation, but we are talking about writing code, not using Mathematica. You need to know why it's slow. Where it's leaking memory. Why it crashes on Joe's computer and not Jim's. And you need to do this on a deadline. There may even be lives staked on the correctness of your code. And so I would say it is beyond short sighted to trade the clarity, simplicity, predictability and transparency of a language for keystrokes and clever expressions.

Re:not enough

[Anonymous Coward]

And which of these two lines of code would you rather maintain?
a = divide(add(b, sqrt(subtract(multiply(4, multiply(a, c)), b)), times(2, c))
a = (b + sqrt(4 * a * c - b)) / (2 * c)

That depends on which is correct, since the two are not equivalent. Maybe you need to go review operator precedence before advocating operator overloading.

Re:not enough

[Anonymous Coward]

Hah. I love how hypocritical some trolls can be.

Re:not enough

[Anonymous Coward]

It looks super easy to read and debug. Suuuure.

Ten bucks says this clever idea never makes it out of the lab, not least for this reason alone.

Re:not enough

[Kupek]

No, not a troll. When someone says something like "my opinion of operator overloading is that it is absolutely bad," I hope they're trolling, because it's very ignorant to say.

Re:not enough

[Anonymous Coward]

Asssuming you're right, which you're not... you, unlike poster, don't say why - making you an... wait for it... troll.

Re:not enough

[Kupek]

No, that just makes me lazy.

Re:not enough

[Anonymous Coward]

Heh. If you were polite, it would have just been lazy.

Java is NOT portable in my gentoo with 2.6.2

[Anonymous Coward]

>Java has binary portability

Java is NOT portable in my gentoo running kernel-2.6.2

I want the JVM-1.5 sources !!!.

open4free

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

[brett_sinclair]

Wouldn't it be possible to java -source 1.5 -target 1.4?

No (assuming you mean javac). javac reports "javac: source release 1.5 requires target release 1.5" if you try that.

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

[Anonymous Coward]

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.

Having the entire technology infrastructure of your company depend on one (evil monopolistic) vendor is a small price?

1. A good IDE.

Nice to have, but you don't need it if you can code. A good text editor is all a REAL programmer needs.

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.

What on earth could you have to do with Apache that would takes hours or days? Unless, as I'm beginning to suspect, you're an idiot who is in the IT area because it pays well, not because you are actually competent or anything.

Re:Nice First Step, But....

[(void*)cheerio]

I've always been a fan of the "X IDE": A couple of xterms with Vim (or emacs if you must ;) ) a web browser, man pages, and shell scripts...

Of course, this isn't as cool as MS's IDEs. But you can take it almost anywhere and you can make it conform to your own tastes and habbits.

And of course, the text editor is king when it comes to IDEs...actually, the compiler is the "king", the text editor is the "queen"

Re:Nice First Step, But....

[cyfer2000]

it really need days to get Apache tell you the root password.

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

[Anonymous Coward]

Sounds great for you. And I am also guessing the stuff your building is really a simple display of a single database table or at most a view of a few tables joined. For this kind of stuff, it's great if you don't want to think about performance or anything other than getting the job done. This is also exactly the job that will get outsourced.

If you need anything moderatly complex like say, push database updates to a smart cache in your webserver, doing it in .NET will require writing lots of custom code. Whereas using Resin, it's already built in and is easy to use. People should get over the whole technology thing and do what makes the most sense. I develop with .NET as my primary job and I have to say, we've practically rewritten and over-rided the default webservices mechanisms. This isn't because we like to re-invent the wheel. It's because we're building apps that are moderately complex and the basic stuff doesn't cut it. If I had to build the same thing with a servlet container, I can honestly say, it would have been done 5 months ago. We still have many months left in our dev cycle to replace more stock stuff, so that we can get the functionality we need.

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:Nice First Step, But....

[Anonymous Coward]

you trust IIS.

wow

what company do you work for so i can avoid doing business with them because if they base their operations on that kind of system, i doubt their final product is of decent quality.

Re:Nice First Step, But....

[aftermath09]

It's not clear to me why it takes you hours to do anything in tomcat. afaik, unzip it and execute run.sh or run.bat depending on your o/s.

Re:Nice First Step, But....

[Anonymous Coward]

If your "productivity" relies on a drag-drop-wizard-code-generating IDE ASP.Nyet is definitely for you. Programmers with a modicum of skill can make do with Java & vi.

WOW.

[flacco]

i ran the SwingSet2 demo using this JVM - started in about 2.5 seconds.

a Swing app in 2.5 secs? it takes about 2 secs to start gedit, a freakin' text editor.

When is the final release supposed to ship?

[Anonymous Coward]

I may have missed it, but I couldn't spot a final release date. Anyone know?

I'd like to use 1.5, but I don't want to ship a commercial product based on a beta devkit.

No, feat. are not only on the lang. ! The truth :

[Anonymous Coward]

But also on the platform.

Do not forget that Java (the name) is used for 2 things : The Java platform, and the Java language.

By default, you application for the Java platform using Java language itself (like you defacto develop in C# for MS.net), but there are lots of differents language that can compile to java's bytecode as well.

IMHO, the strength of Java is the platform and not the language. Without the platform concept, it would never have been different from his ancestors C++/SmallTalk/ObjectiveC ! There is the big difference with .net.

MS.net only run on some MS windows OS (No Mono is not&will not be a complete and real .net impl). Whereas Java do run on most OSes !

This is no b*illsh*it but just truth.

If you want to contribute to Java libre world then i invite you to join the FSFGNU Classpath project, as they are building a full GPL implementation of the Java platform!

This can exist because all Java spec (JSR+TCK) are available to the public (including Reference Implementation) so even if the RI is not GPL, you can just create a new implementation that apply whatever license you want. That's how Java managed to balance freedom & compatibility :)

Linux+Java is the baregain for enterprise solution, and with Java 1.5 and Linux 2.6 functionality & TCO are there ! Here we got the reference platform for developement of the next decade.

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!

Speaking of which ... 1.5 beta on OS X?

[melquiades]

Apple (finally!) has a 1.4.2 out, and it's superb. For a brief moment, OS X is up to date on Java.

Does anybody know anything about Apple's timeline on 1.5? Will we see a beta? Will we at least see a concurrent release? Apple has been notoriously out of date in the past, but they swore that they would improve; now's the time for them to prove that they are.

Re:Speaking of which ... 1.5 beta on OS X?

[LionMage]

Well, Apple's focus is on stability and user experience, so I think they'll probably trail the Windows world by a month or two. Fortunately, most of the JDK 1.5 improvements are under-the-hood, and affect the compiler more than the VM. Of the VM-side improvements in JDK 1.5, it looks like a lot of them were already implemented on the Mac side in some form (such as this memory sharing technology), so it might take a lot less work for Apple to get up to speed with 1.5. Here's hoping!

Re:Speaking of which ... 1.5 beta on OS X?

[melquiades]

I definitely agree with Apple's focus on stability and user experience -- it really shows in the finished product. Still, I sure wouldn't mind a timely beta without the polish. And, as you point out, it should easier for 1.5 than it was for 1.4!

I'm just a little too eager to be using generics on OS X. I feel like I'll have reached some sort of geek nirvana.

Re:Speaking of which ... 1.5 beta on OS X?

[bill_mcgonigle]

Does anybody know anything about Apple's timeline on 1.5? Will we see a beta?

Sure, at WWDC in July. I predict that with no data, but lots of history.

Will we at least see a concurrent release?

No, never happen. Apple always has additional work to do after Sun cuts the final version, so it can't happen simulataneously. Now, the size of Apple's Java team probably has something to do with how long that delay is.

Apple has been notoriously out of date in the past, but they swore that they would improve; now's the time for them to prove that they are.

They've been saying that for at least 5 years. They've backed further and further away from Java during that time (not shipping Java desk accessories, languishing java-objc-bridge, etc.).

Interpreted Java

[NumbThumb]

AS far as i know, BeanShell is able to execute (read: interpret) *any* java code. That doen't help with the memory-footprint, but it allows dynamically generated java to be run without having to invoke a compiler first.

BTW: The BSF (Bean Scripting Framework by IBM) has a engine-interpretation that allows using java-code as scripts. This is however implemented to compile the code into a class-file (which is quite slow the first time you run the code).

BSF is REALLY COOL as it provides a generic interface to scripting languages. So you can make your app scriptable without having to worry about the scripting language to use. Languages supported include (IIRC) JavaScript, Java, Python, Perl, Tkl, BML (bean Markup Language) and even Scheme and VB (i think). And it's quite easy to implement a custom engine for other languages...

Generics and Enumerated types are long needed

[wray]

Now if they would just implement unsigned types (uint, ushort, uchar) the jvm could be used much more effectively for lots of things. Especially vision, graphics, and all kinds of numerical algorithms.

Re:Generics and Enumerated types are long needed

[bunratty]

How would that be? Most operators treat signed and unsigned ints exactly the same. The only ones I can think of the top of my head are the inequality operators (< <= > >=) and division (/). In graphics, you're going to be doing lots of bitwise operators and shifting, and the operations ~ & | ^ << >>> all act as if the operands are unsigned.

Re:Generics and Enumerated types are long needed

[egomaniac]

Now if they would just implement unsigned types (uint, ushort, uchar) the jvm could be used much more effectively for lots of things. Especially vision, graphics, and all kinds of numerical algorithms.

What difference does it make? The only times I have ever wanted unsigned datatypes were when talking to legacy libraries that use them. The legacy libraries didn't actually need to be using unsigned datatypes, they just were.

So, when the only pain I have ever experienced due to this lack is when talking to legacy code that uses it, and the legacy code would have been just as happy using signed datatypes if it had been written that way, I don't really see the big deal. Might as well just kill unsigned datatypes altogether, simplifying life for everybody down the road -- and that's exactly what Sun did. Good for them, I say.

Re:Generics and Enumerated types are long needed

[wray]

Obviously you or the other poster haven't done much programming in the areas I pointed out. When dealing with memory intesive issues (e.g. very large datasets, or especially images) having to use a short to represent something that could be done in an unsigned byte doubles your memory requirement. This in turn slows down everything else while your computer is thrashing the drive for swap, and the bandwidth between RAM and CPU is eaten up. Images are an especially important example. Values for images are generally RGB triplets ranging from 0-255. Doubling the memory footprint of all images on your computer would kill it real fast with all visual icons and everything that most people use.

IMO, this blatant disregard for memory and CPU usage is the reason that computers performance has been ramping up slowly, while we have maintained exponential growth in hardware speeds.

Re:Generics and Enumerated types are long needed

[egomaniac]

. Images are an especially important example. Values for images are generally RGB triplets ranging from 0-255. Doubling the memory footprint of all images on your computer would kill it real fast with all visual icons and everything that most people use.

I'm sorry, but I get the feeling that you haven't actually done image work using Java.

A) Most image storage / manipulation is done by the underlying libraries. They can use unsigned numbers internally if they want, and I don't care.

B) At the level where you get access to color information, you're generally dealing with RGB or ARGB ints, instead of either bytes or shorts. This has no effect on memory usage.

Still failing to see the problem.

Re:Generics and Enumerated types are long needed

[wray]

That just assumes you are using their libraries. And RBG triplets packed in a int require unsigned also. Mostly, I have done a lot of building of my own libraries, which is generally what is needed. Like you said you think they are using unsigned underneath which means they are coding in another language besides java. I know their goal is to code their libraries in "100% java"

Doesn't work!?

[^ZuLu^]

Has anybody tried to download and install this baby on a Windows XP machine? I'm not able to use any of the new features (compiler tells me that symbols (methods, etc.) are unknown).

Is this possible? I don't have any other JDK on my system and I took the examples on the Sun page. Is anybody else experiencing this?

Re:Doesn't work!?

[gregfortune]

Open a console (Start -> Run -> cmd) and type

java

That should list off some help options if it is found in the path.
Then, run

java -version

(note the space...) That should tell you what version is running. My guess is that you *do* have another JVM installed somewhere.

Re:Doesn't work!?

[Anonymous Coward]

Did you pass -source 1.5 to javac?

Re:Doesn't work!?

[^ZuLu^]

Thanks for your help!
Well, I think I found the problem:
Du to the fact that you have to specify the source compatibility I forgot to provide the correct options for the Java compiler:

javac -source 1.5

This is quite bad. Why would I download the newest JDK if I have to switch that on all the time? That's annoying! Sun should change that.

Re:Doesn't work!?

[Anonymous Coward]

I got it running. The new File Chooser (looks like XP's) is reason alone to install it.

Still trying to figure out why javac isn't being seen, though... I'll probably have to reboot the stupid machine or set paths manually.

Nah they never will

[Anonymous Coward]

Java is for the idiot programmer. I bet you just lost 95% of the readership, when you emitted that line of code.

Java isn't about development power - it's about management power. It's about being able to hire idiots to write bloated code for big companies and pay them peanuts.

All of the people who like java are nothing more than mgt's biatch.

dot Nyet

[Pac]

.Nyet. I like it. If you don't mund, I will adopt the term from now on... :)

Java 3.0

[primus_sucks]

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

Scala
Nice

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.

Re:Java 3.0

[voodoo1man]

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.

No. What the smart programmer does in these situations is to learn the lesser language, write a translator (or two, or three) to the lesser language, and call it "code generation."

Re:Java 3.0

[primus_sucks]

Nice is actually a super-set of Java, so if you know Nice, you know Java. So you're argument would be like saying 10 years ago "I don't want to learn C++ because C is more popular". Nice and Scala both can seamlessly interoperate with Java (i.e. compile to byte codes and run on JVM, classes can extend/be extended by Java, can use any Java libraries, etc.). Also, some people (like me) just want to develop software in the most efficient way possible, and IMO this is the way to it. You never know, your employer might appreciate if you can show them how to speed up their software development by a factor of 2 or 3!

MacOS9

[acomj]

Prior to macOSX apple didn't bother to release newer javas (I think 1.2) because the OS8-9 wouldn't support some of the features it needed. Most modern OSs should easily support what the JVM needs

Code is for compiling and running

[Pac]

The fastest you have a running program, the better. Everything else, nice as it may be, is accessory. If you want to read something buy a book, I garantee you will find better entertainment. If you want to understand a program, read the docs, the comments and the diagrams.

Re:Code is for compiling and running

[Anonymous Coward]

Obviously, you work alone, or your co-workers that have to maintain your code hate you.

Code is not just instructions for a computer, it is a form of communication between developers that tells of the problem domain you are solving.

The code below does the same thing. The first is faster to write. Which would you rather have to maintain?


X = X - XX;
XXX = Aretha + SalesTax(Aretha);
X = X + LateFee(X1,X) + XXX;
X = X + Interest(X1,X);

or

balance = balance - lastPayment;
monthlyTotal = newPurchases + SalesTax(newPurchases);
balance = balance + LateFee(customerId, balance) + monthlyTotal;
balance = balance + Interest(customerId, balance);


(Hey,was I just trolled?)

The Web Services stuff is pretty nice

[sielwolf]

I'm glad to see the JAXP tools finally embracing DOM level 3 and SAX 2.0.1. All sort of XML Schema goodness involved there.

Of course Apache's Xerces-J has this support for a while with 2.5 (2.6)? Yeah it should be portable but, eh, why switch horses midstream?

SWT

[primus_sucks]

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

You need SWT. But I don't think you'll see sun promoting it:)

Re:For more information check out theserverside.co

[fyzix]

It's nice to see that a Java site such as theserverside.com completely ignores Mozilla. Check it out for yourself...

Access to developers?

[Anonymous Coward]

"Access to developers (while MS is the clear winner in the US..."

Says who? I haven't used a MS development tool in what...7 years now. They may still rule the desktop with regard to OS, but dev tools don't necessarily follow that. It's been Borland and IBM for me....

Re:Access to developers?

[lonb]

I think you misunderstood me. I was referring to the people not the tools. In America there are more developers who work in MS languages than in Java.

How to get your favorite feature into Java

[NonaMyous]

1. Convince Anders Hejlsberg to add the feature to C#.
2. Wait patiently for Sun's high priest of Java Language Specification to notice. This might take a couple of years.
3. Profit!

Wireless Web support

[ChiralSoftware]

I'm sure many of us are saying "finally" about many features: AMD-64 and generics being the big ones. My big FINALLY is that it finally supports WBMP in the image IO framework. Also improvements in sound and startup speed.

This release is fantastic. Java keeps on growing.

-----------
Create a WAP server now

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?

[Trinition]

No, it's still "Java 2". I once read, but do not recall the details, but there were some pretty vig changes from "Java" (1.1) to "Java 2" (1.2 and beyond).

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.

I am comming back to use java again...

[Anonymous Coward]

I used to love Java. Then came the fuc**** dotnet world to wreak havoc. Now Java responds well enough for me to take a look at it again. :P

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

[blamanj]

Sorry. You've confused source and target. If you compile with -source 1.5, it tells the compiler to allow the new 1.5 constructs in the source code, but the target bytecode is still 1.4 compatible.

There have been no bytecode changes in the JVM since it was released, though class file formats have changed.

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.

Sun Java VM bloated

[Anonymous Coward]

Big installation aside, it installs a giant .MSI file, plus a backup of all the library files! Does anyone know how to turn the duplicates off?

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

[brett_sinclair]

You've confused source and target.

No. -source 1.5 implies -target 1.5. And even if the bytecode is basically the same, jdk1.4 refuses to run code compiled with -source 1.5 (with javac from 1.5.0beta). All you get is a java.lang.UnsupportedClassVersionError.

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:The biggest problem with compatibility...

[Zoolander]

Couldn't you just do a perl -pi -e 's/^enum$/__enum/i' on your java files? (First doing a grep -r __enum * on your source tree, so you don't accidentally name it to some existing variable)
Doesn't seem like too big a problem to me.

Re:The biggest problem with compatibility...

[Zoolander]

Or do a search and replace with some nice Java IDE, Intellij IDEA for example.
Also spotted a typo: The 'i' should be a 'g'...

Re:The biggest problem with compatibility...

[ayahner]

Not too much of a problem?
Have you ever dealt with the issues of having a reliable product module deployed to a customer for the past 2+ years break when they upgrade to the latest SDK, as product managers are wont to do.
I certainly agree that, as a programmer, the fix is simple enough. There are 100 dfferent ways to search and replace your code, but that isn't the point.

The point, as a customer will see it, is that some developer wrote code that was shoddy in the first place. This may or may not be true, and they won't know that there was no way of knowing that enum would become reserved behind your back, but the perception could cost customer dissatisfaction. Especially if the original source is owned by a development firm, and that firm no longer exists. Back to the code escrow problem...
In a business where reliability is an issue (and I can't think of any business where it SHOULDN'T be), it is our responsibility as developers to AVOID this issue, and therefore, find it before the customer does. But the original posts stands stronger than your reply:
It may not be a large development problem, but it will be a problem.

Re:The biggest problem with compatibility...

[Zoolander]

Good points.
But should we as developers really be responsible when/if the customers upgrade some vital part without at least checking with the guys who gave them the program?
Patches and upgrades can break stuff. That's true everywhere.
But this is really only an issue, IMHO, with proprietary code that can't be modified for some reason or another. Although that's no help for people who are stuck with it, I know, I know...
Here, OSS has a distinct advantage. I guess I was too stuck in that mindset: that you just change the code, recompile, and ship it.

Re:The biggest problem with compatibility...

[Deadbolt]

No, it will not be any sort of problem.

If you feed bytecode compiled by 1.4 to a 1.5 VM, it will work just as it did without any alteration. So when the happy customer upgrades, it won't break. Upgrading a VM *will not break* previously working code.

By default JDK 1.5 compiles source into bytecode suitable for 1.4 VMs. That means that unless you specifically use "-target 1.5", any use of newly minted keywords like "enum" won't conflict with old variable names.

If one fine day the developer decides that he wants to use 1.5 features, he can search and replace the variable name and use -target 1.5, *but he is not forced to do that until he wants to*.

Try not to panic so easy.

Re:The biggest problem with compatibility...

[Miles]

Don't do a search and replace--do a refactoring by renaming it. Eclipse supports this, so I imagine IDEA would, too. This can also change method names, and other uses of the 'enum' variable/field.

Re:The biggest problem with compatibility...

[NMSpaz]

I doubt it, when the assert keyword was added, you had to compile with -source 1.4 to use it. So the compiler is compatible by default, then you explicitly switch-on the feature if you need to use it on a file-by-file basis. So old code with "enum" isn't a problem

Re:The biggest problem with compatibility...

[ayahner]

Not panicking, but you are correct about the old bytecode working without problems. You can recompile the source using the latest, and only get warnings about the new reserved word.

The fact remains that the reserved word needs to be changed if the JDK gets implemented and the PM decides to use the new language features, and also that there changing it is simple, sure. But it is a change. To a Project Manager, it goes on the risk list.

Version changes for the code are probably not worth a recompile, but if the code is still under development/revision, the change will simply be incorporated into any migration, simply, as pointed out.

Also, of course, we've all known that enum has been on the list of probable changes for so long, that using it in code was probably a bit short-sighted anyway.

But overall, I will retract my arguement, as the PM should not upgrade VMs without a ROI analysis for the next FY, and if the CTO and CFO agree, the PM will have devs change JDKs ASAP, since the risk is low and the work is small.

TTFN

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

[blamanj]

If you've tested it, then I believe you, but the docs are wrong then because they say "target -1.4 is the default."

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

[brett_sinclair]

The docs are (obviously) not very clear. But in fairness -target 1.4 is the default - unless you specify -source 1.5.

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:operator overloading

[Featureless]

Here is my general response to this observation.

And to your specific question, the simple fact is that you can define your operators however you like - when you create the language - which can be bad or good, depending on your decisions - and this is not operator overloading (which is always bad).

My central point is that that operators are 1-letter function names. You just don't want them doing a dozen different things depending on circumstances that aren't immediately visually apparent.

You may find it difficult to handle math if you can't treat it like algebra on the line. I find it difficult to debug your code when I have to stare at your code for longer to figure out what is actually happening. When troubleshooting becomes really more complex, then you have things like mars probes landing at the wrong velocity and so forth. You will just throw up your hands, but I will be telling you why it was more likely that someone would make a mistake.

So the source of my confidence in my pronouncement is that after a decade I have never a place where there was so much "good" use of operator overloading that wasn't more than overshadowed by the problems that came from it.

This may be a function of the kind of programming I've done, but I just don't see a lot of deep math in non-standard data types where the method rule really makes it as bad as you say. It is often a lot easier to express yourself with methods clearly than people admit...

Re:operator overloading

[NoOneInParticular]

Still don't buy it. I don't think a language should make a vector/matrix/complex a basic type simply to avoid overloading. A language itself should be as simple as possible to make things work: libraries are used to extend the language, and there operator overloading is a must.

Obviously anyone writing application code should use such libraries and not try to build them. Newbies making use of operator overloading should be taken out and shot in the foot. A simple solution for java would be to have a compiler flag like -library. If on, operator overloading is allowed, if off, its generates errors. This will enable vendors to supply serious (tested) libraries for numeric/graphing stuff, while still protecting innocent developers from the evils of expressive code.

Re:operator overloading

[Featureless]

I see what you are saying. Well, it's a balance, reasonable people will disagree, and who knows in the end. The compiler flag is a good idea. It's all a matter of degrees. Most programmers are not mathematicians, and I still say the more complicated you make your operators, the more trouble you'll get into.

Re:operator overloading

[Kupek]

Okay, I'll bite. Read how the aglorithms in the STL are implemented. Stroustrup's book has excellent examples that are more digestable than cracking open the STL source if you don't feel like approaching that.

Dumbass.

[Anonymous Coward]

Java availability on Mac OS X?

[gumpish]

Hey there.

I was wondering if you have any info on 3rd party SDKs or JREs for Mac OS X.

Specifically I was pretty annoyed that no official 1.4 JRE was ever made available for Mac OS 10.1, and now I strongly suspect that no official 1.5 JRE will be available for Mac OS 10.2

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!

Re:Pain in the ass to download

[Anonymous Coward]

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

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.

ooops...

[NumbThumb]

...this should not be a reply-to-self but a reply to the AC telling me about OCAML. damn.

Amazing!

[kahei]

Among all the posts from java users containing disinformation, paranoia, and FUD about C#, I finally found an _even more_ biased one going the other way!

I shall call this new sport 'ignorance surfing'.

Re:For more information check out theserverside.co

[fyzix]

Compare the rendering of the page in Mozilla to IE. I'm using Firebird 0.7 and the header section is borked.

opengl

[Anonymous Coward]

I remember OpenGL being announced, but never saw any mention of it again. The JOGL site seems to be dead. what is going on? First they get my hopes up...

Re:For more information check out theserverside.co

[aled]

I'm using Mozilla 1.5 and is just fine. A great improvement over the previous theserverside L&F that had problems in Mozilla.

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:Catching up to Common Lisp?

[Anonymous Coward]

Yeah, then you can concentrate on FASLs, writing FFIs to a GUI toolkit, and writing your own networking code. Ha.

Re:New features - Half way there

[Cthefuture]

Mark my words. All of that will come in time.

See, Java started out like so many projects. "We'll do it better because the current stuff is too complex."

Then they learn, like everyone always does, it's complex for a reason.

Worthless, Absent 64-bit Array Indices

[mosel-saar-ruwer]

Finally! I can use a 64 bit version of Java on the Opterons and see how the speed on the large (~6 to 8 gig datasets) improves/decreases

Unless and until the language supports a construction like the following, so-called "64-bit" support is utterly meaningless:

double [] theDoubleArray = new double[WHOPPIN'_BIG_64-BIT_LONG];

for(long i = 0; i < theDoubleArray.length; i++)
{
theDoubleArray[i] = foo.bar(i);
}

So: Did we get 64-bit array indices this go-round? Or do we have to wait another two years?

If the latter, then: HELLO C#!!!

Re:Worthless, Absent 64-bit Array Indices

[Wesley Felter]

You want to create single arrays larger than 32GB? What kind of hardware are you using?

Re:Worthless, Absent 64-bit Array Indices

[mosel-saar-ruwer]

You want to create single arrays larger than 32GB? What kind of hardware are you using?

Larger than 2^32 = 4GB, dude.

You're [possibly] thinking of Intel's 36-bit hardware hack, which gets you [at least theoretically] to 2^4 * 2^32 = 64GB.

But I know of no programming language which supports 36-bit array indices.

WE NEED 64-BIT PROGRAMMING LANGUAGES!!!

Re:Worthless, Absent 64-bit Array Indices

[Wesley Felter]

No, an array of 8-byte doubles with 2^32 entries is 32GB; that's the largest array you can create in Java.

Re:For more information check out theserverside.co

[fyzix]

I'll correct myself, it doesn't render properly at 800x600 in Firebird 0.7.

Still no operator overloading

[highwindarea]

Sigh

Code is for life, not just for writing!

[gidds]

Er, yes, I've had to maintain code by people who clearly thought like that, and what a nightmare it was...

I saw an estimate once that 80% of the time spent on code is maintenance. (Of course, this will vary between systems and projects. But it seems reasonable IME.) That means that people will spend four times as long reading code, amending it, extending it, and fixing it, than they do writing it in the first place. Code that suffers from being knocked out quickly takes longer overall -- bugs are harder to find, it's harder to change without breaking, it's harder to learn from, harder to fix, harder to read, harder to do anything with. That applies whether it's the writer or anyone else -- but especially for anyone else, who might have trouble following the author's disorganised thought processes or labyrinthine code.

IME, clarity and neatness isn't something you can turn on and off. People who don't care about how code looks or functions, often don't care about how well it works, or even whether it works...

As another commenter said, I hope I'm being trolled here!

What fool

[Anonymous Coward]

I would like to ask the question "what fool came up with the idea of writing code inside comments, aka metadata" Are we now not allowed to change comments anymore? This is pure stupidity... At least C# solution is more elegant than this. Sorry.

Re:For more information check out theserverside.co

[Suppafly]

I'll correct myself, it doesn't render properly at 800x600 in Firebird 0.7.

If you are going to use a pre 1.0 release of anything, you aren't really entitled to complain, especially when you aren't even using the latest pre 1.0 release of said software. It renders fine in .8 of firebird. The site can't really be held responsible for the fact that different versions of mozilla browser's render it differently.

Too bad the generics are not typesafe w/reflection

[jlrobins_uncc]

Reflection breaks the typesafety of the generics model, which is enforced only at compile time. Therefore, any reflection-driven manipulation of generic collections, such as via Jython, will completely bypass the typesafety of the system, probably yeilding ClassCastExceptions at retreival time (I've not played with the beta yet, so I'm talking out of my ass a little bit here).

It would be nice when / if the EJB CMP relation interfaces switch from vanilla Collection and Set to these typed collections. Would ever so pretty up EJB code!

Re:For more information check out theserverside.co

[fyzix]

Firebird 0.8, hmm?

Yah

[sbszine]

Most languages seem to use . to cat strings, but I suppose Java needed that operator more elsewhere :)

Personally, I don't mind using -> to invoke a method. It gets around the overloading problem and doesn't seem like that much extra typing when you consider that most of the stock classes and methods have incredibly long names. Which leads me to my pet peeve, the encouragement of one letter variable names, leading to bizarre stuff like:

PortKnocker p = new PortKnocker();
p.knockOnSomePorts();

Heh. What do YOU call non trivial?

[FatSean]

If your code only depends on other open source software, you are correct. If you must interact with closed source APIs then things get ugly. Your shared libraries just work on multiple Unix servers? Java server plugins do.

You got it !

[Anonymous Coward]

This is a new feature Reachability of host

Implemented using ICMP & echo !

Instrumentation API rulezzz !

[Anonymous Coward]

And will help Scripting and dynamic bytecode generation tools Yet another cool feature in Tiger :)

Shared Connection

[Yoda2]

The apps we've developed with SwingSet all use a shared connection.

when will there be a 1.5 certification exam?

[vernonB]

I wonder if Sun plans to roll out a Java programmer certification upgrade exam for the 1.5 platform before my 1.4 certification expires in March 2005.

SORRY ALL--My Bad

[severoon]

I have indeed set off a number of bullshit detectors, and rightly so. I apologize. My statement that C# code must be run on a Windows-supported platform under Windows is incorrect. This is admittedly very old information that I should have checked out, in fact the only time it could have been true was in the formative stages of the language and the .NET platform.

I try to be as responsible as I can in posts to the /. community because it is the first forum I've found that self-moderates so well (in most cases, anyway--I'd apply a negative mod to my own post here if I could).

Anyway, thanks to those who pointed this out.

sev

Example Given Is Neither Necessary Nor Sufficient

[severoon]

I too thought of this as a possible means of explaining this situation, but rejected it (and I'm referring to your intended meaning pointed out by tbspit in this thread). The explanation you put forth here does not satisfy because the same argument could be applied to Integer[]s and Number[]s.

Alas, the corresponding array code does indeed fail at compile-time, and it is well-defined and unambiguous:

Integer[] i = new Integer[3];
Number[] n = i;
n[0] = new Float(1.1);

There's no reason in generics why the compiler couldn't have been designed to similarly reject code if you replace the arrays with type-parameterized ArrayLists.

sev

Re:For more information check out theserverside.co

[Suppafly]

Yup

Give me strength!

[Anonymous Coward]

Bablefish Translation of Parent Post:

"Shit! I know C inside out, even the tricky stuff like not dereferencing null pointers! Who's going to pay me $$$ to be that smart when any yahoo with a copy of Eclipse & the JDK can write apps for any platform! Hmmm if only I'da thunk a bit longer, I could have brought up a real objection to the Java language - no guaranteed behaviour at object destruction, for example. Too late now though.."

Worthless. Pitiful.

Don't you guys ever hit preview?

[MillionthMonkey]

None of your angle brackets are being rendered.
Discussions of generics never seem to get very far on Slashdot.

Scheme and Java

[kingtutt]

I know various people that are taking Intro to Computer Science at my university. The class starts out in Scheme (ie Miniture LISP) then progresses on to JAVA. There teacher tells them that Scheme is the basis for JAVA (not the syntax but the underlying-operation). I've used both and I really don't see any parralles... Does anyone else see how JAVA is built upon Scheme (if it is at all...)