Updating RIFE to support Java 1.8

[Josh Hansen]

Hi Geert (or anyone),

We are still using RIFE (1.6.2-sanpshot-jdk16-20080712.jar). It's
working great. The template system is nice, along with site structure,
form validation, and the db persistence layer. Not using continuations
at this time.

Q. Any suggestions on how to update it to work with Java 8?

Q. Are you currently aware of technologies that sufficiently replaces
each of RIFE's features as to make RIFE obsolete? If so, we could begin
migration to those.

Q. Alternately, long term, any suggestions for how to re-architect RIFE
so builds are no longer dependent on specific JDK versions, or at least,
less dependent?

Josh
--
Joshua Hansen
Up Bear Enterprises
(541) 760-7685

[Geert Bevin]

Hi Josh,

Very glad to hear that you're still using RIFE, I haven't used it myself in a long time.

To run with Java 8, it might be as simple as adding the argument -noverify to the JVM startup.

I don't know of any technology that is on par with what I tried to do with RIFE, it's always imho overly complex, too layered, lots of boilerplate code and not enough centralization. The last JVM project I built with Spring MVC, which is low-level enough that it's still manageable, but I found it very tedious to work with.

Bytecode manipulations are JDK dependent as the class structure evolves. I don't really know how to completely dissociate RIFE's classes from that.

Hope this helps,

Geert 

> --
> You received this message because you are subscribed to the Google Groups "rife-dev"
> group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rife-dev+u...@googlegroups.com.
> To post to this group, send email to rife...@googlegroups.com.
> Visit this group at http://groups.google.com/group/rife-dev.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rife-dev/559C0FFB.5090006%40up-bear.net.
> For more options, visit https://groups.google.com/d/optout.
>

[Tyler Pitchford]

I miss RIFE.

To view this discussion on the web visit https://groups.google.com/d/msgid/rife-dev/etPan.559c1362.ae1cd57.1d37%40cypress.

[Josh Hansen]

Hi Geert,

On 7/7/2015 10:58 AM, Geert Bevin wrote:
> Very glad to hear that you're still using RIFE, I haven't used it myself in a long time.
>
> To run with Java 8, it might be as simple as adding the argument -noverify to the JVM startup.

That seems to work in a quick test with JDK 1.8.0_45. I'll experiment
with development and see how it goes.


Q. Anything I should be watching out for when using it this way?
Without the option, I get a bunch of "VerifyErrors":
----------------------------------
<code>
SEVERE: java.lang.VerifyError: Expecting a stackmap frame at branch
target 19
Exception Details:
Location:
com/zaps/rife/authentication/credentials/RoleUser.setRemember(Z)V
@4: ifnull
Reason:
Expected stackmap frame at this location.
Bytecode:
0x0000000: 2ab4 006e c600 0f2a b400 6e12 6fb9 0075
0x0000010: 0200 572a 1bb5 0025 b1

at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at
com.uwyn.rife.authentication.elements.AbstractPropertyAuthenticatedDeployer.deploy(AbstractPropertyAuthenticatedDeployer.java:133)
at
com.uwyn.rife.authentication.elements.DatabaseAuthenticatedDeployer.deploy(DatabaseAuthenticatedDeployer.java:50)
at
com.uwyn.rife.authentication.elements.PurgingDatabaseAuthenticatedDeployer.deploy(PurgingDatabaseAuthenticatedDeployer.java:30)
at com.uwyn.rife.engine.ElementInfo.deploy(ElementInfo.java:278)
at com.uwyn.rife.engine.SiteBuilder.setupElements(SiteBuilder.java:1015)
at com.uwyn.rife.engine.SiteBuilder.setupData(SiteBuilder.java:1673)
at com.uwyn.rife.engine.SiteBuilder.finish(SiteBuilder.java:259)
at com.uwyn.rife.engine.SiteBuilder.process(SiteBuilder.java:250)
at com.uwyn.rife.engine.SiteBuilder.getSite(SiteBuilder.java:176)
at
com.uwyn.rife.rep.participants.ParticipantSite.initialize(ParticipantSite.java:34)
at com.uwyn.rife.rep.BlockingParticipant.run(BlockingParticipant.java:228)
at java.lang.Thread.run(Thread.java:745)
</code>
----------------------------------

Q. What would be involved in getting builds that don't require a
'-noverify' option? I'm assuming that verification is a useful sanity
check on manipulated bytecode. :)

