The official beta 1 of the J2SE 1.5 (Tiger) release is now available for download, as is the public review draft of the Tiger Release Contents specification (JSR 176). J2SE 1.5 is scheduled to be released in the Summer of 2004; the spec defines what features (out of a long list of high, medium and low priority) will be included in the summer release.
Links:
JDK 1.5 BETA 1 SDK Download.
JDK 1.5 Home page.
Specification Public Review Draft Download.
JSR 176 Homepage.
The spec includes a significant number of "target of opportunity" features, which the group hopes to get into the summer release if there is time. Some of notable ones for enterprise developers include:
-Add a method to generate a UUID (Universal Unique Identifier)
-support using dynamic proxies as RMI stubs
-Support for standard LDAP controls
-API to test reachability of a host
-Improve Security Access and Control
-HTTP client: Improve cookie support
-HTTP client: Improve proxy server configuration and
Which would you definitly like to see?
-
JDK 1.5 Beta and Public Review Specification is out (47 messages)
- Posted by: Floyd Marinescu
- Posted on: February 04 2004 21:21 EST
Threaded Messages (47)
- How about quick adoption? by Clinton Begin on February 05 2004 01:55 EST
- How about quick adoption? by Mileta Cekovic on February 05 2004 05:31 EST
- Summary of new language features by Wille Faler on February 05 2004 06:16 EST
-
Summary of new language features by Vincent Brabant on February 05 2004 08:03 EST
- Nice PDF by tyler durden on February 05 2004 08:34 EST
- Cool! by Test Dummy on February 09 2004 03:16 EST
- Code samples highlighting the new features. by Vasanth Dharmaraj on February 05 2004 08:20 EST
- Summary of new language features by alf garnet on February 05 2004 08:26 EST
-
Summary of new language features by Vincent Brabant on February 05 2004 08:03 EST
- How about quick adoption? by han theman on February 05 2004 09:44 EST
-
How about quick adoption? by Marcus Brito on February 05 2004 09:57 EST
- xdoclet and JSR 175 by Paul Cantrell on February 05 2004 01:24 EST
-
How about quick adoption? by Marcus Brito on February 05 2004 09:57 EST
- Tasty, but it's going to be awhile by Will Hartung on February 05 2004 14:01 EST
- What about JDO by Ruslan Zenin on February 05 2004 03:45 EST
- Imroved usability on the client side. by Sergei Batiuk on February 05 2004 03:56 EST
- JDK 1.5 Beta and Public Review Specification is out by Nipsu on February 05 2004 04:25 EST
- Improve (or replace) standard Swing Look-and-Feels by Sergei Batiuk on February 05 2004 04:47 EST
- Improve (or replace) standard Swing Look-and-Feels by Bill Willis on February 05 2004 08:15 EST
- Improve (or replace) standard Swing Look-and-Feels by Sergei Batiuk on February 05 2004 09:02 EST
- Swing Look-and-Feels by William Louth on February 05 2004 09:11 EST
- Improve (or replace) standard Swing Look-and-Feels by Bill Willis on February 05 2004 08:15 EST
- JDK 1.5 Beta and Public Review Specification is out by Nipsu on February 05 2004 05:17 EST
- Generics by Billy Newport on February 05 2004 05:45 EST
- 1.5 by atus3 . on February 05 2004 06:09 EST
- RE: Generics by Jason Gerard on February 05 2004 10:02 EST
- How about versioning Java3 by Karl Banke on February 05 2004 08:57 EST
- A Quantum Leap by Darryl Stoflet on February 05 2004 09:24 EST
- A Quantum Leap by Brian Miller on February 05 2004 14:06 EST
- swing or swt? by dav kh on February 05 2004 09:28 EST
- swing or swt? by Horia Muntean on February 05 2004 11:19 EST
- OpenGL, swing or swt? by Brian Miller on February 05 2004 04:01 EST
- swing or swt? by Horia Muntean on February 05 2004 11:19 EST
- No Compiler API? by Ryan Rhodes on February 05 2004 09:49 EST
- 1.5 and Mac OS X? by Paul Cantrell on February 05 2004 13:12 EST
- Correcting my own typo by Paul Cantrell on February 05 2004 13:14 EST
- Why not static printf and println by Ziyu Huang on February 05 2004 13:29 EST
- java.util.logging enhancements? by Sean Sullivan on February 05 2004 14:45 EST
- java.util.logging enhancements? by Herve Tchepannou on February 05 2004 15:16 EST
- java.util.logging enhancements? by Nipsu on February 05 2004 07:17 EST
- java.util.logging enhancements? by Herve Tchepannou on February 05 2004 15:16 EST
- JDK 1.5 Beta and Public Review Specification is out by Mike Wu on February 05 2004 15:07 EST
- JDK 1.5 Beta and Public Review Specification is out by Jim Sculley on February 05 2004 16:23 EST
- Its getting too complicated by Malcolm Edgar on February 05 2004 18:53 EST
- This Rocks by Mike Zatko on February 05 2004 23:23 EST
- typedefs by Valentin Sliouniaev on February 06 2004 07:43 EST
- typedefs by Dmitriy Kiriy on February 09 2004 03:38 EST
- JDK 1.5 Beta and Public Review Specification is out by Smythe on February 06 2004 10:55 EST
- JDK 1.5 Beta and Public Review Specification is out by Dmitriy Kiriy on February 09 2004 03:45 EST
- Auto update of JRE? by Martin Bromley on February 18 2004 05:18 EST
- Live code examples for JDK 1.5 by Michael Slinn on February 25 2004 13:06 EST
-
How about quick adoption?[ Go to top ]
- Posted by: Clinton Begin
- Posted on: February 05 2004 01:55 EST
- in response to Floyd Marinescu
Which would you definitly like to see?
What I would like to see is a quick adoption of the 1.5 platform. These changes are great and quite significant, but they will be completely wasted if they aren't used by _EVERYBODY_ as soon as possible (post beta of course).
Seriously, we can't even code to JDK 1.4 safely yet due to a lack of adoption by key industry players and tons of major corporate customers. It's been 2 years! I don't want to wait until 2006/2007 before I can use JDK 1.5 with any confidence.
I appreciate the usual concerns...cost, stability, blah blah (okay, maybe I don't). Perhaps JDK 1.4 wasn't worth it, but I think this one will be.
LET'S UPGRADE PEOPLE! :-)
Cheers,
Clinton -
How about quick adoption?[ Go to top ]
- Posted by: Mileta Cekovic
- Posted on: February 05 2004 05:31 EST
- in response to Clinton Begin
This is realy a great set of features!
We can only hope that stability and performance would be as great as features and that stability and performance improvements would retain the same level as from 1.2 to 1.3 and from 1.3 to 1.4.
>> Perhaps JDK 1.4 wasn't worth it.
JDK 1.4 is certanly worth it, if not for anything else, then for performance of JDK 1.4.2
Mileta -
Summary of new language features[ Go to top ]
- Posted by: Wille Faler
- Posted on: February 05 2004 06:16 EST
- in response to Clinton Begin
Does anybody know of a good summary with examples of the new language features?
The JSR:s are a bit "wordy", having 90 pages to describe stuff that someone else could probably summarize (better) in a couple of pages... -
Summary of new language features[ Go to top ]
- Posted by: Vincent Brabant
- Posted on: February 05 2004 08:03 EST
- in response to Wille Faler
In the JDK 1.5 Home page, you have a link to J2SE 1.5 in a nutshell, with screenshot of the new Theme (Ocean)
http://java.sun.com/developer/technicalArticles/releases/j2se15/
enjoy it -
Nice PDF[ Go to top ]
- Posted by: tyler durden
- Posted on: February 05 2004 08:34 EST
- in response to Vincent Brabant
-
Cool![ Go to top ]
- Posted by: Test Dummy
- Posted on: February 09 2004 03:16 EST
- in response to Vincent Brabant
Heyyyyy!! This looks cool! JMX and all..
Maybe by 2006 I will actually be able to use this also :)
//ras -
Code samples highlighting the new features.[ Go to top ]
- Posted by: Vasanth Dharmaraj
- Posted on: February 05 2004 08:20 EST
- in response to Wille Faler
zamples.com have a nice list of samples you can try online.
http://zamples.com/JspExplorer/samples/samplesJDK1_5.html -
Summary of new language features[ Go to top ]
- Posted by: alf garnet
- Posted on: February 05 2004 08:26 EST
- in response to Wille Faler
-
How about quick adoption?[ Go to top ]
- Posted by: han theman
- Posted on: February 05 2004 09:44 EST
- in response to Clinton Begin
Well, meta data is the death of xdoclet and a lot of other javadoc tools.
Bravo! -
How about quick adoption?[ Go to top ]
- Posted by: Marcus Brito
- Posted on: February 05 2004 09:57 EST
- in response to han theman
Not really. Metadata is now a standard way to markup your code so tools like xdoclet can do something with it. I bet that after JDK 1.5 goes gold xdoclet will be changed to use standard metadata attributes to do it's work instead of relying on xjavadoc. -
xdoclet and JSR 175[ Go to top ]
- Posted by: Paul Cantrell
- Posted on: February 05 2004 13:24 EST
- in response to Marcus Brito
Not really. Metadata is now a standard way to markup your code so tools like xdoclet can do something with it. I bet that after JDK 1.5 goes gold xdoclet will be changed to use standard metadata attributes to do it's work instead of relying on xjavadoc.
This seems logical, but it's likely that it won't happen, or will take a long time if it does. Xdoclet is often used to to generate some source files that are necessary to make other source files compile (e.g. EJB interfaces, data objects). To allow this, Xdoclet implements a cleverly mangled Java parser of its own, with very relaxed parsing rules, which can extract metadata and basic structural information from classes that won't actually compile.
The APIs for extracting Java Metadata all operate on compiled classes. Xdoclet certainly won't be able to use those APIs: to use them you need compiled classes, but to make your classes compile, you might need Xdoclet! To use JSR-175, Xdoclet would once again have to implement their own relaxed parser ... but this time, they have to deal with the much richer structure of Java metadata -- much harder to parse than key=value pairs in Javadoc tags. In any case, they certainly don't get much for free with JSR 175.
I asked Josh Bloch about this, and he basically said that making the spec require that metadata be parsable even if the class doesn't compile would just open too large a can of worms for that JSR to deal with reasonably. And I definitely agree with him. But it does place a large burden on the Xdoclet developers..... -
Tasty, but it's going to be awhile[ Go to top ]
- Posted by: Will Hartung
- Posted on: February 05 2004 14:01 EST
- in response to Clinton Begin
This is really a demarcation point for Java, and its much more widespread than before.
It's a beta, but I bet that my company won't be able to use any of these features for at least a year, if not more.
And the big threat is simply that the community needs to move forward almost in lock step. I fear that something like JBoss will want to move forward with full vigor to 1.5, and thereby want to drag things like Hibernate with it.
But for those who don't use JBoss and are tied to, perhaps, more conservative vendors, those users may get left in a lurch when a key sub-system moves forward.
Much of the differences between 1.2, 1.3, and 1.4 were mostly in the class libraries, and potentialy downgradeable (like adding the Collections framework to 1.2). In fact, I don't know that I've even see the assert keyword out in the wild on a released project, for fear of breaking 1.3 environs.
While forgoing assert is a small price to pay for compatability, dumping some of the new features in 1.5 may be less of an option for users.
So, we shall see... -
What about JDO[ Go to top ]
- Posted by: Ruslan Zenin
- Posted on: February 05 2004 03:45 EST
- in response to Floyd Marinescu
Are there are any plans to have JDO in there or next version?
JDO 2.0 is coming this year. -
Imroved usability on the client side.[ Go to top ]
- Posted by: Sergei Batiuk
- Posted on: February 05 2004 03:56 EST
- in response to Floyd Marinescu
This has been discussed many times before...
1. Responsive and memory-friendly UI (Swing, SWT -- I don't care). SWT seems to be a real alternative to Swing in this way, so it would be cool to include it into JDK. Though not perfect, this solution is a real and viable alternative to Swing to build GUI in Java that brings satisfaction rather than irritation.
2. When loading a Java applet, I would like to see a nice splash screen with a progress bar, something like what you can see when loading a Macromedia flash file (take a look at http://www.lamborghini.com, for example), instead of that stupid taciturn gray box. -
JDK 1.5 Beta and Public Review Specification is out[ Go to top ]
- Posted by: Nipsu
- Posted on: February 05 2004 04:25 EST
- in response to Floyd Marinescu
And the most interesting feature is...
http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html -
Improve (or replace) standard Swing Look-and-Feels[ Go to top ]
- Posted by: Sergei Batiuk
- Posted on: February 05 2004 04:47 EST
- in response to Floyd Marinescu
The standard Swing Look-and-Feels (Windows, Metal) are far from being perfect. WindowsLookAndFeel does remind the native Windows Look and Feel, but it has to be polished - it still looks like alpha.
The best look-and-feels I have ever seen are those from http://www.jgoodies.com. This is what Swing should look like. Sun must incorporate JGoodies into JDK 1.5(mayble refactor package names, if necessary). Whenever I use applets, I use the JGoodies look-and-feels. In this case, however, I need to download them in a separate .jar file (150-200k), which is quite a lot for an applet.
Usability maniac. -
Improve (or replace) standard Swing Look-and-Feels[ Go to top ]
- Posted by: Bill Willis
- Posted on: February 05 2004 08:15 EST
- in response to Sergei Batiuk
The best look-and-feels I have ever seen are those from http://www.jgoodies.com. This is what Swing should look like. Sun must incorporate JGoodies into JDK 1.5(mayble refactor package names, if necessary). Whenever I use applets, I use the JGoodies look-and-feels. In this case, however, I need to download them in a separate .jar file (150-200k), which is quite a lot for an applet.
If you like what JGoodies offers here then perhaps the last thing you want is for them to be included in the JDK. Not being there allows Karsten a certain freedom (and control) in incrementally improving them quickly as needed. So as far as I am concerned, the answer to whether or not they should be included in the JDK (aside from Karsten's own concerns), is not as simple as it may sound. I would personally vote against including them. Although if the standard JDK LNFs don't cut the mustard, then perhaps including a small subset of third party LNFs (as long as they don't stifle further development of those particular LNFs) would be wise (in an ideal world, that is).
Thoughts? -
Improve (or replace) standard Swing Look-and-Feels[ Go to top ]
- Posted by: Sergei Batiuk
- Posted on: February 05 2004 09:02 EST
- in response to Bill Willis
C'mon, Bill!
I DO disagree with you. The main reason I would like to see them in the JDK, like I said, is because I use them in applets often. Unfortunately, this increases the size of my applets (or the number of external .jars that my applet requires to run). Once this .jar in the JDK, my applet gets smaller and requires less external libraries. In many cases my applets are smaller than the l&f library itself...
The JGoodies library is pretty stable and usable IMHO, and is much better than standard look&feels. By having done so, SUNW could have easily made applets much more attractive, and thus customers and, hopefully, Karsten, happier.
Sergei Batiuk. -
Swing Look-and-Feels[ Go to top ]
- Posted by: William Louth
- Posted on: February 05 2004 09:11 EST
- in response to Sergei Batiuk
Hi Sergei,
I don't think the Swing Metal look and feel is that bad. A few tweaks in the color scheme (theme) and color/border defaults can make a difference.
JDBInsight 2.1 uses the metal look and feel but its elegance is derived from standard graphic design principals which would work across any toolkit or platform. Look and feels are only part of the solution.
Check out: http://www.jinspired.com/products/jdbinsight/transflash.html
The problem is not necessarily L&F's but whether programmers (and not designers) be the persons deciding the user interaction and visual style.
I just downloaded 1.5 and was pleased to see that JDBInsight's visual design style is the same across 1.4 and 1.5.
Kind regards,
William Louth
JDBInsight Product Architect
"Tune with Ease"
http://www.jinspired.com -
JDK 1.5 Beta and Public Review Specification is out[ Go to top ]
- Posted by: Nipsu
- Posted on: February 05 2004 05:17 EST
- in response to Floyd Marinescu
[quote]
Lastly, after seven years, we've made jFrame.add equivalent to jFrame.getContentPane().add().
[/quote]
Somebody has managed to keep a sense of humour.. =)
http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#swing -
Generics[ Go to top ]
- Posted by: Billy Newport
- Posted on: February 05 2004 05:45 EST
- in response to Floyd Marinescu
Anyone know if if javac with source 1.5 and 1.4 targets lets generics code run on 1.4 JDKS? -
1.5[ Go to top ]
- Posted by: atus3 .
- Posted on: February 05 2004 06:09 EST
- in response to Billy Newport
Yippppeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee. What a day :-) Thanks Sun engineers. Don't let yourselves be discouraged by the whiners and complainers. -
RE: Generics[ Go to top ]
- Posted by: Jason Gerard
- Posted on: February 05 2004 10:02 EST
- in response to Billy Newport
Anyone know if if javac with source 1.5 and 1.4 targets lets generics code run on 1.4 JDKS?
Nope, just tried it.
jgerard@DEVWORK002 ~/java/test15
$ ~/j15bin/javac -source 1.5 -target 1.4 GenericsTest.java
javac: source release 1.5 requires target release 1.5 -
How about versioning Java3[ Go to top ]
- Posted by: Karl Banke
- Posted on: February 05 2004 08:57 EST
- in response to Floyd Marinescu
Honestly,
these changes are very deep in the language and would normally justify a new major release. Java - used to be simple, straightforward etc. is going to be very different with generics, autoboxing etc. Also, adding monitoring to the JVM and improved GC are massive changes as well. I can't say I like all of the features, in particular generics have failed miserably most of the time in custom development projects. I would like a feature in the compiler that strips down the set of features of the language you can use - now that would be cool..
Karl -
A Quantum Leap[ Go to top ]
- Posted by: Darryl Stoflet
- Posted on: February 05 2004 09:24 EST
- in response to Floyd Marinescu
For the first time I can say I appreciate C# for the simple reason it lit a fire under Sun to radically enhance Java. Has there every been so many added features to a release compared to 1.5?
Besides the obvious additions of auto boxing, enhanced for loops, generics, varargs - which enable printf functionality (see java.util.Formatter), and the memory mapped shared archive for faster startup and less memory usage for muliple JVMs:
MetaData - The other AOP (Attribute Orientated Programming). With this we will likely see POJOs be remoted, persisted, marshalled to XML (and ?) via meta tags.
Class File Transformation (Instrumentation: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/package-summary.html). A hook for AOP implementations?
Management, including JMX 1.2 and JMX Remoting 1.0 with various JVM related MBeans
(http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#jmx). A built in MBeanServer and a cmd line switch to enable remote access via a RMIConnector (see $JAVA_HOME/jre/lib/management).
JDK 1.5 will make Java dominant for at least another 5 years. -
A Quantum Leap[ Go to top ]
- Posted by: Brian Miller
- Posted on: February 05 2004 14:06 EST
- in response to Darryl Stoflet
I'm amazed to see that Java now has sizeof! -
swing or swt?[ Go to top ]
- Posted by: dav kh
- Posted on: February 05 2004 09:28 EST
- in response to Floyd Marinescu
Thanks sun for this great job. But they can even be better.
All of us (almost all) believe that swing API is great but it really sticks to every thing in desktop and SWT brings performance advantage that we need (I cant see any thing more).
So in a closer relation between sun and eclipses SWT team (perhaps a free eclipse) what will happen if both sides accept swing technology (Swing API) but go in SWT way for having better performance?
This will eliminate common problems in j2se world and certainly will be good for any one and additionally will remove common problems about eclipse plug in technology.
I think there is enough time (until releasing stable version of tiger) for this change and making java world united. -
swing or swt?[ Go to top ]
- Posted by: Horia Muntean
- Posted on: February 05 2004 11:19 EST
- in response to dav kh
Quoting from http://java.sun.com/developer/technicalArticles/releases/j2se15/#dc
"Linux and Solaris users who have the latest OpenGL drivers and select graphic cards can get native hardware acceleration from Java2D using the following runtime property:
java -Dsun.java2d.opengl=true -jar Java2D."
Did anybody tried this? Could this mean a real Swing perf boost?
Regards,
Horia -
OpenGL, swing or swt?[ Go to top ]
- Posted by: Brian Miller
- Posted on: February 05 2004 16:01 EST
- in response to Horia Muntean
"Linux and Solaris users who have the latest OpenGL drivers and select graphic cards can get native hardware acceleration from Java2D using the following runtime property: java -Dsun.java2d.opengl=true -jar Java2D."
Did anybody tried this? Could this mean a real Swing perf boost?
I doubt OpenGL noticeably accelerates Swing, since most stock Swing painting isn't Java2D. Maybe Apache's Batik would benefit. -
No Compiler API?[ Go to top ]
- Posted by: Ryan Rhodes
- Posted on: February 05 2004 09:49 EST
- in response to Floyd Marinescu
Earlier versions of the Tiger JSR listed JSR-199. Now the specification says something about JSR-199 being unnessarry, and that com.sun.tools.javac.Main just needs to be documented.
What the heck does this mean? Do we get a standard java.tools.compiler or not?
I'm not exactly sure how the JSP implementors are even doing this right now... The best thing I can think of is to spawn a process everytime you need a compile. Is that the correct way to do it right now? -
1.5 and Mac OS X?[ Go to top ]
- Posted by: Paul Cantrell
- Posted on: February 05 2004 13:12 EST
- in response to Floyd Marinescu
Does anybody know what Apple's plans are around 1.5? Will we see a concurrent or near-concurrent release of 1.5 from Sun and Apple (as Apple has said they're aiming for)? Or will we be waiting as long as we did for 1.3? Any word on the first 1.5 beta on Mac? -
Correcting my own typo[ Go to top ]
- Posted by: Paul Cantrell
- Posted on: February 05 2004 13:14 EST
- in response to Paul Cantrell
Or will we be waiting as long as we did for 1.3?
Sorry, that was a typo -- it was *1.4*, not 1.3, that Mac users ended up waiting on for ages and ages. (TSS really needs a preview button!) -
Why not static printf and println[ Go to top ]
- Posted by: Ziyu Huang
- Posted on: February 05 2004 13:29 EST
- in response to Floyd Marinescu
What not add static printf and println function in java.lang.System
With static import, you can import java.lang.System.out, but you still have to use out.println. if there is a static println in System than we can use println() directly. this we make code more like C. More simple, less code type. ^_^ -
java.util.logging enhancements?[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: February 05 2004 14:45 EST
- in response to Floyd Marinescu
Does J2SE 1.5 contain any significant enhancements to java.util.logging ? -
java.util.logging enhancements?[ Go to top ]
- Posted by: Herve Tchepannou
- Posted on: February 05 2004 15:16 EST
- in response to Sean Sullivan
Looks like they didn't.
That's too bad bc java.util.logging should be like log4j.
I think it would be an exellent idea to standardize it since its log4j is used
almost everywhere and is cleaner that java.util.logging -
java.util.logging enhancements?[ Go to top ]
- Posted by: Nipsu
- Posted on: February 05 2004 19:17 EST
- in response to Herve Tchepannou
That's too bad bc java.util.logging should be like log4j.
> I think it would be an exellent idea to standardize it since its log4j is used
> almost everywhere and is cleaner that java.util.logging
The fact that Sun's logging implementation sucks and log4j is a bloated monster forced me to write yeat another logging system for the app I'm working on. -
JDK 1.5 Beta and Public Review Specification is out[ Go to top ]
- Posted by: Mike Wu
- Posted on: February 05 2004 15:07 EST
- in response to Floyd Marinescu
D:\temp\jdk15Test>more < GTest.java
import java.util.*;
class GTest {
public static void main(String[] agrv) {
ArrayList<Integer> list = new ArrayList<Integer>();
list.add(0, new Integer(42));
int total = list.get(0).intValue();
}
}
D:\temp\jdk15>java -version
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32c)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)
D:\temp\jdk15Test>javac GTest.java
GTest.java:4: '(' or '[' expected
ArrayList<Integer> list = new ArrayList<Integer>();
^
1 error
?????? -
JDK 1.5 Beta and Public Review Specification is out[ Go to top ]
- Posted by: Jim Sculley
- Posted on: February 05 2004 16:23 EST
- in response to Mike Wu
<snip>
> D:\temp\jdk15Test>javac GTest.java
> GTest.java:4: '(' or '[' expected
> ArrayList<Integer> list = new ArrayList<Integer>();
> ^
> 1 error
> ??????
RTFM ;)
http://java.sun.com/j2se/1.5.0/relnotes.html#javac
===============
The -source 1.5 option is required for compiling with the new language features.
The -target 1.4 option is the default, which generates class files that are compatible with 1.4 or 1.5 VMs. A new option -target 1.5 is available for compatibility only with 1.5 VMs.
===============
Also, your source code doesn't need the call to intValue(). Autoboxing/unboxing handles the conversion for you. Autoboxing also allows you to add the primitives directly, doing the wrapping for you in the background. Add in the enhanced for loop and you can have something like this:
import java.util.*;
public class Test {
public static void main(String[] args) {
ArrayList<Integer> list = new ArrayList<Integer>();
list.add(42);
list.add(37);
int total = 0;
for (int i : list) {
total += i;
}
System.out.println(total);
}
}
>javac -source 1.5 Test.java
>java Test
79
Jim S. -
Its getting too complicated[ Go to top ]
- Posted by: Malcolm Edgar
- Posted on: February 05 2004 18:53 EST
- in response to Floyd Marinescu
A lot of new stuff added to 1.5 is great, but I am concerned that some of the new features are making the language unneccessarily complicated. Generics principly come to mind here.
One of the great features of Java is that is simple language to learn. I worry in JDK 1.5 you are going to be able to write code which is difficult understand.
The reason Java was initially so successful, was that it was very easier to learn. Every new feature that is added will increase Java's learning curve. It should also be noted that complexity compounds itself. -
This Rocks[ Go to top ]
- Posted by: Mike Zatko
- Posted on: February 05 2004 23:23 EST
- in response to Floyd Marinescu
I love this. Absolutely superb. The only thing I think Java needs is someway to compile to native code. (without breaking cross platform) If you could compile an app to class files like normal, and then be able to take the extra step and compile the class files to native. Then we could finally start killing all that COBOL code we run, programming games and OS's with Java. -
typedefs[ Go to top ]
- Posted by: Valentin Sliouniaev
- Posted on: February 06 2004 07:43 EST
- in response to Floyd Marinescu
Is there an equivalent of C++ typedef? What I mean is that it is totally boring to type
// Need a small working array just inside this method
ArrayList<Integer> al = new ArrayList<Integer>();
every time I need do use one. Compare it to something like
// Allocate the object on the stack; will be promptly
// and predictably removed. No memory fragmentation or
ArrayListInt al(); // auto-var, allocated on the stack
regards,
--Val. -
typedefs[ Go to top ]
- Posted by: Dmitriy Kiriy
- Posted on: February 09 2004 03:38 EST
- in response to Valentin Sliouniaev
Is there an equivalent of C++ typedef? What I mean is that it is totally boring to type
public class ArrayListInt extends ArrayList<Integer> {
}
Thats it :) -
JDK 1.5 Beta and Public Review Specification is out[ Go to top ]
- Posted by: Smythe
- Posted on: February 06 2004 10:55 EST
- in response to Floyd Marinescu
Has anyone tried out swing apps? Any noticeable speed increases? -
Swing[ Go to top ]
- Posted by: Nipsu
- Posted on: February 06 2004 17:14 EST
- in response to Smythe
Has anyone tried out swing apps? Any noticeable speed increases?
First time start still takes quite a long time. (IntelliJ IDEA is 25 sec if it's the first java app to run). Second time is faster as usual - 9 sec for IDEA with 1.4.2 and 8 sec for 1.5.0. The difference is that the second, different java app starts faster than it did with 1.4.2. I haven't measured the speed difference but it feels like that.
Our server software seems to run ok with 1.5.0 beta. Small bmark/regressiontest suite (mostly XML parsing and database inserts/updates) run 29sec on 1.5.0 and 32sec on 1.4.2_03. The downside is that the 1.5.0's VM size showed 97.336 MB on -server -Xms64m -Xmx64m while the 1.4.2 managed to keep in 89,248 in same settings. This was on windows, so I'll run the same test on linux later to examine the memory consumption there. (BTW: the 3sec difference advantage could be due to the better? xerces parser in 1.5?)
I think the memory consumption increase on windows platform can be explained with this snippet from http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html
The footprint cost of new JVM instances has been reduced in two ways. First, a portion of the shared archive, currently between five and six megabytes, is mapped read-only and therefore shared among multiple JVM processes. Previously this data was replicated in each JVM instance. Second, less data is loaded out of the shared archive because the metadata for unused methods remains completely untouched as opposed to being created and processed during class loading. These savings allow more applications to be run concurrently on the same machine. However, on some operating systems (in particular, Windows), the perceived footprint of the process may increase, because a larger number of pages are being mapped in to the process's address space. Reducing footprint, including perceived footprint, remains a high priority and work is ongoing in this area. -
JDK 1.5 Beta and Public Review Specification is out[ Go to top ]
- Posted by: Dmitriy Kiriy
- Posted on: February 09 2004 03:45 EST
- in response to Floyd Marinescu
java.util Interface Map<K,V> :
boolean containsKey(Object key)
boolean containsValue(Object value)
What the hell Object doing here? -
Auto update of JRE?[ Go to top ]
- Posted by: Martin Bromley
- Posted on: February 18 2004 05:18 EST
- in response to Floyd Marinescu
I heard somewhere about a year ago that there'd be an auto update feature for the JRE. This would be really useful for Web Start apps. Anyone know anything about it..? -
Live code examples for JDK 1.5[ Go to top ]
- Posted by: Michael Slinn
- Posted on: February 25 2004 13:06 EST
- in response to Floyd Marinescu
Zamples, Inc., announced today the availability of a free preview of its Web-based interactive code examples for the Java 2 Standard Edition (J2SE) 1.5 platform. Zamples® patent pending technology increases the productivity of software developers by providing a collaborative facility in which instructional materials, including executable code examples, can be accessed by developers over the Internet or within intranets using a standard browser-based client. Zamples' products allow software developers to share interactive discussions and examples of excellent code and coding techniques to build skills, enhance productivity, and teach complex interfaces and techniques. They can be readily adapted to virtually any language and platform API.
Our mission is to enable platform providers to accelerate the adoption rate of their programming languages and APIs, said Michael Slinn, Zamples' founder and CTO. Software developers learn best by doing. Our products provide them with software 'sandboxes' where they can find and experiment with software examples, and share information about their results with other community members. Our products enable software vendors, enterprise IT departments, system integrators, open source communities, educators, and online publishers to improve developer learning and productivity.
The free preview of Zamples technology for J2SE 1.5 is available on Zamples' web site (http://zamples.com/JspExplorer/samples/index.jsp). Code examples there can be modified, compiled and executed from a web browser, without users installing any code locally on their system. The Zamples' web site also offers online code examples written in Perl, Python and bash for the Amazon Web Services API, the Google Web Services API, the PayPal API and the Java Servlet API.
Zamples server-based software is available now and is licensed either for installation on customer-owned servers or as an application service operated by Zamples. Application service pricing starts at $500 per month.
ABOUT ZAMPLES, INC.
Zamples, Inc. is a privately held corporation based in San Mateo, California.