Java 2 SDK v1.5 Beta 1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
My Java applications start faster, JFileChooser’s run much faster. Applications are more responsive.
I really like that…
Go Java!
allow an application’s JNLP file to specify what integration to do. The JNLP file can now suggest desktop and/or menu and specify submenu names.
Happy days…
> My Java applications start faster, JFileChooser’s run much
> faster. Applications are more responsive.
Than crawl, which isn’t to say much.
The primitive wrapping/unwrapping was definitely due, the simplifying of for and generics are clumsy solutions to a serious problem, but solutions nonetheless (solutions with the burden of grammar complication). If only Sun would implement blocks a la Smalltalk, much simpler solutions would be simple to implement in turn, using no syntax extensions.
The problem is, all this should have been present in java 1.0. Now, we’re left with uncertainty. If you should use J2 to write something, you don’t know whether it will run in the target. Which is a problem for an intended distributed model.
It’s about time.
The problem is, all this should have been present in java 1.0. Now, we’re left with uncertainty. If you should use J2 to write something, you don’t know whether it will run in the target. Which is a problem for an intended distributed model.
Not sure about all of the features, but the generic implementation is a compiler hack. Still uses old data types but automatically generates code to do casting at runtime. Thus compiled classes WILL still work under older JVMs. I’d imagine, but haven’t checked, that many (if not all) of the other features added are also done by the compiler.
> The primitive wrapping/unwrapping was definitely due, the simplifying of for and generics are clumsy
> solutions to a serious problem, but solutions nonetheless
Personally I’ve found the new syntax quite intuitive, and not clumsy, though I am not familiar with SmallTalk
> If you should use J2 to write something, you don’t know whether it will run in the target
The 1.5 compiler generates bytecode that runs on older VMs, even when the new generics and for loops are used. Using the new APIs won’t run in older versions however, as can be expected.
> Now, we’re left with uncertainty. If you should use J2 to
> write something, you don’t know whether it will run in the
> target. Which is a problem for an intended distributed
> model.
Hence Web start where you can specify a minimum required JRE version. JNLP really is a great thing to use in many environments.
How stable is this?
Any apps appear to not run on this?
Does anybody know of any ports of this beta version (or even 1.4.2) to Solaris 2.6?
Thanks,
John
Should I uninstall it before installing the 1.5 beta?
> Should I uninstall it before installing the 1.5 beta?
There shouldn’t be any need to. I’m running both 1.4.1_02 and 1.5 beta. I just set the JAVA_HOME and PATH envrironment variables for the version I want to use, e.g. JAVA_HOME=c:j2sdk1.5.0, PATH=c:j2sdk1.5.0in
You can have as many JREs installed at once as you like, then use the control panel applet to set the default.
> How stable is this?
So far fine.
> Any apps appear to not run on this?
Have problems with some JNLP based apps which have listed all the versions of java instead of doing 1.X+ (and thus trys to download 1.4.2 each time it starts), but this is a problem with narrow minded developers, not 1.5.
The new Metal L&F is… err… IMO not as nice as the old one. Way to lickly.
> The primitive wrapping/unwrapping was definitely due
Why? I’m not convinced on this feature. Or static imports.
> J2 to write something, you don’t know whether it will run in the target.
You have always had this.
Use a 1.4.2 feature, and guess what, it don’t run on 1.4.0!
As mentioned above, this is what Webstart is for (but not when ppl abuse it
)
Although i can hardly wait for 1.5 final to be released (yay generics!!!) i really think it`s time to start planning a 2.0 version.(java 3??)
It is really time to remove 1.0 backwards compatability and alot of the deprecated cruft/interfaces and move forward into the new milenium.
Has someone a screenshot of the new look and feel ?
SwingSet2, first tab: http://j2mevnc.sourceforge.net/test.jpg (78k)
Better. Not great. But better.
(i hate microsoft. avid mac fan, so don’t think i’m going off on java. it’s one of the few languages i like).
it needs dynamic recompilation like C#.
simply put, having to redecode the bytecode every time, and re JIT compile it is a WASTE of processor efficiency. store the bytecode and JIT compiled code in a fatbinary like C# and do it right.
since sun hasn’t woken up and smelled the fricking roses yet: Swing is slow. Swing is crossplatform. AWT isn’t crossplatform. SWT is fast, SWT is crossplatform. i know you don’t like working with competitors sun, but IBM got this right. run with it. SWT has problems that sun could fix by integrating the good features of swing (layout managers) with SWT (fast native toolkits).
People still complain about how “awful” OS/2 looks, but java is still dreadful by a country mile plus being the worst memory hog out there !!
This computer is JAVA free and proud of it.
I love java as a langauge, and I even like that you can write a swing app that runs on multiple platforms without change.
However, I don’t like that they run slower than native apps, and I don’t like that they don’t have the native look and feel.
What I do like however, is the java-gnome project, which lets me use glade to design and interface in GTK+, use libglade to load the interface and write the application in Java. I think Java is a good language for writing business applications, and I think GTK+ is a good widget set.
The java-gnome project is starting to move along quite well, especially now it is part of gnome-bindings, but they just need a bit more help.
It is also a pity that this project hasn’t the time to port to windows, this would then provide the similar cross platform gui feature as swing.
SWT of course gives you this. I have done a small bit of work trying out SWT, I didn’t really like it. However, I would love it, again if I could use glade to design the interfaces and libglade to load it! I really think this way of designing a gui is excellent, and it’s just a pity that an IDE and Widget set (other than java-gnome) hasn’t provided this type of integration. Well, you can draw gui’s in netbeans, but I have always found netbeans to be just too slow. I also don’t like having my gui-connecting code generated and non-modifyable other than by modifying properties!
Anyway, just a rant that’s been building up…
> However, I don’t like that they run slower than native apps, and I don’t like that they don’t have the native look and feel.
You can use getSystemLookAndFeelClassName() on Win2K, XP and I think on OSX too. Looks like the real mccoy.
Please see this:
http://java.sun.com/j2se/1.4.2/docs/guide/swing/1.4/Post1.4.html
Sorry I don’t have screenshots. Maybe someone else does?
> What I do like however, is the java-gnome project, which lets me use glade to design and interface in GTK+, use libglade to load the interface and write the application in Java.
I hear you. Been meaning to try this out.
Yes, you can get the system look and feel, and it does look the same, but only on those two.
I know Sun did implement a look and feel for GTK, but it really is ordinary.
I guess this is the bonus of SWT, it does use native widgets, so the look is right and it does run quicker.
You should try them out, java-gnome is moving along well and very useful. It is amazing that you can go from a day to do a basic window layout to something like 30 minutes using glade, then connecting the code up!!
I hate glade. It is a very simple user interface builder and far from a modern RAD environment. It was very nice about 10 years ago, but today a little bit obsolote. SWT is a good idea (native look&feel on every platform), but SUN isn’t support it. Eclipse is very nice, but without integrated form designer not too useable for real application development. Netbeans seems good but it is based on ugly, big and slow SWING.
swing is not slow. The matter is that there are not big applicaiton using swing, that’s why no one nows how fast Java ui can be.
Try out intellij, it’s much faster as eclispe. It doesn’t use SWT
I tried intellij, and just could not use it because it was too slow!
intellij is a good tool, but I can’t sit around waiting for things to slide in and out, or pop-ups to display. I find this IS because of swing.
SWT has no use for those who need to develop BiDi applications, there’s no equivalent to Swing’s CompononetOrientation.
As for large apps using Swing, check EIOffice:
http://www.evermoresw.com/weben/product/eio_overview.jsp
There is an attempt at a GTK+ emulation in 1.5.0b1, but it is absolutely hideous. I wouldn’t have guessed it was supposed to emulate GTK+ if it didn’t say it was…
The main problem is font rendering. Swing doesn’t use Xft/Freetype – so font rendering is both very, very ugly and (more importantly, if you try to emulate a “native” look&feel) doesn’t look anything like other applications.
I’m getting way too spoiled by freetype’s brilliant sub-pixel anti-alised fonts to put up with Swing these days. I even stopped using Intellij’s otherwise fantastic IDEA: readability sucks big time compared to Eclipse.
I’m coming from Java background, but I’ve spent last 2 years programming for .NET with C#. I really like what C# has to offer, and I must say that I don’t get the idea why Java was crippled this way in 1.5? Java creators obviously wanted to catch up with the latest C# but the results are more or less dissappointing.
Is there any particular reason why Java devz decided not to modify the virtual machine but focused on creating an (ugly imho) syntax extensions that compile to unmodified bytecode?
As far as I understand, 1.5 apps that take advantage of new runtime features (metadata annotations, etc.) will not work with older JVMs even though the bytecode looks compatible.
Why didn’t they follow the same idea as MS.NET did with .NET 2.0 (modify VM to add runtime support for generics for both reference and value types)? I think it’s obvious that the speed increase for strongly typed collections of value types is great.
Does anybody know if there are plans to make “int”, “boolean” and other primitives the first class citizens in future versions (like value types in .NET)? Or will they have to be wrapped as “Integer”, “Boolean”, and so on? I think that value types are the single best feature of .NET and doing without them is painful.
OK the default Swing L&F is not beautiful, but just use the system look and feel !! I wouldn’t call this ugly :
http://www.ammai.com/modules.php?op=modload&name=News&file=article&…
And on a decent machine, Swing is fast.
Don’t say you hate Microsoft then just after you want dynamic compilation just like C# ….
>As far as I understand, 1.5 apps that take advantage of new runtime >features (metadata annotations, etc.) will not work with older JVMs >even though the bytecode looks compatible.
Well,guess: if the code uses new features only available on a
1.5 VM, you can’t use them on something <1.5 (just try using
.NET 2.0 Generics on .NET 1.0…);
>Why didn’t they follow the same idea as MS.NET did with .NET >2.0 (modify VM to add runtime support for generics for both >reference and value types)? I think it’s obvious that the speed >increase for strongly typed collections of value types is great.
While I don’t know Suns specific reasons (besides not wanting
to major changes in the JVM), value types are not necessary;
they would also complicate the semantics of the language
and platform without a gain that would justify the cost of
adopting these changes (updating libraries, education
of developers (all developers, as the introduction of value
types has a major influence on the semantics of the language));
I wouldn’t call this ugly
Well, I would. No Cleartype?
>since sun hasn’t woken up and smelled the fricking roses yet: Swing >is slow.
No (which is about as substantiated a claim as yours….);
>Swing is crossplatform. AWT isn’t crossplatform. SWT is fast,
Then try using its Table or Tree controls with real world size data sets; as the SWT controls
map directly to native controls, they do not support the MVC
pattern, which makes use of larger datasets possible;
There is JFace, an API layered on top of SWT, that offers
MVC semantics, but not it’s performance and memory footprint
advantages;
> SWT is crossplatform. i know you don’t like working with
>competitors sun, but IBM got this right. run with it. SWT has
>problems that sun could fix by integrating the good features of
>swing (layout managers) with SWT (fast native toolkits).
Well, SWT could do with a good refactoring; it ‘s just
weird to see a “cross platform” API, where classes expose
properties called “win32s” and the like (just look it up in
the SWT doc, available in each Eclipse installation);
The fact that Eclipse (written using SWT) is fast, does not necessarily mean that SWT is fast, it might just mean that
the Eclipse team spent a lot of time optimizing Eclipse;
a Swing app, that wasn’t just slapped together in 5 minutes,
also looks good and feels fast (just look at the stuff by
Karsten Lentzsch http://www.jgoodies.com/ ;
SWT certainly has its place: applications, that need to
look and behave as native as possible; Many people don’t
care for that; I prefer to have my apps look & feel the same
when I switch between Win and Linux;
It is, and always has been, emulated. As a result, it’s easy to catch it out, e.g. on Windows XP I reduces the size of the title bar and it’s buttons. The new button size was reflected in all MDI apps, except the Swing one I was using (NetBeans). SWT and JFace use the underlying API and so integrate perfectly. Swing is easier to program, and architecturally nicer, than SWT, but for a decent app, I’d got with SWT any day.
That said, almost everything I’ve done using Java has been JSP based, and that’s the market I think they should concentrate on.
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.
http://developers.slashdot.org/comments.pl?sid=95605&cid=8188472
If you think Java (or X11 for that matter) is slow, then I guess its time to ditch that 486…
You people should try this new Office Suite:
http://www.evermoresw.com/weben/product/eio_overview.jsp
Its faster than OpenOffice, looks exactly like MS Office, has a nippy interface, runs on red flag linux & windows, and – yes – is written in Swing rather some alternative braindead solution like SWT or whatever.
The problem with Swing is that it is terribly, terribly easy to write a crappy Swing application that works. Its a doddle. The results are not usually any good, though. This is quite unlike most other widget toolkits, which are considerably more difficult, but when you do write one it’ll thus be better. Nonetheless, writing fast, performant Swing applications is perfectly possible.
The world is full of Swing applications written by OSS tossers where they haven’t bothered to seperate the event thread and keep it clean of code, haven’t thought about how to make it look decent and easy to use, and so on & so forth, Still, put Swing to good use and you end up with an Office suite that OpenOffice & KOffice and other native apps wish they could be as good and fast as..
>>The problem with Swing is that it is terribly, terribly easy to write a crappy Swing application that works.
ok, i’ma using SWT cause i think that i’am doing that with SWING ! where can i find some info on how to avoid that ?
To everyone pointing out the advantage of swing programming being the only/best way to do cross-platform development:
There is a way your application can run on 95%+ of all machines out there, being beautiful and easy to use and install, and most important: slim & fast!
Yeah, it´s possible! It ist called… Windows programming!
Like it or not. That´s the way it is.
I was a big java supported, until recently.
I have submitted a number of bugs with Java re: Windows look and Feel which exist in 1.4.2.
They can be addressed by WinLaf 0.4 (which is a hack).
Sun appears to be ignoring SWING developers.
A new Look and Feel, but leaving Windows look and feel as broken is not progress..!
Fix the menus, buttons, fonts, message boxes etc etc before giving us new stuff please..!!!
otherwise many developers like myself will move onto C#..
>> The primitive wrapping/unwrapping was definitely due,
>> the simplifying of for and generics are clumsy solutions
>> to a serious problem, but solutions nonetheless
>
> Personally I’ve found the new syntax quite intuitive,
> and not clumsy, though I am not familiar with SmallTalk
Well, since Smalltalk has block closures, all you have to do for a for is
collection do: [:element | …put code here…]
In a sort of java syntax:
collection.do((Object element)
{…put code here…}
);
‘(args){code}’ being a possible syntax for a block.
Try a simple example with somewhat Smalltalk-like Java:
String caps=String.new();
“NiceJava”.do((char c){
if(c.upperCase)
s.add(c);
})
The key here is that this is extensible and builds on existing elements unlike some syntax change for a compiler hack.
>> If you should use J2 to write something, you don’t know
>> whether it will run in the target
>
> The 1.5 compiler generates bytecode that runs on older
> VMs, even when the new generics and for loops are used.
> Using the new APIs won’t run in older versions however,
> as can be expected.
That should mean that one can still develop for 1.1.8 using the innovations? That’s good.
>That should mean that one can still develop for 1.1.8 using >the innovations? That’s good.
I think you mean improvements. C# was the first major interpreter (that has JIT compilation, run-time exceptions, etc.) to implement the majority of these features, and they weren’t the first to come up with the ideas. Hell, foreach has been around forever, in a lot of scripting languages and stuff.
especially complains about swing should stop now, it is still beta, give them 1-2 months. it is not a big issue. if you want to flame, flame after the release.
Then move on to C# and be vendor/OS locked.
It is “BETA 1” people.
>> Personally I’ve found the new syntax quite intuitive,
>> and not clumsy, though I am not familiar with SmallTalk
>
>Well, since Smalltalk has block closures, all you have to >do for a for is
>
>collection do: [:element | …put code here…]
>
>In a sort of java syntax:
>
>collection.do((Object element)
>{…put code here…}
>);
>
>'(args){code}’ being a possible syntax for a block.
>
>Try a simple example with somewhat Smalltalk-like Java:
>
>String caps=String.new();
>
>”NiceJava”.do((char c){
>if(c.upperCase)
>s.add(c);
>})
>
>The key here is that this is extensible and builds on >existing elements unlike some syntax change for a compiler >hack.
Closures like in Smalltalk or LISP are cool, and I agree with you that they are the most elegant and general solution for iteration. However, I think Sun made the right decision by not adding them. As a general language feature, I don’t see Java programmers clamoring for blocks/closures. For the case you talk about (collections), I don’t see that it has a huge advantage over generics, while it does have the considerable practical disadvantage of being very unfamiliar to people whose only OOP languages are Java or C++ (i.e. probably 90% of Java programmers). As for replacing for loops with blocks and internal iterators, as a practical point it’s never going to happen in Java.
Also, I think there is a lot to be said for keeping Java conceptually simple and not tossing in every language feature somebody happens to like (multiple inheritance, closures, coroutines, etc., etc.) This is one thing the Java language has going for it that you are not likely to see in any competing product from Microsoft.
Closures like in Smalltalk or LISP are cool, and I agree with you that they are the most elegant and general solution for iteration. However, I think Sun made the right decision by not adding them.
But Java does support closures* (through anonymous inner classes – each time you see a Class$1.class file), all it needs is preprocessing to make them usable. I wouldn’t recommend adding them if the only purpose were iteration, but they are just one of the things I feel a language is crippled without (mind you, machine code doesn’t have them and it can do anything).
Far be it from me to wish Java were Smalltalk (what would be the point?), but I’d be heppay if Sun would allow the use of something which the language’s machinery already supports. Like it’s just done with generics and primitive types’ automatic wrapping/unwrapping.
(*) In
Thread t=new Thread()
{
public void run()
{
outerVariable.change();
}
}
you have a closure.
I think that soon the comments about Java’s speed won;t be valid since it won’t be noticeable> On my box (P4-2.4GHz 1GB RDRAM) NetBeans opens in <15secs and thats fastenoguh and once its running its smooth sailing. True it’ll always be a little slower but thats a non-issue since it’s increasingly becoming impreceptible.
On my box (P4-2.4GHz 1GB RDRAM) NetBeans opens in <15secs and thats fastenoguh
<chuckle> What would be slow? I find 10s for Mozilla on my 112 RAM 900MHz Duron laptop damned slow. I used to use Windows 2.x on a 1MB 8MHz 8086 and it was faster… running quite a few apps.
and once its running its smooth sailing.
True it’ll always be a little slower but thats a non-issue since it’s increasingly becoming impreceptible.
Now these two are the important measurements. Unfortunately, I don’t notice either going the way you mention.
I really dislike Java, but I agree it’s getting better. However, I don’t see that the software written in it is.
>> Closures like in Smalltalk or LISP are cool, and I agree
>> with you that they are the most elegant and general
>> solution for iteration. However, I think Sun made the right
>> decision by not adding them.
>
> But Java does support closures* (through anonymous inner
> classes – each time you see a Class$1.class file), all it
> needs is preprocessing to make them usable.
Doh! Good point, I had totally forgotten about anonymous inner classes in Java – haven’t seen that feature used in a while, although it does come in handy from time to time.
> Far be it from me to wish Java were Smalltalk (what
> would be the point?), but I’d be heppay if Sun would
> allow the use of something which the language’s machinery
> already supports
Fair enough.
Personally, I would like that too. However, the crux of my point is that I don’t think you can take Sun to task too much for the approach they chose given that your average Java programmer wouldn’t know a block closure or internal iterator from a hole in the ground.
However, the crux of my point is that I don’t think you can take Sun to task too much for the approach they chose given that your average Java programmer wouldn’t know a block closure or internal iterator from a hole in the ground.
Oh, of course. Overall I think Java fulfills its goals well. I just regret syntax extensions and when I saw the : I skipped it.
One thing not addressed (and I think it just can’t be) is the lack of static inheritance:
class Bug{abstract static Image pic;}
class Spider extends Bug{pic=picFrom(“spider.jpg”);}
class Ant extends Bug{pic=picFrom(“ant.jpg”);}
is just not possible… though one can do without it, just make every spider have a reference to the same Image. It’s not too troubling to waste 4 bytes per spider, but the conceptual quirk is hard to swallow (for me).
> A new Look and Feel, but leaving Windows look and feel as broken is not progress..!
the new theme is NOT a L&F it is a colour tweek on Steal (gray/purple)
> They can be addressed by WinLaf 0.4 (which is a hack).
Use that? Tis plugable. (But I too would like to see Windows L&F worked on, post the bug ID and I’ll vote on it. No idea if it makes much diff)
> I used to use Windows 2.x on a 1MB 8MHz 8086 and it was faster… running quite a few apps.
Any of the apps a full blown web browser? No did not think so.
How about an IDE in the same class as NetBeans?
Shock, no again.
A Java app, once running for a while, will ofton get compiled to native (ohh for .net-like keeping of pre-complied). The start up time is the killer, and with stuff like shared VMs, this will fall to a degree that the user will not notice the diffrence.
like it or not, most programming isnt done for desktop windows use.
get over it.
> I used to use Windows 2.x on a 1MB 8MHz 8086 and it was
> faster… running quite a few apps.
Any of the apps a full blown web browser? No did not think so.
How about an IDE in the same class as NetBeans?
Shock, no again.
There were none back then. What ‘class’ is NetBeans? (Not to mention why such a stupid name, since the answer is obvious). A 8086. The thing hasn’t even got kernel mode. It’s 16 bit. It’s 8 MHz.
There was a Smalltalk IDE. There was Mathematica.
A Java app, once running for a while, will ofton get compiled to native (ohh for .net-like keeping of pre-complied). The start up time is the killer, and with stuff like shared VMs, this will fall to a degree that the user will not notice the diffrence.
Startup time has little importance even from Joe’s POV. The issue is with latency. And latency is a nightmare. If it’s JITted, it just doesn’t look so. Though, as I said, it’s getting better.
the idea of java has taken hold, developers have embraced it. Now its time for java to perform. I expect Java to perform wonderfully and I thik most software will be using java.