(Note the odd version number of 0.0.2030 to help make it obvious that you shouldn't use it for anything important.)
For milestone builds like this, please understand that there are still known problems, and it is use-at-your-own-risk. It *definitely* isn't ready for production use. For example, this milestone build is missing release notes, and it doesn't include the developer guide documentation. So, you should expect some trial and error getting everything to work.
Are your expectations low enough yet? Well, I also have some good news about what's included in this milestone:
- The Java 1.5 syntax is fully supported, including generics, enums, nice "for" loops, autoboxing, static imports, annotations, and so on - Support for generics in RPC (no more @gwt.typeArgs!) - The ability to subclass JavaScriptObject<http://code.google.com/p/google-web-toolkit/wiki/JavaScriptObjectRede...>for very straightforward JavaScript interop - Standards mode is now supported by the UI library (though there may be a few remaining bugs)
- GWT 1.5 requires Java 5 or later - The compiler output now goes into a subdirectory (e.g. ".../std" or ".../xs", depending on your linker settings<http://code.google.com/p/google-web-toolkit/wiki/LinkerDesign> ) - To encourage people to start using annotations and generics instead of the javadoc metadata, you'll see warnings about uses of old-style metadata such as @gwt.typeArgs; it is intentionally annoying :-) - The benchmark classes have moved into a separate package; should be easily fixable using your IDE's auto-import fixup - As a performance improvement, widgets now often call DOM.sinkEvents() lazily, when listeners are actually added rather than in the constructor. Sometimes, widget subclasses implicitly depend on the set of events sunk in the superclass' constructor. Consequently, if you are overriding onBrowserEvent() in a widget subclass and certain events mysteriously stop firing, you should explicitly call DOM.sinkEvents() in your subclass constructor for the events you depend on (don't worry, sinking an event more than once has no effect). If the preceding sentences made no sense at all to you, then you shouldn't be affected.
> (Note the odd version number of 0.0.2030 to help make it obvious that you
> shouldn't use it for anything important.)
> For milestone builds like this, please understand that there are still known
> problems, and it is use-at-your-own-risk. It *definitely* isn't ready for
> production use. For example, this milestone build is missing release notes,
> and it doesn't include the developer guide documentation. So, you should
> expect some trial and error getting everything to work.
> Are your expectations low enough yet? Well, I also have some good news about
> what's included in this milestone:
> - The Java 1.5 syntax is fully supported, including generics, enums,
> nice "for" loops, autoboxing, static imports, annotations, and so on
> - Support for generics in RPC (no more @gwt.typeArgs!)
> - The ability to subclass
> JavaScriptObject<http://code.google.com/p/google-web-toolkit/wiki/JavaScriptObjectRede...>for
> very straightforward JavaScript interop
> - Standards mode is now supported by the UI library (though there may
> be a few remaining bugs)
> - GWT 1.5 requires Java 5 or later
> - The compiler output now goes into a subdirectory (e.g. ".../std" or
> ".../xs", depending on your linker
> settings<http://code.google.com/p/google-web-toolkit/wiki/LinkerDesign>
> )
> - To encourage people to start using annotations and generics instead
> of the javadoc metadata, you'll see warnings about uses of old-style
> metadata such as @gwt.typeArgs; it is intentionally annoying :-)
> - The benchmark classes have moved into a separate package; should be
> easily fixable using your IDE's auto-import fixup
> - As a performance improvement, widgets now often call DOM.sinkEvents()
> lazily, when listeners are actually added rather than in the constructor.
> Sometimes, widget subclasses implicitly depend on the set of events sunk in
> the superclass' constructor. Consequently, if you are overriding
> onBrowserEvent() in a widget subclass and certain events mysteriously stop
> firing, you should explicitly call DOM.sinkEvents() in your subclass
> constructor for the events you depend on (don't worry, sinking an event more
> than once has no effect). If the preceding sentences made no sense at all to
> you, then you shouldn't be affected.
> (Note the odd version number of 0.0.2030 to help make it obvious that you
> shouldn't use it for anything important.)
> For milestone builds like this, please understand that there are still known
> problems, and it is use-at-your-own-risk. It *definitely* isn't ready for
> production use. For example, this milestone build is missing release notes,
> and it doesn't include the developer guide documentation. So, you should
> expect some trial and error getting everything to work.
> Are your expectations low enough yet? Well, I also have some good news about
> what's included in this milestone:
> - The Java 1.5 syntax is fully supported, including generics, enums,
> nice "for" loops, autoboxing, static imports, annotations, and so on
> - Support for generics in RPC (no more @gwt.typeArgs!)
> - The ability to subclass
> JavaScriptObject<http://code.google.com/p/google-web-toolkit/wiki/JavaScriptObjectRede...>for
> very straightforward JavaScript interop
> - Standards mode is now supported by the UI library (though there may
> be a few remaining bugs)
> - GWT 1.5 requires Java 5 or later
> - The compiler output now goes into a subdirectory (e.g. ".../std" or
> ".../xs", depending on your linker
> settings<http://code.google.com/p/google-web-toolkit/wiki/LinkerDesign>
> )
> - To encourage people to start using annotations and generics instead
> of the javadoc metadata, you'll see warnings about uses of old-style
> metadata such as @gwt.typeArgs; it is intentionally annoying :-)
> - The benchmark classes have moved into a separate package; should be
> easily fixable using your IDE's auto-import fixup
> - As a performance improvement, widgets now often call DOM.sinkEvents()
> lazily, when listeners are actually added rather than in the constructor.
> Sometimes, widget subclasses implicitly depend on the set of events sunk in
> the superclass' constructor. Consequently, if you are overriding
> onBrowserEvent() in a widget subclass and certain events mysteriously stop
> firing, you should explicitly call DOM.sinkEvents() in your subclass
> constructor for the events you depend on (don't worry, sinking an event more
> than once has no effect). If the preceding sentences made no sense at all to
> you, then you shouldn't be affected.
great work. A note though: You are only supporting JDK1.5.
We are busy making our production ready software using GWT
and since our customers can NOT upgrade tot 1.5 yet, is this
going to be an issue ?
I know that 1.4 is EOL at the end of this year, but we'll still have
customers
running the old VM (so <1.5). (Think about their AppServers, some of
the customer
are still running IBM Websphere 5.1 or 6.0, which are not JDK 1.5
platforms
yet and trust me, upgrading their VM's is a lot of work (for them)).
What would be the solution on this ? Can I use the GWT1.5 binaries
with a 1.4 VM (for example if I use RetroTranslator).
> > (Note the odd version number of 0.0.2030 to help make it obvious that you
> > shouldn't use it for anything important.)
> > For milestone builds like this, please understand that there are still known
> > problems, and it is use-at-your-own-risk. It *definitely* isn't ready for
> > production use. For example, this milestone build is missing release notes,
> > and it doesn't include the developer guide documentation. So, you should
> > expect some trial and error getting everything to work.
> > Are your expectations low enough yet? Well, I also have some good news about
> > what's included in this milestone:
> > - The Java 1.5 syntax is fully supported, including generics, enums,
> > nice "for" loops, autoboxing, static imports, annotations, and so on
> > - Support for generics in RPC (no more @gwt.typeArgs!)
> > - The ability to subclass
> > JavaScriptObject<http://code.google.com/p/google-web-toolkit/wiki/JavaScriptObjectRede...>for
> > very straightforward JavaScript interop
> > - Standards mode is now supported by the UI library (though there may
> > be a few remaining bugs)
> > - GWT 1.5 requires Java 5 or later
> > - The compiler output now goes into a subdirectory (e.g. ".../std" or
> > ".../xs", depending on your linker
> > settings<http://code.google.com/p/google-web-toolkit/wiki/LinkerDesign>
> > )
> > - To encourage people to start using annotations and generics instead
> > of the javadoc metadata, you'll see warnings about uses of old-style
> > metadata such as @gwt.typeArgs; it is intentionally annoying :-)
> > - The benchmark classes have moved into a separate package; should be
> > easily fixable using your IDE's auto-import fixup
> > - As a performance improvement, widgets now often call DOM.sinkEvents()
> > lazily, when listeners are actually added rather than in the constructor.
> > Sometimes, widget subclasses implicitly depend on the set of events sunk in
> > the superclass' constructor. Consequently, if you are overriding
> > onBrowserEvent() in a widget subclass and certain events mysteriously stop
> > firing, you should explicitly call DOM.sinkEvents() in your subclass
> > constructor for the events you depend on (don't worry, sinking an event more
> > than once has no effect). If the preceding sentences made no sense at all to
> > you, then you shouldn't be affected.
There are still some unresolved (some serious) bugs, like #1741, which
possibly makes contents of your HTMLPanel go fishing.
So, don't switch your test platform just yet...
You could use Java 5 to compile the client and whatever you want on
the server-side. You could, for example, instruct the Java 5 compiler
to output Java <1.4-compliant class files. Or, you could refrain from
Java 5 language features in your RPC and compile the server code using
Java <1.4 compiler. Or, implement the server-side independently from
the client, but this way you may have to come up with your own RPC
framework or use JSON.
Lots of options and you still can use Java 5 to develop the client.
Yegor
On Mar 7, 5:57 am, Rockster <rjan...@gmail.com> wrote:
> great work. A note though: You are only supporting JDK1.5.
> We are busy making our production ready software using GWT
> and since our customers can NOT upgrade tot 1.5 yet, is this
> going to be an issue ?
> I know that 1.4 is EOL at the end of this year, but we'll still have
> customers
> running the old VM (so <1.5). (Think about their AppServers, some of
> the customer
> are still running IBM Websphere 5.1 or 6.0, which are not JDK 1.5
> platforms
> yet and trust me, upgrading their VM's is a lot of work (for them)).
> What would be the solution on this ? Can I use the GWT1.5 binaries
> with a 1.4 VM (for example if I use RetroTranslator).
> > On Mar 6, 11:48 am, "Bruce Johnson" <br...@google.com> wrote:
> > > Hi everybody,
> > > GWT 1.5 isn't finished yet, but it is starting to get close. I'm happy to
> > > report that the first milestone build of GWT 1.5 is now available:
> > > (Note the odd version number of 0.0.2030 to help make it obvious that you
> > > shouldn't use it for anything important.)
> > > For milestone builds like this, please understand that there are still known
> > > problems, and it is use-at-your-own-risk. It *definitely* isn't ready for
> > > production use. For example, this milestone build is missing release notes,
> > > and it doesn't include the developer guide documentation. So, you should
> > > expect some trial and error getting everything to work.
> > > Are your expectations low enough yet? Well, I also have some good news about
> > > what's included in this milestone:
> > > - The Java 1.5 syntax is fully supported, including generics, enums,
> > > nice "for" loops, autoboxing, static imports, annotations, and so on
> > > - Support for generics in RPC (no more @gwt.typeArgs!)
> > > - The ability to subclass
> > > JavaScriptObject<http://code.google.com/p/google-web-toolkit/wiki/JavaScriptObjectRede...>for
> > > very straightforward JavaScript interop
> > > - Standards mode is now supported by the UI library (though there may
> > > be a few remaining bugs)
> > > - GWT 1.5 requires Java 5 or later
> > > - The compiler output now goes into a subdirectory (e.g. ".../std" or
> > > ".../xs", depending on your linker
> > > settings<http://code.google.com/p/google-web-toolkit/wiki/LinkerDesign>
> > > )
> > > - To encourage people to start using annotations and generics instead
> > > of the javadoc metadata, you'll see warnings about uses of old-style
> > > metadata such as @gwt.typeArgs; it is intentionally annoying :-)
> > > - The benchmark classes have moved into a separate package; should be
> > > easily fixable using your IDE's auto-import fixup
> > > - As a performance improvement, widgets now often call DOM.sinkEvents()
> > > lazily, when listeners are actually added rather than in the constructor.
> > > Sometimes, widget subclasses implicitly depend on the set of events sunk in
> > > the superclass' constructor. Consequently, if you are overriding
> > > onBrowserEvent() in a widget subclass and certain events mysteriously stop
> > > firing, you should explicitly call DOM.sinkEvents() in your subclass
> > > constructor for the events you depend on (don't worry, sinking an event more
> > > than once has no effect). If the preceding sentences made no sense at all to
> > > you, then you shouldn't be affected.
> (Note the odd version number of 0.0.2030 to help make it obvious that you
> shouldn't use it for anything important.)
> For milestone builds like this, please understand that there are still known
> problems, and it is use-at-your-own-risk. It *definitely* isn't ready for
> production use. For example, this milestone build is missing release notes,
> and it doesn't include the developer guide documentation. So, you should
> expect some trial and error getting everything to work.
> Are your expectations low enough yet? Well, I also have some good news about
> what's included in this milestone:
> - The Java 1.5 syntax is fully supported, including generics, enums,
> nice "for" loops, autoboxing, static imports, annotations, and so on
> - Support for generics in RPC (no more @gwt.typeArgs!)
> - The ability to subclass
> JavaScriptObject<http://code.google.com/p/google-web-toolkit/wiki/JavaScriptObjectRede...>for
> very straightforward JavaScript interop
> - Standards mode is now supported by the UI library (though there may
> be a few remaining bugs)
> - GWT 1.5 requires Java 5 or later
> - The compiler output now goes into a subdirectory (e.g. ".../std" or
> ".../xs", depending on your linker
> settings<http://code.google.com/p/google-web-toolkit/wiki/LinkerDesign>
> )
> - To encourage people to start using annotations and generics instead
> of the javadoc metadata, you'll see warnings about uses of old-style
> metadata such as @gwt.typeArgs; it is intentionally annoying :-)
> - The benchmark classes have moved into a separate package; should be
> easily fixable using your IDE's auto-import fixup
> - As a performance improvement, widgets now often call DOM.sinkEvents()
> lazily, when listeners are actually added rather than in the constructor.
> Sometimes, widget subclasses implicitly depend on the set of events sunk in
> the superclass' constructor. Consequently, if you are overriding
> onBrowserEvent() in a widget subclass and certain events mysteriously stop
> firing, you should explicitly call DOM.sinkEvents() in your subclass
> constructor for the events you depend on (don't worry, sinking an event more
> than once has no effect). If the preceding sentences made no sense at all to
> you, then you shouldn't be affected.
On Fri, Mar 7, 2008 at 11:41 AM, Jeremy Cohen <jeremy.h.co...@gmail.com> wrote:
> Hi, > Is OOPHM available already? If not, is there a target date / timeframe > for this functionality.
OOPHM won't be in GWT 1.5, but we are making solid progress on it in parallel to finalizing 1.5. The post-1.5 development cycle that would include OOPHM is likely to be a lot shorter than the one we're starting to wrap up now. Those Java 5 tweaks took a while.
> On Fri, Mar 7, 2008 at 11:41 AM, Jeremy Cohen <jeremy.h.co...@gmail.com>
> wrote:
> > Hi,
> > Is OOPHM available already? If not, is there a target date / timeframe
> > for this functionality.
> OOPHM won't be in GWT 1.5, but we are making solid progress on it in
> parallel to finalizing 1.5. The post-1.5 development cycle that would
> include OOPHM is likely to be a lot shorter than the one we're starting to
> wrap up now. Those Java 5 tweaks took a while.
