Slashdot Mirror
Java SDK 1.5 'Tiger' Beta Finally Released
kingkola writes "Finally, after about two years of development, the Beta for Java SDK 1.5, aka Tiger, has been released. Features added in this edition include generics support, autoboxing of primitives, syntactic sugar for loops, enumerated types, variable arguments, sharing of memory between multiple VMs and a bunch of other bugfixes, enchancements, etc."
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.
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.
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.
There ain't no rules here; we're trying to accomplish something.
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.
Your pizza just the way you ought to have it.
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).
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!
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.
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
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).
What the hell are you talking about? Be more specific.
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).
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).
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).
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.
HAND.
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.)
I hope that helped clear things up...
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
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)
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?
Ceterum censeo subscriptionem esse delendam.
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:
..the list goes on.
- 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)
"Ain't I a stinka..." - Bugs
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.
Infuriate left and right
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.
File under 'M' for 'Manic ranting'
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.
Suck figs.
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.
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.
ZFS: because love is never having to say fsck
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.
Erlang.org: wow
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.
Developers: We can use your help.
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.
.Net support in eclipse.
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
Jilles
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.
Want to Know How to Cheat the GPL? Read On!
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.