I'll reply to the other items in a separate e-mail. :)

That did help a lot. Thanks!

[Geert Bevin]

Upgrade ASM and rewrite the bytecode manipulation to be compatible with the new JVM verifier. A lot of projects went through this, sometimes simply upgrading the shaded included ASM classes do the trick. 

[Josh Hansen]

Hi Geert,

On 7/7/2015 10:58 AM, Geert Bevin wrote:

> I don't know of any technology that is on par with what I tried to
> do with RIFE, it's always imho overly complex, too layered, lots of
> boilerplate code and not enough centralization. The last JVM project I
> built with Spring MVC, which is low-level enough that it's still
> manageable, but I found it very tedious to work with.
>
> Bytecode manipulations are JDK dependent as the class structure
> evolves. I don't really know how to completely dissociate RIFE's classes
> from that.

Hmmmm... Assuming that bytecode manip is required, we could write some
developer documentation that might make it easier to migrate / update
for newer VMs.

Assuming there is a way around bytecode manip...

Byte code manipulation pros and cons:
Pros:
* Convenience: simply cast an object, and bytecode manip happens (not
totally sure about this)
* Speed; executes close (same as?) to a direct Java implementation.
* ?? Allows some things not otherwise possible (such as?)

Cons:
* Obscures relationships: IDEs don't know about the relationships the
manipulation introduces, so it is difficult to do a "Find all
references", "Open declaration", to discover how it works.
* Ties a build to particular JDK.

Q. Do the above "pros" cover the main reasons for using byte code
manipulation?

It seems to me that reflection could be used for form generation,
validation and persistence, though it might be slower. A factory which
accepts a bean, and returns a container object with the bean instance as
a property, and a corresponding metadata object as another property,
might get most of the way there. It would require a little more
de-referencing, but the relationships and execution would be easier to
understand in final code.

An explicit reflection/factory mechanism would also follow the existing
pattern where bytecode manip is optional -- it doesn't need to be
applied to all instances of a class. An example is that a list of
retrieved items from a database don't all need meta data instances on them.

For templates, you suggested an implementation that uses pure string
substitution instead of compiled classes. It would be slower, but
doesn't require runtime compilation. This might be a separate issue
depending on how compilation was implemented.

Not sure about continuations would work, since I don't understand them yet.

Newer VMs (Java 7?) have more explicit support for dynamic languages.
If RIFE features are considered as a kind of dynamic language, could
newer VMs make some things easier?

Based on your other e-mail, once "you" understand how the byte-code
manipulation works, it may not be difficult to just manage it that way.
It would still be nice to have a more "self-documenting" mechanism for
the casting / manipulation in normal usage.

[Josh Hansen]

Hi Tyler,

On 7/7/2015 11:08 AM, Tyler Pitchford wrote:
> I miss RIFE.

:)

Are you still doing web app development? If so, which technologies are
you using instead? What are some specific aspects of RIFE that you miss?

[Geert Bevin]

Josh, it's definitely possible to replace some features in RIFE with string handling and reflection, but note that this was where a lot of the current features started up at. For various reasons: performance, capabilities, ... bytecode generation/manipulation was adopted. I would see it as taking several steps backwards to revert to these other approaches. In some situations (like the meta data merging, continuations, ...), it's even impossible to achieve those features without bytecode magic.

Take care,

Geert 

> To view this discussion on the web visit https://groups.google.com/d/msgid/rife-dev/559C3D2B.5090705%40up-bear.net.

[Josh Hansen]

Hi Geert,

On 7/8/2015 12:20 AM, Geert Bevin wrote:
> Josh, it's definitely possible to replace some features in RIFE with
> string handling and reflection, but note that this was where a lot of
> the current features started up at. For various reasons: performance,
> capabilities, ... bytecode generation/manipulation was adopted. I would
> see it as taking several steps backwards to revert to these other
> approaches. In some situations (like the meta data merging,
> continuations, ...), it's even impossible to achieve those features
> without bytecode magic.

Good to know -- that's the insight I was looking for.

Josh

[Tyler Pitchford]

Still doing some web-development, but this shop is mostly using AngularJS. I really miss the whole package. RIFE had everything you needed, a reasonable design, but dropped all the cruft. All the other full-stack frameworks jut didn't mesh with my thinking and felt bloated.

To view this discussion on the web visit https://groups.google.com/d/msgid/rife-dev/559D3DB4.8030707%40up-bear.net.