Slashdot Mirror
New Desktop Features Of Next Java
bonch writes "Sun has posted the new desktop features of the next Java, codename Mustang. Improvements to Swing look and feel, OpenGL 2D renderer performance, AWT features such as the ability to add a tray/panel icon, and improved deployment capabilities."
Here are my items that I would like to see in the next Java:
1) The ability to allocate more memory space to Java apps.
2) 64 bit support.
3) Ability to/Easier implementation of hardware specific calls to speed calculations. (e.g. Altivec acceleration).
Visit Jonesblog and say hello.
...that mustang is also the first Java version to be developed under an Open Source type model. The CVS is open to guests over on http://www.java.net, thus allowing for immediate feedback and bugfixes. It has been a real boon for the gaming community, as they've been able to direct several key performance features.
Javascript + Nintendo DSi = DSiCade
Yeah! This is really something that should be made better.
Always when I use some Swing based applications I'm remembered that the times of ugly GUI's aren't over yet.
chris
Who spilled the java in my Mustang??!
By reading this, you have given me brief control of your mind.
You would have succeeded, if only you had used the speedy next version of Java, codenamed Mustang.
Letter
Jave was too slow.
It looks like they've finally addressed this issue, but I think Sun is a little late.
.NET/Mono being around to give Sun a little kick in the rear to get moving on things.
Personally, I can deal with non-native look-n-feel, but when the fonts look like something circa 1988 on an Amiga, how can anyone take Swing seriously.
I never understood why they couldn't use platform specific code for fonts, and if not possible then go into fallback mode and paint everything themselves.
Swing has been a disaster. I believe it was the OTI guys (who now work on Eclipse and SWT) that told Sun not to go the route of "give me a handle to a brush and we'll paint everything ourselves", but some other group won that debate.
And thank god for
Screenshots!
A story about desktops carry no weight with me unless there is pretty pictures.
Get your Unix fortune now!
...the next version.
Not quite the same thing as "this is in the next version."
Loading...
You mean java is slow?
;)
Yes. Sometimes it is.
But hey! With such a codename it MUST be much faster
chris
First off, no one said it's what we need. And regardless if you or I feel there might be no need for it (I personally use it daily), there are plenty of shops out there that do.
And second, they're addressing a significant issue with Swing which is its pokyness. This is going head on with SWT , a 'feature' that Eclipse people have enjoyed for sometime. This also signifies Sun throwing in the towel on their whole Swing widget abstraction, abstraction, abstraction mantra in favor of using the native OS rendering widget facilities. This has been a major Java gripe for some time; why can't my Windows Java app look like a Windows app and why does it have to be do damned slow?!
Should be interesting to see how these features/additions play out. Also, looks like Swing apps are finally getting native aa font support. This will please many as the text rendering in Java apps is still in the Windwos 2k/GTK 1.x days..
I think that there is a Layout for positioning with exact coordinates. Either that or you can use a Java IDE.
However, the more common GridLayout, BorderLayout and FlowLayout can all be used to make perfectly acceptable GUIs, it just takes a bit of practice. The main advantage with it is that it allows your windows to be a range of different sizes without repositioning anything, and is less likely to screw up when you change look and feel.
GTK has very similar layouts to Java as well.
Java must embrace SWT and start doing GUIs in a fast, portable, native way. SWING is slow, redundant and ugly. IBM knows the right way, SUN should follow them or surrender to .NET (both windows and mono have NATIVE widgets stuff).
You don't have to use a layout manager. You can easily call setLayoutManager(null), and then use coords to place everything in the frame.
but I like to position the elements where I want them, and not how some layout manager feeld they will will go best.
Thing is that "some layout manager" will know about the different conventions used for different human languages when it comes time to localize your software. Pixel layout is dead because different languages use different numbers of letters to spell the same thing. And in Israel and the Arab world, text in the local languages reads from right to left.
I'm no Java fanboi, but these are some the classical advantages of Java over other languages:
There are others, but these are the ones that immediately come to mind for me.
I'm a C++ coder myself, but I do appreciate Java's value for certain situations.
cp /dev/zero ~/signature.txt
I've been on the java.net site.>/a>
.net suffix is either coincidence or very ironic.
Its a good mix of Sun developers and java users. I'm thinking of jumping back into java and been poking around that site to see what is new.
Its not all netbean either, Eclipse is giving good billing to.
The
And how long did it take BASIC to get this?
When is it coming out for FORTRAN and COBOL?
10 years is still young as far as languages go.
Why, oh why, didn't I take the Blue Pill?
It would help if GridBagLayout actually worked as advertised...
For example, is there any way to have a double-height cell at the end of a row, and start on the next (single) row, and not have to resort to statically numbering everything?
BoxLayout is good for simple stuff but not when you need to have things line up both horizontally and vertically.
as soon as I find out something's written in Java I can immediately ignore it
Then which web games do you play? Do you really want to use ActiveX to load web games written in native Win32 code when ActiveX lacks the sandbox capability of the Java platform?
64-bit Java VMs have been available for SPARC64, PPC64, and AMD64 for ages.
Those all sound like very good enhancements. I would get rid of the crappy "Ocean" theme for the default. It's really no better than the much hated Metal. It sounds like they have worked to get the native look and feel much improved, but I would still like to see a *much* nicer default since it seems like that's what so many developers end up using.
The other thing is major Java Web Start improvements. I've tried to use it and it sucks majorly. Basically you end up having two different versions of your application, one that works with WS and one that works as a native application, which stinks from a QA perspective. Furthermore, while I know there are major security considerations when clicking on a program from the web, something has to be done about the dialog boxes. My own parents wouldn't run the application I wrote because it said "it is strongly recommended not to run this program". Then, there are all sorts of other weird dialogs like "would you like to enable desktop integration" that never works, and also sometimes gets put behind the application so you can't see it while it's still modal.
Otherwise, they REALLY REALLY need to get a better browser component. Here's what I suggest:
http://jrex.mozdev.org.
Make this a part of the standard JRE! *It will be the most significant and best single thing that ever could have been done to java*. Imagine having a gecko rendering engine whose DOM is fully controllable from Java on every major platform that the JRE supports! Imagine being able to use a gecko widget inside any GUI com\ponent! That would be how to step up and really innovate.
Finally, provide better desktop integration. Interact with the system tray. Allow "always on top" behavior. Include proper fonts (which it sounds like they're doing).
All in all, though, it sounds like there are some definite improvements, but they need to leap frog, not just catch up. Taking the JREX.MOZDEV.ORG concept and running with it is just how to do it.
Where possible, we will add pointers
Wow, the beginning of that sentence sure scared the hell out of me. In my opinion, asterisks should be for multiplication only.
I concur, Java pretty much missed the boat for desktop apps. Not that I mind - I hate how they refuse to adopt native widgets, instead pushing their own cheap imitations that lack all the keyboard shortcuts, font anti-aliasing, and solid feel that native widgets have. Most stuff doesn't use SWT, either. Between the horrid UI and a language that loves to hamstring the programmer, I have to say good riddance.
To my suprise and delight, it was incredibly easy to do... and I've done many custom layout managers since. They are about the same level of difficulty as some of the one-off scripts unix sysadmins might develop to automate a particular job that needs doing.
File under 'M' for 'Manic ranting'
Abstract Windowing Toolkit. Really, is google so hard?
Here's some info.
My UID is the product of 2 primes.
Simple really-- some programmers are lazy. They can't be bothered with optimizing their code for individual platforms.
Or they don't have the time to write something for multiple platforms. Time-to-market is directly tied to your ROI..
Why would I pay a programmer $1 an hour to code something for 10 hours on three different platforms, when I can pay him $1 an hour to code something once? Especially if I'm going to sell just as many copies for the same exact price in either scenerio -- the java route increases my return.
I'm very excited with all the improvments Java is going through, but I'd hate to see it all being completely missed by the general public and web application developers if Microsoft won't include the JRE and Java Plug-in in Longhorn.
Anyone knows what going on with this issue?
Exactly. So why is Sun dragging its feet on porting its virtual machine for the Java language to the AMD64 platform?
What are you talking about?!? Go to http://java.sun.com and click on "J2SE 5.0". Then click on "JDK 5.0 Update 2" and accept the license agreement. Right there are four packages for AMD64. (Two for Linux, two for Solaris.)
Stop spreading FUD.
Javascript + Nintendo DSi = DSiCade
But I can count the number of .net desktop apps I know on 1 finger!
Simple really-- some programmers are lazy. They can't be bothered with optimizing their code for individual platforms
Sorry, but that's a pretty ignorant attitude. Judging an application soley on being java-based is a poor method. Rather, you should ask if the developing language is appropriate for the task. If someone told me they wrote a graphically intense FPS in java I would be suspicious. But, if the app only needs to be light and portable java may be a good choice. It allows for very easy control of how the application looks on multiple operating systems. A good example of a nice-looking java app with no speed issues is Limewire. It runs quickly, works well and can be updated more efficiently than if they had used a graphical toolkit for python or C. Not that anything is wrong with chosing python or C either. It entirely depends on your application requirements and development resources. Brushing off all apps written for the JVM (or any development kit) will cause you to miss out on a good app sometime.
First, it seems like KDE/Qt has more momentum than GTK on the desktop. Qt apps look better and are more integrated with eachother. Suse is the dominant desktop Linux distro and Suse is KDE-oriented. I'm glad that Java is going to be using native GTK for rendering, but what I would really like to see is native Qt. Maybe they could create some kind of interface to make it easier to plug in different rendering systems? Maybe they could open source Java and let the community take care of it? Maybe they don't care because desktop Linux is only about 5% of the market anyway? But still, it's something I would like to see.
The second thing they need is a "SwingLite", or some easier way to do common things. For example, it is very common to need a text field that allows the user to enter a number, but not text. Should be easy, right? This is the code I have to use to do it:
That's just wrong. I should be able to say:or maybe:The above example, involving two different factory classes to just get the field to accept integers only, puts a high burden of knowledge on the programmer, and Swing is full of stuff like that. It's great that the power is there because I can write my own hierarchy of text formatting factories and objects that enforces correctly-entered Sandhi rules, but that doesn't come up very often, and what does come up very often is having to enter a plain old number, date, currency value, that kind of thing. And I'm just using this one example, but this kind of over-design is all over the place in Swing.The final problem that they have is putting emphasis on plugable look and feel. Application developers shouldn't get to decide the look and feel of their apps. That should be determined by the desktop environment. Pluggable look and feel is not a feature; it is a bug. It should be deprecated and removed.
----------
Educational software
I use many java desktop apps in my day to day tasks on my linux desktop. There is no better way to connect to multiple databases than Squirrel , No better way to code in Java than NetBeans and no better editor than JEdit
I think Java 5 already has great desktop features like shared class data, and 2D acceleration for 2D acelerated hardware (which I don't have yet!).
It's ALMOST as fast (and in many cases just as fast) as C code. Additionally, it compiles much faster than C, though C binaries make up for it with substantially shorter load times (Java has been improving in this regard recently, however).
Incredible, does this crap ever end. No, its not even in the same universe as C when it comes to performance. I can't name ONE Java application that doesn't suck utter arse when it comes to responsiveness. The much touted server peformance is also awful but is easier to hide behind mammoth hardware specs. Embedded Java -- slooowww. Seriously, put any Java application next to a C application and see the truth.
I just checked out the latest build release of Mustang, Swing at least on Win32 seemed again snappier, the absence of the gray rectangle problem really made a huge difference, the guy now is faster on Windows (tested it on SwingSet2 and JEdit) than Firefoxs is.
But there still were minor annoyances in the Windows look and feel, mainly, the menus still are different to those done by windows (XP does dropshadows and transparency while being opened, Swing is flat) The file open dialog still has layouting differences, but besides that things start to look very good and fast. Cannot speak for Linux however and the Mac has yet to get a 1.5 release.
Actually Sun is not throwing in the towel, Swing has done an interesting approach no other Widget set has done so far. They basically went the way, of rendering the widgets still in software, but the underlying graphics layer is hardware accelerated if possible and the rendering data for the skins is directly parsed from the underlying OS skinning engine if present.
And Swing has gotten much faster that way. Swing has been already more than usable in 1.4 and I recently checked the latest 1.6/6.0 builds, and all I can say is wohaaa... The guy in 1.6 at least on Windows is very snappy. I have had running Firefox and SwingSet2 running side by side and SwingSet2 blew firefox away rendering speedwise.
I wonder why they aren't having an XUL/XAML implementation?
I don't want my java apps looking like windows apps. I want them as responsive. I like the ability to change look and feel. I just wish laying out the gui was easier and classes like swingworker (or the foxtrot stuff) was built in and more transparent.
It can be done, and it is done by those doing Swing work effectively. With tools like JFormDesigner, you can just create resources that are loaded in real time by your swing app. Add a binding framework, and building GUIs in Java becomes as easy as making GUIs in pretty much any other language.
JSP sucks. Check out Velocity at the very least.
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
and suggest Eclipse or IntelliJ as a better java IDE.
"Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
Why would I pay a programmer $1 an hour to code something for 10 hours on three different platforms, when I can pay him $1 an hour to code something once?
Because you'll end up coding 10 times anyway, at least according to John Carmack.
But then again, what the hell does he know, right?
Is stability, security, and more speed. OOo 2 beta is SLOW and most issues i have with it are Java related in some way.
I am Spartacus
Use Microsoft's API for rendering portions of components (5106661).
and
Use GTK API for rendering portions of components (6185456). After fixing 6185456 Swing components will use GTK's rendering engine...
ROTFL. After years of Swing fanboys bashing IBM for daring using native OS rendering for UI widgets in their SWT toolkit (in contrast with Swings alleged the-only-right-and-holy-way of drawing everything in Java in name of "Java purity"), they seem to have finally gave up the futile attempts to imitate native OS and Swing will now delegate part of its rendering to the *gasp* _native_ rendering engines. I really wonder how can it be noone in the Swing camp cries desecration... :-)
Sig erased via substitution of an identical one.
If i could pay a programer 1 USD an hour , i would be a very rich man , either that or in jail for slave labour.
The only things certain in war are Propaganda and Death. You can never be sure which is which though
You have never written a large multi-platform piece of software, have you? Learn to code something a bit more complex than Hello World before you call other people slackers for not going through the hell that is making a piece of software written in C/C++ work on multiple platforms, all from the same source.
No, in fact, I have been doing multi-platform development for around 20 years now, including client server, three tier, networked database and web applications. How much hell the programmers go through is not the issue-- it's a programmer's job to program, and if that's hell for you perhaps you should look for another job.
1. You have obviously never written a line of code.
2. The Java programmers of this planet would like to thank you for becoming one of their users.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
> all instances of a page are sharing the same object, which is very frustrating and anoying after having done it the other way.
What are you talking about ? Two instances of a JSP don't share objects. They are both different instances of the jsp servlet class.
Oh, I can't help quoting you because everything that you said rings true
Why would I pay a programmer $1 an hour to code something for 10 hours on three different platforms, when I can pay him $1 an hour to code something once? Especially if I'm going to sell just as many copies for the same exact price in either scenerio -- the java route increases my return.
Exactly. But now think like a customer. Why would you buy a Mac and not a PC if you just wanted to run generic programs? Aren't you interested in looking for those programs out there that take specific advantage of your hardware investment? What is it about the best Mac programs that make you buy a Mac in the first place? As a customer, what do you care how hard it is to write code? Sure, you care how much it costs, but you may very well be willing to pay more for software that's better integrated with your platform. When I'm a customer and not a developer, that's the sort of customer I am. Consequently, if it's written in Java, I look elsewhere...
"Dear China,
I am inexperienced with the Chinese language. I am having difficulty learning it because I find it ridiculously complicated. Please simplify it.
Signed,
VolciMaster"
As for the layout managers, you just need practice with them. My suggestion is to stick with BorderLayout, FlowLayout, and BoxLayout (with some widgets from the Box class). You can easily nest panels using those layout managers to get what you want, 99% of the time.
Do you know what frustrates me about Windows development (using C++ Builder)? Absolute positioning. I place things where I want them, run the app, resize the window, and nothing moves! Only the window gets bigger. Once you get the hang of layout managers you'll see how easy they are to use and how much nicer your UIs will be.
You don't have to use a layout manager. You can easily call setLayoutManager(null), and then use coords to place everything in the frame
Just what I was going to say.
That guy has obviously less than 1 hour experience with swing, and he is making outrageous claims like you cant position things where you want to.
[I can picture a world without war, without hate. I can picture us attacking that world, because they'd never expect it]
If i could pay a programer 1 USD an hour , i would be a very rich man , either that or in jail for slave labour. That or you would be a major US corporation outsourcing to India or Russia.
`fortune -o`
On Linux, I use muine and tomboy regularly. F-Spot is one of the best rated apps on gnomefiles. I can't think of a single java desktop app for Linux...
-Mark
On the other hand, while text mode apps can run on many platforms, there are c compilers on even more platforms. Well written C will port much more easily to those platforms. And GUIs just look wierd when you try to run them on a different platform than you wrote them on.
On the other hand, for many practical applications, java will turn out to be much slower than C. Particularly if your work relies on the performance of two key areas: 1) you write code that does a lot of interesting array access, in which case the lifters and such in the optimizer will fail you and you'll do 3 ops in java to every one in C when you access your array. 2) you copy application data from/to disk or over a network, an extra copy is required to move the data into an object's memory, and this cannot be done in bulk either.
On compilation, I don't know what planet you're working on, none of the java compilers hold a candle to the C compilers, but really, who cares about compile time, run time is what matters, and there indeed you get the joy of slow java startup.
Also, the java compiler has no support for conditional compilation, which hampers debugging support (and lots of other nice bonuses you get with a precompiler).
On the other hand, most large scale apps still wind up having to track down this sort of problem, and auto_ptr can solve this for you on C if you want.
On the other hand, C apps can run in a web browser too, but granted, support is not as widely deployed by default.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Or Tapestry.
SYS 49152
Check out dbvis or Azureus before you talk down to java apps. Java makes networking and database code a lot easer to write which realy shines though on these apps.
From what I hear Azureus is about as fast as any C++ BT client but it adds a good UI and a lot more features than the av BT client.
As to dbvis I have been using it for a while at work and the free vertion works great. Now you want to show me a free / cheep C++ app that does the same things on OS X I will look into it untill then I am going to stick with dbvis.
Hmnnn, perhaps I'm missing something but that's not the way I understood it. Here is a page that I think backs up my original statement:
e /j sp_declarations.htm
http://www.imagescript.com/atg/articles/jsp_j2e
each web server thread calls on the _jspService method but the servlet behind the JSP page is made only once. If you add your own functions and variables outside of the scope of the _jspService method all that stuff seems to get shared between threads running on your web server.
Blender And Linux Fan
Look at JSF. I think it rocks.
.NET apps to run on anything except Windows. Heck good luck getting them to run on anything but the latest version of Windows with all the latest patches. Now if that isn't a concern and you don't mind all the limitations Windows AND not being tied to one vendor, then .NET may be cool. Heck if you don't mind being locked in to one vendor there are a lot of cool tools out there.
Good luck getting
The more I learn about science, the more my faith in God increases.
The AMD64 editions still does not provide a browser plug-in. Luckily, there is Blackdown.
Wow... you guys wasted no time bringing out the flamethrowers. ;-)
I'm not advocating Java, but the parent asked what it's good for, so I gave the most commonly cited advantages.
I still prefer C++ myself, unless I don't care about performance or need some specific feature of Java that I don't feel like implementing/obtaining myself.
cp /dev/zero ~/signature.txt
I had to stop using it because it crashed too often. It is there, but kinda flakey (all crash logs have been reported to sun)
Azureus ... and those are just three that I use -daily-.
Eclipse
JEdit
Why can't it all be XML based where you just design your GUI elements in document form and load it in.
That is one suggestion which needs to be sent to the team working on the new Java. This would make things sensible. It would be even better if they used an XML syntax similar to Mozilla's XUL or even the stuff WxWidgets uses - this would (hopefully) make porting a breeze.
You just posted to slashdot that you use IE... nevermind that you also prefer a 10-year-old JVM. Maybe it's just me, but highly I recommend learning something new instead of praying "JCobol" will stretch out your IT career until retirement.
About time they started thinking about the desktop. Java rules the server, why not the client?
Making a project take much longer to implement and take literally twice as long to test really isn't a sensible option when you are paying people by the hour.
Java is not the panacea your argument here is claiming it is. Testing may take a bit longer, but that's not necessarily a bad thing-- some things get tested better on one platform than another and you find things you might not otherwise. And coding doesn't necessarily take much longer to implement if you are familiar with the variations in the target platforms. Sure, I've seen a lot of *bad* attempts at multi-platform code, look for *platform* specific #ifdefs spread throughout for example, rather than *feature* specific ifdefs that are selectively defined for each platform. That sort of thing can be hell when the programmers don't know what they are doing, or if you've inherited it from some who didn't. But make no mistake, Java has its own unique set of issues that cause their fair share of problems.
Ultimately, the customer doesn't really care what it's written in, other than the fact that he's "heard" things good or bad about one language or another. I've never heard someone react to the fact that something was written in C as if it was a bad thing though, usually the contrary (most customers are ignorant of it's propensity for buffer overflows and wayward pointers). I have heard negative reactions from customers for a lot of other languages though.
If you can't afford programmers who know about coding in multi-platform environments, then Java might well be a good bet for you-- but that's not a good argument to relay to the customer as to why they should buy it...
In many ways, Linux takes better advantage of x86 architecture than Windows does. Linux is written multi-platform in the way I'm arguing makes sense, not by emulating a virtual machine on every platform, but by optionally taking advantage of the specialties of every platform. Otherwise, all Linux installations would be compiled strictly for the 386. And the ways that Linux comes up short on the x86 platform, it's due to either lack of hardware drivers which is a short-term problem (hopefully) OR the overhead "one-size-fits-all platform independent" solutions such as X which is also a short-term problem (see directFB.org for an example). I dual boot Linux/PC at home, Linux anytime I want to surf the web because its more secure, and PC when I want to run games or other graphics intensive programs. I create (boot) the platform I want for the job I'm trying to do. I have little interest in emulations such as Wine to do that, rebooting is not a big problem for me. Eventually I do hope to be able to stick with one environment, but it's just not a big deal in the meantime. I'm not interested in "networked" games though, if I was I'd have to do something else.
It seems to me that product managers have long concluded that programming is hard, or expensive, or otherwise prohibitive and they want to do less of it. We don't have time or money or expertise to do it right, so we have to find some kind of shortcut. And that sells lots of things-- fad methodologies, magic tools, outsourcing, all sorts of software snake-oil. The problem is however, that there's no free lunch. Each of these alternatives have their own set of complications. I choose to pick those that optimize the results, not the process.
...and nobody bloody cares or remembers.
SwingWT is a FREE implementation of the Swing APIs on top of SWT so you get all the juicy nativeness of SWT and all of the nice APIness of Swing.
What are you talking about?!? Go to http://java.sun.com and click on "J2SE 5.0". Then click on "JDK 5.0 Update 2" and accept the license agreement. Right there are four packages for AMD64
Sadly, there is no 1.4 version, which is the one i need/want. Only for the dead IA64 platform
Open Source Java Web Forum with LDAP authentication
I know about the old Slashdot joke about BSD dying but I think Sun should release a distribution of Java for BSD. BSD's can make great servers and Java on that platform could open the way for many enterprise solutions.
What's wrong with 1.5? It should be fully compatible with 1.4. Just make sure you're looking in the 1.4 JavaDocs. Also, you may need to add "-target 1.4 -source 1.4" to the javac parameters.
Javascript + Nintendo DSi = DSiCade
If you add your own functions and variables outside of the scope of the _jspService method that is stateful, it sounds like the application architecture is fundementally flawed.
The JSP/Servlet paradigm was always intended to be transitive and stateless, thus forcing (as much as possible) applications into a tiered MVC-like architecture. If you are trying to put stateful information in your JSPs or Servlets, then you need to take a hard look at your architecture and consider redesign/refactoring.
The
Not that I mind - I hate how they refuse to adopt native widgets, instead pushing their own cheap imitations that lack all the keyboard shortcuts, font anti-aliasing, and solid feel that native widgets have
Swing can have any keyboard shortcuts you like. Also, in Java 5.0, you can globally turn on antialiasing of all fonts in an application.
Swing can have a solid feel, as it can have any feel you like! There are a huge range of looks and feels.
I have to say good riddance.
You can say what you like, but Java use is growing, and has already overtaken C++ use in most job indicators.
Because:
*1.4 works fine.
*Mac version is 1.4
*No java plugin on 1.5 for amd64
*Eclipse's stable version needs 1.4
*Java 1.5 sucks, because of bad implementations of stuff like generics. See here for info.
Open Source Java Web Forum with LDAP authentication
How about Flash?
Games using Java technology can be made in J2SDK, which costs $0 (royalty-free proprietary software). Games using ActiveX technology can be made in MinGW, which costs $0 (free software). In both cases, the Eclipse IDE is free software. Flash games, on the other hand, are made only in Macromedia Flash, which costs well over what I can afford.
In addition, doesn't using Java technology let nearly the same codebase run on J2SE web browsers and J2ME phones?
Of course, it's still better to not fix stuff that ain't broke.
Everything I've written has had no reason to be localized.
Yet. Are you planning for when some foreign company wants to publish your program in another country and possibly pay you for the i18n work underlying its L10n job?
Remember when everything was written in assembler? Was it "lazy" to code in C? While it would be nice to optimize the results, you have to remember that if you have more time, you can spend it debugging or adding new features - thus optimizing the process can lead to optimizing the results.
As usual, it's a tradeoff. C was a pretty good tradeoff against assembler in most cases, it is practically a generic assembler itself-- handling data at pretty much the same level, mainly just the "instruction set" is hardware independent, not so much the data. A good C programmer will generally have a pretty good idea what the equivalent machine instructions are for a given line of C code.
C++ however, somewhat less so. Many of those object oriented features move the programmer further away from the sense of what is happening with the hardware. Layers are hidden, encapsulated, etc., but bugs and performance problems can be as well. It may be a reasonable tradeoff, but there is some penalty you are paying.
When on top of that, you further add virtual machine emulation, you've completely removed the programmer from any sense of what is going on at the level of the hardware. If that's good enough for you, fine, but as long as there are available alternatives that aren't carrying around that kind of lets-make-it-playskool-for-the-programmer baggage, the only thing that is going to convince me is a Java "killer app." While Azureus may be a good performer (I wouldn't know, I've had virtually no need to bittorrent at all so far), it's not a "killer app" as there's nothing about it that Java can do better than an alternative. A true Java "killer app" would have to be one where if it wasn't written in Java or an equivalently architectured environment, it would necessarily not perform as well, AND be something that almost noone will want to do without once it's created. Until then, it'll always be second-fiddle to something with fewer layers between the language and unique hardware features.
Java may evolve to where very little of a Java program is actually written in Java-- the Java code becomes merely interface logic that calls "libraries" or "drivers" that handle the platform dependent capabilities. But then in fact, while the interface logic is "run anywhere," who cares as it's pretty trivial, and useless if you don't have the relevant libraries and drivers for a candidate platform...
*1.4 works fine.
I thought you just said that 1.4 doesn't work on AMD64?
*Mac version is 1.4
So?
*No java plugin on 1.5 for amd64
But how does not using 1.5 fix that?
*Eclipse's stable version needs 1.4
It should work just fine with 1.5. The 1.4 source level means that the IDE is setup to work with the 1.4 language features and that it won't support stuff like Generics.
*Java 1.5 sucks, because of bad implementations of stuff like generics. See here for info.
So ignore it.
You seem to be under the impression that 1.5 is incompatible with 1.4. Nothing could be farther from the truth.
Javascript + Nintendo DSi = DSiCade
What I would like to see is a reduced memory footprint for Java. Using up 40MB for a tiny applet, application or servlet is a pain. CDS, Class Data Sharing, is close but you have to use the old-school garbage collector and the client VM. See http://java.sun.com/j2se/1.5.0/docs/guide/vm/class -data-sharing.html for the poop.
Please show me I am wrong.
According to the GridBagLayout documentation, it sounds like you should set the constraints on cell 'E' to gridheight=2 and gridwidth=REMAINDER. However, when doing this, the "next" cell starts _UNDER_ 'E'. So there's a blank line, everything gets shifted down, and 'F' starts where 'H' should be.
The only workaround I've found is to manually set gridx and gridy coordinates on every cell, which makes changing the layout later a royal pain.
From your link: I haven't used it a lot myself, thankfully, but to me it seems too complicated
Wow, now that's going to be some really valuable criticisim.
I thought you just said that 1.4 doesn't work on AMD64?
No, i said there was no amd64 port of 1.4. I am using 32 bit 1.4 for development.
I also use mac, and guess what, i want to use the same version on all my boxes
You seem to be under the impression that 1.5 is incompatible with 1.4. Nothing could be farther from the truth.
No i am not. I don't need 1.5 right now, so why upgrade?
Open Source Java Web Forum with LDAP authentication
(Sun's 1.5 for AMD64 is based on that.)
Really? That is interesting. On all benchmarks i have seen, blackdown is the slowest of all JVM's. I guess the amd port should be good if Sun used it, or otherwise they just wanted to get any version amd64 compatible. I have always stayed far away from blackdown because of this, but really haven't tested it with servlet development, which is what i currently use.
Open Source Java Web Forum with LDAP authentication
Only reason Swing runs without a companion distribution is that the required DLL's for Swing are part of the Java download for Windows, Mac, etc.
OK, so Swing is "lightweight" in that most of it is done in Java, but there still has to be a link to the native OS at some level.
If you have a benchmark that compares the two VMs in a similar setup (e.g. Blackdown 1.4.2 HotSpot Client VM vs. Sun 1.4.2 HotSpot Client VM on the same machine) and Blackdown loses, then please mail me a link.
Our tests say, that our version is always at least as fast as Sun's version. For some things (e.g. Java2D operations) our VM is noticeably faster.
(Note that the AMD64 HotSpot VM has no Client mode. So if you compare it to the x86 version, make sure you enable Server mode for the x86 version too.)
It's faster than the 32-bit x86 VM on the same machine in almost all benchmarks.If you have a benchmark that compares the two VMs in a similar setup (e.g. Blackdown 1.4.2 HotSpot Client VM vs. Sun 1.4.2 HotSpot Client VM on the same machine) and Blackdown loses, then please mail me a link.
:) How about publishing those benchmarks? Or would that break a NDA or something?
You are right, the benchmarks i saw are old. I don't really understand what the blackdown project is about, since other than having ports (the most useful would be the ppc port since java on mac linux is only done otherwise by ibm). The most recent java benchmark i have seen is here yet they don't address blackdown (but it says it was evaluated)
You guys need more marketing
Open Source Java Web Forum with LDAP authentication
That would allow me to work fulltime on the ppc port. For some, yes. For others I'll put some results on our site after the next release.
Built in USB and HID support would be nice!
Is it being prepared to do the right thing, whatever the cost. Isn't that what makes a man? That and a pair of testicles
OK, I haven't checked lately (right now, I'm on a dial-up machine, so I'm not going to do anything extreme, like check facts before I post), but when I got an AMD-64 computer, and downloaded both the 1.4.? SDK and JRE, *NEITHER* of them had a browser plugin. No documentation, no excuses, it just wasn't there.
The 32-bit plugin (as well as Flash's 32-bit plugin) don't work with 64-bit Mozilla or Firefox, so I have a separate 32-bit Firefox executable, that I use for java and flash sites. It runs noticeably slower than the same app compiled for AMD-64 though.
If v1.4.2 for Linux, on AMD-64 has browser plugins, that would be welcome news to me.
Why the fixation on the browser plugin? It's not a very useful thing to have. Core Java support is far more important for running applications and servers.
:-)
If you really need the plugin, then you need to go to the development branch. i.e. Blackdown.
Javascript + Nintendo DSi = DSiCade
Since Swing is much larger and more complicated than SWT/JFace this cannot technically be accomplished for REAL LIFE Swing applications. The reverse however is possible there is a partial SWT implementation running on Swing....
Features such as full component based renderers/editors with truely decoupled models just can't be accomplished natively.
Dear VolciMaster, We already did. Signed, China
Help poke pirates in the eyepatch, arr.
Of course it can have all the keyboard shortcuts you want. The problem is, it doesn't completely conform to the platform it is running on -- it just tries to do a 'good enough' job. For example, focus behavior in a file selector dialog is mostly correct in Java 1.5 - but it isn't completely the same as the native Win32 dialog.
The problem is it inflicts the fact that it is its own 'platform' on us, the users. I want a program that behaves like all my other programs, not does its own thing because marketing idiots have an agenda to push. If I wanted cheap-feeling, half-assed GUIs I'd use KDE.
You just posted to slashdot that you use IE... nevermind that you also prefer a 10-year-old JVM
Yeah, I'm sure he feels the need to fit in with Slashbot groupthink.