Sun Microsystems today introduced Java 2 Platform Standard Edition (J2SE) 5.0, the most significant upgrade to the Java platform and programming language since its initial release nearly one decade ago.Known as Project Tiger, this updated Java platform offers dramatic ease of development, new application monitoring and management features, a dedicated focus on rich client support for the PC desktop and record-breaking performance.
Sun will launch Netbeans 4.0 Beta version in end of July 2004. According to Sun, some interesting features will be included: Profiler-functions (to check performance and memory problems), some goodies that should help developers develop J2EE and Webservices apps easier. More here and here. There is also an interesting project of Gosling called Jackpot.
Sun’s alliance with Microsoft, which was announced in April, also got a mention. McNealy outlined how the two companies plan to make their products interoperable over the coming years. “All kidding aside, I know we shocked some of you back in April with that announcement, but we are serious about working with Microsoft. The better our products work together, the better it is for all of you.”
Elsewhere, guard your castle! Claim your land! Command your knights to joust valiantly and defeat their foes. Capture the enemy’s position and seize its land while dodging its menacing knights. If writing mundane Java code is giving you the blues lately, maybe it’s time to turn your medieval fantasies into reality with CodeRuler. You can rule your own kingdom while refining your Java programming skills and mastering the Eclipse development environment all at the same time. This article provides you with the Jave tips needed to let you achieve ultimate CodeRuler kingdom domination.
Mono went 1.0. And I almost started coding in c#… Then Sun bullseyes java 1.5
. Im back, Java.
Only A hobby coder so I can jump ship all the time
.
The things mentioned were kind of interesting, but it misses one of the biggest problems with Java: its size.
The Java platform is getting way too huge. And by the way things are going, as companies keep dumping their irrelevant APIs into it, which possibly less than 1% of the people that use Java will ever use them, things will get even worst.
Java (JSE or JEE) is getting to be too big for distribution. What I’m looking for in the next version/edition of Java is to be able to choose the libraries that are found in the package. It would be great if you could download the latest version of the Java platform and then choose the libraries that you want to enable for further distribution. Thus, you take the Java distro and re-shape it for further distribution within your organization.
If I only need a few class libraries, why do I need to distribute megs and megs around? There has to be a better way!
Any ideas why they bumped Java version number from 1.4 to 5.0?
Do they want us to think that Java 5.0 is 4.54 times better/more advanced than .NET 1.1 ?
IMHO this produces nothing but confusion, and Sun is known for making simple things overly complicated (vide Java v1.0, Java v1.1, Java2 v1.2, Java2 v1.3, Java2 v1.4, Java2 v5.0).
The version numbering isn’t atypical for Sun, they went from Java 1.1 to Java2 (1.2) and from Solaris (or was it called SunOS?) 2.6 to 7.0.
Distributing Java client apps is really annoying: first you need to assure that the user has the JRE, then you need to provide all the libraries you use in your app, like xerces or log4j or whatever you need, even if another java app allready provides these, so most java apps seem to come along with the JRE and all the needed support apps, for example JBuilder comes with its own JRE, as does Oracle JDeveloper and certainly many other apps. This is just like Windows DLL-hell… I don’t know how this is solved (if it is solved) with .NET or Mono.
The version numbering isn’t atypical for Sun, they went from Java 1.1 to Java2 (1.2) and from Solaris (or was it called SunOS?) 2.6 to 7.0.
Yes, it was called SunOS.
This is just like Windows DLL-hell… I don’t know how this is solved (if it is solved) with .NET or Mono.
with .NET you don’t have DLL Hell nor anything like that. There’s no need to include Registry Info and you can even have the “same” component -different version- run side by side. If aplication version 1.0 needs library 1.0, and you release library/app 2.0, all aplication version 1.0 will stil be able to use library 1.0. Wow, what a mess.
Anyway, with .NET you still have to make sure that the “client” has .NET Runtime Environment and if you use external libraries, to follow you, log4net for example, you have to make sure the client receives that file. In contrast with COM/DCOM, you don’t have anything to do but “copy” the DLL. In .NET there’s no need to “install” an application, simply copying all the required files will do.
One thing’s for sure, you don’t have “multiple” .NET’s hanging around (apart from M$, GnuDoTNet and Mono)… well, you do..
Martin.
“Java 2 Platform, Standard Edition (J2SE) Version 5.0 (code name “Tiger”).”
And to answer those who asked “why” 5.0. Read the article, in short:
” If you’re wondering why Tiger is J2SE “5.0” instead of the traditional J2SE “1.x”, Hamilton noted that “because J2SE 5.0 is our biggest update to the platform since the original 1.0, it felt kind of stupid that we were still calling things 1.1, 1.2, … And with a big roaring Tiger, we wanted to change the numbering system, so we’re now going to use the 5.0 number for J2SE, and similarly Jave 2 Platform, Enterprise Edition (J2EE) is going to move to 5.0. Future releases will be 6.0 and 7.0.”
The fact that some product makers distribute their own copy of the JRE with their product is non-logical to me. That was one of the reasons I disliked JBuilder. Any vendor that needs to make sure the JRE is present, should give the option of detecting and using and installed JRE or use the one they provide, not force theirs with their product. I have tried Eclipse and NetBeans with the same JRE I already had, and they both work.
If you have nothing better to bitch about than the VERSION number used, then please, hold your tongue and STOP WASTING ELECTRONS.
In my opinion, talking about the VERSION number used is much better than complaining about ppl who does “b….” about Version Numbers. And since electrons are going to be wasted no matter what we do…
I love you overreaction.
M.
Java is already pretty slim. The J2SE SDK is a 33-34mb package. Just to compare to what you might be running — a *very* bare bones application execution/development environment for C on Linux would include the kernel, gcc, and binutils (mostly for ld), glibc, and maybe gdb. I just took a look at RedHat’s website. For RedHat 9, just those packages alone add up to 51mb. So, it seems like standard packages for other development platforms might actually be bigger, but they are in the same ballpark. Keep in mind the J2SE SDK contains a java compiler, VM, debugger, class-libraries, and the supporting runtime for the VM. Java’s size seems pretty proportional to other development environments out there.
The situation would improve if Sun allowed developers to ship their applications with their own customized JRE. If you strip away all the standard libraries that you don’t need, you can easily reduce the total distribution size (application + JRE) to 5Mb or even less(depending on the size of your own application classes).
Sun doesn’t even have to open-source Java for this. The only thing they would need to change in the licensing is to allow vendors to ship a custom JRE for the sole purpose of running a particular application. (Vendors should not be allowed to install a system-wide JRE.)
See also http://rejar.sourceforge.net/
You can’t count the kernel or glibc because the JVM needs those too.
I think the main point is that the C development environment usually comes with the distro. You usually don’t have to do anything at all. Even so, I think the JDK size isn’t prohibitive because most developers have the patience to download/install it.
The JRE is the tough one. It looks like the typical installation is only 7.1 MB now, but I imagine that it’s still a pain for end users.
i’ve said it before buut why does ibm do more for the java community than sun. they give away compilers (jikes), produce additional jdks, spend lots of effort poducing real contentful articles and tutorals… and programs like the mentioned CodeRuler.
shouldn;t sun be ashamed that they don’t do this? its as if sun don’t want java to be successful but ibm do.
t
well my good sir, that statement is complete crap right there. They’ve done plenty, hell, they even invented the language. Someone has to fund development.
Plus, if you are comparing open source, sun has done more than any other company. Sun has helped open source applications and etc regarding Java as well.
Smart business
this stuff runs alot smoother, faster, less resources on the server side. No idea regarding the desktop. Java has always been extremely fast on the server though, compare a Java-based search engine to a Python, PHP or ASP search engine. Especially lucene–that engine is FAST
Blame the apps, not the runtime.
A well packaged app written to be portable will work fine on any JRE, a badly packaged app will be like JBuilder.
” they give away compilers (jikes), produce additional jdks, spend lots of effort poducing real contentful articles and tutorals… and programs like the mentioned CodeRuler.”
if you ask me both companies has great and free products for java. Sun is also givin away everything about java. i do not agree that Sun is not woking or giving away stuff. If IBM has eclipse and developer articles, Sun gives away complete J2SDK, JRE, J2EE, compilers, NetBeans all free. and do not forget IBM is making much more money from java then Sun. In terms of tutorial and articles, they are probably head to head, especially java.net and java.sun.com has very neat articles, communities and of course projects. it seems like you are not following java environment lately.
This is why I LOVE Sun:
Real Enterprise tools:
>Monitoring and manageability is a key theme of the release and the platform features a new monitoring and management API. This enables tools to monitor the health of a running JVM remotely or for applications to perform self monitoring for higher levels of reliability, availability and serviceability. Also new in the J2SE 5.0 platform is the Java Management Extensions (JMX) technology, which provides a simple, standard way of managing Java resources such as applications, devices and services.
>Many areas of the rich desktop client have been enhanced including an updated, more modern, cross-platform look and feel. Support for advanced graphics hardware acceleration via the OpenGL (r) API enables higher levels of Java 2D API performance. A new Pack200 utility dramatically reduces the download size of applets and applications for faster access. Many areas of user security have been modified for simplicity and safety.
Looks like Swing is going to finally get a performance boost with the OpenGL support?
You can’t count the kernel or glibc because the JVM needs those too.
Sure I can. The fact that the Linux JVM depends upon libc is an artifact of the build process. It’s entirely possible to statically link a JVM to an alternate C-library, or whatever library you happen to have written your JVM in. The same goes for the kernel. While most JVMs provide a virtualization within the confines of an operating system, there’s nothing that says you can’t build an OS that is itself a JVM. VMware does a similar kind of virtualization with one of their high-end servers. It contains its own OS and virtualizes the hardware the way they want to. There’s nothing inherently prohibitive about the design of Java that would prevent this. (I think there’s a group of people already writing JavaOS anyway…)
But you’ve missed the point entirely. All I was trying to observe is that the size of the Java SDK is quite similar to the components required for other software development. J2EE may be horribly bloated, but I was talking about the standard J2SE. *shrug*
The situation would improve if Sun allowed developers to ship their applications with their own customized JRE. If you strip away all the standard libraries that you don’t need, you can easily reduce the total distribution size (application + JRE) to 5Mb or even less(depending on the size of your own application classes).
I think in this case it’s a matter of branding and standards-compliance more than anything else. I don’t believe there’s anything legally-binding that would prevent you from building your own JVM that takes a specialized JRE, and shipping this JRE with software you distribute. However, I do think Sun is in the right to insist that when you do something like this, you don’t get to call it Java(TM).
I’m also a bit confused by your statement, though. I don’t think vendors have to ship a JRE unless they add additional components. And even then, I think they can package them with their files. My understanding was that it is possible to compress all of your code, you being the hypothetical developer, and then ship it off to customers. As long as they have a JRE with the libraries you use, they can run the bytecode you send them. My understanding was that the shipped bytecode can contain new libraries too.
>I don’t believe there’s anything legally-binding that would prevent you from building your own JVM that takes a specialized JRE, and shipping this JRE with software you distribute.
Well, this is clearly spelled out in the JRE readme and license. There are only a few optional files that you can leave out.
My point is that you could reduce the distribution size by shipping your application with a stripped-down, minimal JRE. The average application uses only a fraction of the standard Java libraries, there’s no need to litter the user’s harddisk with libraries that are never used by the application.
Just to be clear: the custom JRE I’m talking about is visible only to the application and has no impact on any existing JRE installations.
Of course, if you install the JRE system-wide then it’s important that *all* the libraries are available.
IBM’s goal is to drive the cost of software licenses to zero, so customers have more money to spend on hardware. (If you have, say, $10000 to spend on a new server and the software licenses cost $3000, you only have $7000 left for the hardware. Now if the software is free you have $10000 to spend on the hardware.) IBM just wants to leverage Java for their goals, hence their calls to make it open-source. There’s nothing sinister about this policy, it makes perfect business sense.
In the meantime, we can pick the fruit of their labors. I think that IBM, through Eclipse and SWT, has done more for Java on the desktop than Sun has ever done with Swing.
My point is that you could reduce the distribution size by shipping your application with a stripped-down, minimal JRE. The average application uses only a fraction of the standard Java libraries, there’s no need to litter the user’s harddisk with libraries that are never used by the application.
Why would you want to do that? The more Java apps someone has on their machine, the more ‘stripped-down’ JVMs they’ll have on their machine. That may make your distribution smaller, but it’s not a good long term solution.
Instead, a good software distribution method is required. If you’re distributing software via the internet downloads, you could have two distributions, one with the VM and one without. Or better yet, have a page with an applet that says “If you can see this, you can proceed to download” and if they can’t they should get the VM from the direct link that you provide. http://www.java.com/en/download/windows_manual.jsp is a good place to start. If you distribute your software via CDROM, you shouldn’t be complaining then
IMHO, one universal VM is definitely better than many tiny customized VMs.
ok, i guess you can argue that IBM has done more for java than sun, but they don’t like the java community process and they didn’t invent the language and dont provide updates like this.
It shows there is life in the beast and please, if that’s getting to big, come and live in our century, where machines have disk space, memory and broadband access (if not yourself, someone you know).
>Why would you want to do that? The more Java apps someone has on their machine, the more ‘stripped-down’ JVMs they’ll have on their machine. That may make your distribution smaller, but it’s not a good long term solution.
The ideal solution is, of course, a system-wide JRE with all bells and whistles, we agree on that. However, most users do not have a recent JRE, so there’s an extra step involved for them to get an application to run. For technical users like the OSAlert crowd, installing the JRE is trivial, but ordinary, non-technical users are wary of installing extra run-times just to run a single application. Aside from the technical issues: the JRE requirement makes a bad impression on the user. This is why you rarely see commercial end-user applications written in Java. Yes, there are a lot of developer tools, XML editors, etc., but those are meant for a technical audience anyway.
I believe that for Java desktop applications to become competitive with native applications there must be a way to reduce the total distribution size of a single application. Hence, I advocate the *option* of shipping a customized JRE. The JRE is visible only to the application anyway, no other application can use it, and if the user already has the full JRE then there’s no need to install the custom JRE in the first place. Everyone wins in this scenario.
Amen.
Ow men!
I finally finished my J2SDK 1.4.04 + NetBeans download with 56K modem (96 MB) yesterday… Argh!
And in the next day, Sun published a newer version! LOL.
All right, here is my problems with Java…
GUI Speed: Well, I see that not is only my problem…
Swing Components: Ow men, come on! JFormattedTextField is a pain to configure! (VB’s MaskEditBox is easy!)
JDBC: Several drivers, several ways to do the same thing…
(I’m developping an app with Oracle database).
and etc, etc, etc, but, after all, Java is the best solution to create an app that have a beautiful appearence, fast connection with JDBC to Oracle Database using the Thin drivers and it’s easy to distribute (only a Jar file with any launcher! (+JRE, hehe!)
My 0,02 cents.
Michael Vinícius de Oliveira
~ BlueEyedOS.com Webmaster ~
Ow men!
I finally finished my J2SDK 1.4.04 + NetBeans download with 56K modem (96 MB) yesterday… Argh!
And in the next day, Sun published a newer version! LOL.
All right, here is my problems with Java…
GUI Speed: Well, I see that not is only my problem…
Swing Components: Ow men, come on! JFormattedTextField is a pain to configure! (VB’s MaskEditBox is easy!)
JDBC: Several drivers, several ways to do the same thing…
(I’m developping an app with Oracle database).
and etc, etc, etc, but, after all, Java is the best solution to create an app that have a beautiful appearence, fast connection with JDBC to Oracle Database using the Thin drivers and it’s easy to distribute (only a Jar file with any launcher! (+JRE, hehe!)
My 0,02 cents.
Michael Vinícius de Oliveira
~ BlueEyedOS.com Webmaster ~
The new Java is still in beta stages; they just changed the version number… it’s still not released.
If the final version is released, someone direct me to the *non-beta* download area please.